Re: RFC-2518 LOCK-TOKEN: header

Bill,
If the lock token isn't returned in the header, there's no way for you to
get the lock token of the lock you just created. That's because the active
lock element of the lock discovery property does not contain the
authentication id of the principal owning the lock. The lock  tokens are in
the lock discovery, but you can't figure out which ones you own.

I continue to believe this is an open issue that requires clients to
persist their lock  tokens outside the WebDAV repository. Lock tokens are a
pain enough for the rare case where they are actually useful. Not having
the principal owning the lock in the lock discovery makes them even worse.
I proposed a fix to this over a year ago, but was  told at that time that
it was too late and would have too much effect on the spec which was about
to become an accepted draft. But now we are looking at some pretty
significant changes to locking semantics. Can we please get this simple
issue resolved. WebDAV clients will appreciate it.





bill@carpenter.ORG (WJCarpenter)@w3.org on 01/20/2000 06:31:11 PM

Sent by:  w3c-dist-auth-request@w3.org


To:   w3c-dist-auth@w3.org
cc:

Subject:  RFC-2518 LOCK-TOKEN: header


Examples in RFC-2518, section 8.10.8 et seq, don't show a LOCK-TOKEN:
response header.  This contradicts other places in RFC-2518 which say
that the header is required in the response.

It would suit me if the requirement were changed and the examples left
as is.
--
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

Received on Tuesday, 25 January 2000 12:28:40 UTC