- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 27 Sep 2001 09:30:07 +0200
- To: "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: Monday, September 24, 2001 8:18 PM > To: Julian Reschke; Webdav WG > Subject: RE: RFC2518 issue with lockdiscovery/activelock/owner > > > Actually, the DAV Interop showed that you just can't mess with > the contents > of lock owner as it is now. Adobe clients rely on setting the lock owner > specifically to their own string. DAV:owner value must be set by the > client. > > RFC2518 could extend lockdiscovery in a couple ways: First of all, the previous statement should appear somewhere in the RFC, and the examples should be adjusted to be compliant to this statement: for instance, in 8.10.8 [1] the whitespace inside the href child element is not preserved. > - create a new element of some kind for clients to use, to contain a URI > pointing to the owner. Make a clearer specification about what > this element > contains. > > - create a new element of some kind for servers to use to put their > conception of who created the lock. Probably this is a PrincipalID from > ACLs. I would be interested to work on this definition. I think it's essential that a server can provide enough information to a client to discover the actual owner of a lock, no matter whether and what *his* client has submitted as DAV:owner. First tests show that extending DAV:activelock with new child elements didn't have any negative impact of MS Office and Adobe GoLive. Julian [1] <http://www.greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.8>
Received on Thursday, 27 September 2001 03:30:40 UTC