- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 4 Mar 2003 22:35:49 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Clemm, Geoff'" <gclemm@rational.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 04, 2003 9:33 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: bind draft issues > > > > > > I thought we had agreement that GULP is the currently best approach of > > explaining the WebDAV locking model. GULP also covers binds (implicitly!) > > and therefore either should be added to RFC2518bis, or be the basis for a > > rewrite: > > > > GULP should not cover bindings. That's the problem. It causes a I don't understand this statement. How is the fact that GULP indeed handles the effects of multiple bindings (internal member URIs) to the same resource affecting it's usability for servers that do not need to consider this case??? Maybe it's really time to re-read it: --- Grand Unified Lock Proposal (V5.2) - A lock either directly or indirectly locks a resource. - A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request. - If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if a binding to a resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock. - 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. - 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. - 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 binding of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. --- I really doubt that you make the description significantly simpler by removing this case. > problem because some RFC2518 servers just don't work that way. There's Could you explain? Are you saying that there are RFC2518-compliant servers that do not comply to the GULP lock model? In which case there's simply a problem in the model that needs to be fixed. Actually, Geoff and I have been asking for this kind of feedback for several months now. > no need to say whether operations apply always to URLs, bindings or > resources in RFC2518, because when you have 1:1 mappings between URLs No. You don't. Just because RFC2518 doesn't have a BIND method doesn't mean that multiple bindings do not exist. In fact, RFC2518bis talks about redirect resources, although it doesn't define a method to create them. This is a very similar issue. > and resources it just doesn't matter 95% of the time, and lets > implementations expose their existing repository. So how precisely have these implementations problems with GULP? Please explain! > Otherwise, I think there is a lot of useful specification language in > GULP. OK. So *please* specify in which way GULP is inconsistent with RFC2518. Things I don't like to hear are: - it contains the term "binding" - RFC2518 defines a 1:1 mapping between URL and resource (this is clearly wrong, because RFC2518 extends HTTP, and there's no such restriction in HTTP). Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 4 March 2003 16:36:23 UTC