RE: GULP vs RFC2518bis

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, March 08, 2003 7:20 PM
> To: 'Julian Reschke'; 'WebDAV'
> Subject: RE: GULP vs RFC2518bis
>
>
>
> Here's some initial feedback on the latest GULP.
>
> I much prefer replacing the "bindings" terminology with the "internal
> member" terminology.  That said, I'm still thinking about the model.  I
> think it's worth considering carefully.
>
> "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).

> implementations either already support this or are willing to add
> support for this. I don't have time to verify WFS at the moment but I'm
> assuming it's better to send a partial response now than a more complete
> response later when I dig myself out from a large amount of work.
>
>
> "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".

> 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).

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Saturday, 8 March 2003 14:02:37 UTC