RE: Submitting lock tokens without a validity check

> 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