RE: RFC2518 issue with lockdiscovery/activelock/owner

> 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