- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sat, 8 Mar 2003 10:19:53 -0800
- To: "'Julian Reschke'" <julian.reschke@greenbytes.de>, "'WebDAV'" <w3c-dist-auth@w3.org>
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 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." 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. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Friday, March 07, 2003 6:24 AM > To: 'WebDAV' > Subject: GULP vs RFC2518bis > > > > Hi. > > I'd really like to see some progress regarding this issue. In > http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0281.html I have tried to rephrase GULP so that it doesn't require the term "binding" anymore. This should address the concerns of those who fear that a dependency on the BIND spec is introduced. To those who did object to GULP being part of RFC2518bis *please* review this? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 8 March 2003 13:19:57 UTC