- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 24 Nov 2002 13:47:06 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, November 23, 2002 11:16 PM > To: 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: Submitting lock tokens without a validity check > > > > Julian said: "Checking: the desired semantics are that the request > succeeds > independently of the lock still being present or not?" > > Geoff said: "Yes." > > My response: I don't agree with that narrow definition of what's > desired. I think the problem statement is that the if header is > constantly causing interoperability problems. The desired semantics are > "some semantics that make locks easier to use". Sorry, but that isn't a definition. I doubt it makes sense to try to solve a set of problems that constantly is being redefined while we are trying to solve it. Unless the mostly silent client implementors are willing to write down *why* locks are hard to use, there's no point in debating it. So far I've seen the following things mentioned, each of which should have it's separate entry in the RFC2518 issues list (Jason?): 1) Syntax of If header relies on "long" HTTP headers, for which support cannot be relied upon (because of proxies). Solution: allow comma separated format and distribution across several header lines. Note: need to find out how a client can discover support for this (support for "long" headers *can* be discovered using TRACE). 2) Clients have both lock tokens and entity tags and want a request to succeed no matter whether the lock is there or not. Solution: possible with current If header syntax. Note: very questionable feature. 3) Clients are in doubt which URL to pass for a given lock token. Solution: clarify that it's the lock root (the URI against which the lock was created). 4) Clients are in doubt which locks need to be provided for a certain operation to succeed. Solution 1: try to clarify. Solution 2: submit all locks using existing If header syntax. 5) Clients want to be notified about expiring/disappearing locks. I wasn't aware of this before and would like to see the use case. If a client is in doubt about the state of the lock tokens it holds, it can discover them using PROPFIND. Anything else? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 24 November 2002 07:47:52 UTC