W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

RE: RFC2518 issue with lockdiscovery/activelock/owner

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 27 Sep 2001 09:30:07 +0200
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEPKDBAA.julian.reschke@gmx.de>
> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT