RE: Some more comments on the LABEL section...

   From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]

   Peter Raymond <Peter.Raymond@merant.com> wrote:

   > The last paragraph of the introduction to the LABEL feature
   > (section 8) seems out of place.  This text is non-normative and
   > talks about distributed servers 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.

   That's fine by me (its there because someone asked for that
   justification to be added, but I'm equally happy for it to be moved
   out).

Fine by me as well.  Unless somebody objects, I'll delete this and
we can add it to an implementers guide.

   > Also I am not sure I understand why UPDATE (section 8.9) can take
   > two labels, one in the header and one in the DAV:label-name
   > element.

   I think that is a bug.

Yes, definitely a bug ... thanks for catching that, Peter!

   The Label: header should not apply to an UPDATE request.  A label should
   only appear in the body (in the DAV:label-name element) of the UPDATE
   request.  Then the Label: header simply means "apply this method to the
   version with the given label in the version history of the
   version-controlled resource".

Yes.  This was left over from the days when semantics of UPDATE were
the other direction (i.e. the resource to be updated was in the body,
and the versions to use for the update were specified by the request URL).

   I recommend we disallow/ignore the Label: header on an UPDATE request,
and
   change the postcondition to read:

   "(DAV:apply-request-to-labeled-version): If the request includes a
   DAV:label-name element in the request body, the content and deep
properties
   of the version-controlled resource are updated to be those of the version
   selected by that label."

Yes, that was the intent.  I'll make this fix.

   > 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?

   You're right, for each version-controlled resource matching the
   depth header, UPDATE should select the labeled version in the
   version history of that version-controlled resource.

When "the request is applied to all members", the request is
effectively reapplied for each member, which means the "request-URI"
is effectively reset to be the URI for the member to which the request
is currently being applied.

Cheers,
Geoff

Received on Monday, 10 September 2001 08:38:54 UTC