Re: Core versioning issues and nits

Tim covered most of the points very thoroughly ... I assume
that there have been followups to any of his responses that
people may have found unsatisfactory (there were several such
followups :-).  So I just snipped out everything where all
I had to say was "I agree with what Tim says here".

   From: Tim_Ellison@uk.ibm.com

   > 9) What is DAV:checkout-response
   >
   > The definition of the "DAV:already-under-version-control" status
   > message (er, I mean 'postcondition') uses the
   > "DAV:checkout-response" element.  That's not part of core.

   Good catch, I suspect that is a typo. -- it should of course be
   <DAV:version-control>.

And based on other reviews, I'll just delete this part of the
postcondition.

   > 10) Interactions between LOCK and VERSION-CONTROL
   >
   > State whether a locked resource can be placed under
   > version-control, and whether the lock-token must be supplied
   > with the VERSION-CONTROL method.

   Sounds reasonable.

Actually, the interaction between the versioning protocol and
the locking protocol is completely defined in 1.5.4, namely 
that a property defined in the versioning protocol MUST NOT
be modified on a locked resource unless accompanied by a
valid lock token.  In particular, in this case, placing a
resource under version control adds a DAV:checked-in property
on that resource, which requires a lock token if the resource
is locked.

This might be worth adding to the FAQ, but I don't want to
repeat this on every method that updates a property (which
most of them do).

   > 11) Interaction between existing headers and new methods
   >
   > What happens when Depth is applied to the VERSION-CONTROL
   > method?  It seems that this is being addressed in a mail
   > thread, but the specification must define the behaviour.
   > What exactly happens if anything in the scope can't be
   > turned into a VCR?

Depth only applies to methods that explicitly state that they
support the Depth header.  The VERSION-CONTROL method does not.
We don't disallow it though, to leave room for future extensions
that might find a use for the Depth header.

   > 12) Version-tree report
   >
   > In 2.5, the version-tree report is required to be a
   > "DAV:multistatus".  The response could for that could
   > reasonably be 200 Success or 207 multistatus.  Your
   > example shows 200.  Please state normatively, which
   > response code is required.

   Another good one, I think that should be 207 Multistatus.

Great catch!  Same problem with the "locate-history" report.
I'll fix them both.

   > 15) Version-history-is-tree
   >
   > "(DAV:version-history-is-tree): If the request-URL
   > identifies a version-controlled resource that was
   > automatically checked out because DAV:auto-version was
   > DAV:when-locked, then the versions identified by the
   > DAV:predecessor-set of the checked-out resource MUST
   > be descendants of the root version of the version
   > history for the DAV:checked-out version."
   >
   > What does locking have to do with whether the versions
   > must be descendants of the root version?  Wouldn't
   > this also apply when doing autoversioning when unlocked?
   > We don't really understand this paragraph.  Again, we
   > wonder what this is doing in core.

   I don't understand this either.  Given that the root version cannot be
   deleted to maintain connectivity, surely all versions are descendants of
   the root version.

When a version-controlled resource is left checked-out (which in
core can only happen because DAV:auto-version was DAV:when-locked),
the DAV:predecessor-set can be updated by the client.  It could
update the predecessor set to refer to some random resource that
is not in the version history.  This postcondition prevents that.

   > 17) OPTIONS supported-method-set
   >
   > Section 23.6:  this defines 'supported-method-set',
   > but in fact there's already a header that expresses this.
   > How are you dealing with that redundancy?

Now that DAV:supported-method-set is back to being a property,
it is no longer redundant.

   Thanks for the comments, I hope my answers were not too flippant -- I'm
   just in that kind of mood today.

When dealing with an internet protocol, I believe the more
flippancy the better !  (Not going to get a chuckle from
the protocol itself, that's for sure :-).

   For those points where I was able to give a satisfactory answer I strongly
   encourage you to add a Q&A to the Delta-V FAQ
   (http://www.webdav.org/deltav/faq);

I second that request!

Cheers,
Geoff

Received on Sunday, 4 February 2001 22:14:47 UTC