Next message: Geoffrey M. Clemm: "Re: 07 Review"
To: ietf-dav-versioning@w3.org
Message-ID: <OF0C3A4BE0.94C99982-ON85256953.00770CE6@raleigh.ibm.com>
From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
Date: Thu, 7 Sep 2000 17:46:36 -0400
Subject: 07 Review
<jim>
6.1 VERSION-CONTROL seems a little overloaded. It does two very
different
things depending on the presence of the entity request body and the
types
of the various arguments. Consider splitting into two methods. (Note
that
if we can unify version selector and bind semantics, then this dual role
goes away). First paragraph should indicate that VERSION-CONTROL either
puts a versionable resource under version control, or creates a new
version selector for a particular version.
</jim>
<tim/>I agree that this section requires very careful reading.
I agree that the section requires careful reading, but I don't think
it would be simplified by splitting it into two methods.
Currently, the result of a successful VERSION-CONTROL request is that
there is a version selector resource at the request URL. I think that
having a single request to achieve this post-condition is appropriate.
<jra>
VERSION-CONTROL is a verb indicating a resource is being put under version
control. The fact that it changes a URL to refer to a revision instead of
an unversioned resource seems quite different than creating a new version
selector URL to an existing revision. Didn't we have a MKRESOURCE method
once that took a request body that contained the same contents as
PROPPATCH. This seems like the right solution here.
</jra>