RE: GULP vs RFC2518bis

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Lisa Dusseault
   >
   > Here's some initial feedback on the latest GULP.
   >
   > "An UNLOCK request deletes the lock with the specified lock token.
   >  The request-URL of the request MUST identify a resource that
   >  is either directly or indirectly locked by that lock.
   >  After a lock is deleted, no resource is locked by that lock."
   >
   > Do we really want to allow an UNLOCK to an indirectly-locked
   > resource to remove the lock on the directly locked parent?  I'd
   > like to know whether

   RFC2518 says about UNLOCK:

   "The UNLOCK method removes the lock identified by the lock token in
   the Lock-Token request header from the Request-URI, and all other
   resources included in the lock. If all resources which have been
   locked under the submitted lock token can not be unlocked then the
   UNLOCK request MUST fail.  "

   So I think GULP only repeats what RFC2518 has been saying all the
   time (BTW: this is issue UNLOCK_WHAT_URL on the open issues list).

Yes, this was just echoing what appeared to be in 2518.  I'd probably
go with the tighter restriction (i.e. the client must issue the UNLOCK
against the URL that was specified in the LOCK request), but either
one is fine with me.  Since this issue is already been tracked, I
suggest we handle this issue independently of GULP (the change to GULP
is obvious and trivial, i.e. replace "either directly or indirectly"
with just "directly").

   > "A lock token is "submitted" in a request when it appears in an If
   >   header tagged-list whose tag is the lock-root of the lock."
   >
   > This doesn't mention untagged-list syntax in If header.  Is a corollary
   > of this proposal that we remove the untagged-list syntax? Or was the
   > omission of untagged-list accidental?  I'd prefer to keep the untagged
   > list syntax, so I believe this should read:
   >  "A lock token is "submitted" in a request when it appears in an If
   >   header."

   I'd prefer

   "when it appears in an If header tagged-list whose tag is the lock-root
of
   the lock, or if it appears in an untagged list and the request-URL is the
   lock-root of the lock".

I agree this change should be made, and I prefer Julian's rewording, as
it is more precise.  I'll post a new version of GULP with this change.

   > Then this paragraph, with the substitution to "internal member"
   > made as Julian suggested...
   >
   >   "If a request would modify the content for a locked resource, a
   >   dead property of a locked resource, a live property that is
   >   defined to be lockable for a locked resource, or a member URL
   >   in a locked collection, the request MUST fail unless the
   >   lock-token for that lock is submitted in the request."
   >
   > Being picky here, this sentence is conditional on a request
   > modifying "a member URL" in a locked collection. Isn't it any
   > modifications to the internal member, not just the URL?
   > E.g. this definition must encompass a PUT to a indirectly locked
   > internal member, as well as a MOVE.

   No. The *shallow* lock on a collection locks it's member URLs. If
   the lock on the collection isn't deep, you can modify internal
   members without the lock token, as long as you don't change their
   name (affecting the state of the collection itself).

Julian is correct.  If the lock is deep, then the first phrase of
of this section handles the lock on the content of the member
resource.

Cheers,
Geoff

Received on Sunday, 9 March 2003 14:11:51 UTC