W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

Some more comments on the LABEL section...

From: Peter Raymond <Peter.Raymond@merant.com>
Date: Fri, 7 Sep 2001 10:22:50 +0100
Message-ID: <20CF1CE11441D411919C0008C7C5A13B027AA383@stalmail.eu.merant.com>
To: ietf-dav-versioning@w3.org

I also have a couple more points/questions regarding section 8 (labels)....

The last paragraph of the introduction to the LABEL feature (section 8)
out of place.  This text is non-normative and talks about distributed
and synchronization which is not discussed elsewhere in the specification.  
It seems like the kinda text you would put in an implementers guide or a 
specification regarding synchronization between deltav servers.  I am sure 
that other aspects of deltav would cause synchronization problems in a 
distributed server environment.  At the London IETF we talked about an 
"implementers guide" for deltav, if we have such a document I propose this 
section is removed from the draft and placed in the implementers guide.

Also I am not sure I understand why UPDATE (section 8.9) can take two
one in the header and one in the DAV:label-name element.  It seems the 
DAV:label-name is used to ensure that the VCR identified by the request URL 
has a certain label, it is only mentioned in a Precondition and so it does 
not affect the UPDATE, it simply prevents UPDATE on a VCR which has no 
versions that have that label.  The Label header on this method will cause 
the UPDATE to change the VCR to point at the version that has the specified 
label.  I guess my questions are:

What's the use case for the DAV:label-name element? Why have it at all?

Why does the DAV:must-select-version-in-history precondition only affect the

request URL, for example when you specify a depth should this precondition 
not apply to all VCRs that match that depth?

Peter Raymond - MERANT
Technical Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
WWW: http://www.merant.com
Received on Friday, 7 September 2001 05:24:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC