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:
 - 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.

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
> Sent: Monday, September 24, 2001 5:26 AM
> To: Webdav WG
> Subject: RFC2518 issue with lockdiscovery/activelock/owner
>
>
> Hi,
>
> in WebDAV, the owner of a lock can be reported using the DAV:owner element
> (<http://www.greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_owner>):
>
> <quote>
>
> The owner XML element provides information sufficient for either directly
> contacting a principal (such as a telephone number or Email URI), or for
> discovering the principal (such as the URL of a homepage) who owns a lock.
>
> <!ELEMENT owner ANY>
>
> </quote>
>
> It is documented to have ANY content, while the examples (for instance,
> <http://www.greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.1
> 0.8>) use
> an embedded DAV:href element:
>
> <quote>
>
>      <D:lockdiscovery>
>           <D:activelock>
>                <D:locktype><D:write/></D:locktype>
>                <D:lockscope><D:exclusive/></D:lockscope>
>                <D:depth>Infinity</D:depth>
>                <D:owner>
>                     <D:href>
>                          http://www.ics.uci.edu/~ejw/contact.html
>                     </D:href>
>                </D:owner>
>                <D:timeout>Second-604800</D:timeout>
>                <D:locktoken>
>                     <D:href>
>                opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
>                     </D:href>
>                </D:locktoken>
>           </D:activelock>
>      </D:lockdiscovery>
>
> </quote>
>
>
> While this isn't a problem per se, it seems to have created a situation
> where implementors are unsure how to set and process the owner element.
>
> For instance, the WebDAV library used in Microsoft Office 2000 seems to
> compare the (text) contents of the owner element (as returned in the
> response) with the value it has sent. If they don't match, it assumes that
> the LOCK operation has failed and reports that the document was opened as
> "read only" (which I'd say is clearly a bug).
>
> I think to "fix" this, we whould collect more implementation data. Maybe
> this is a case where we could take advantage of XLink
> (<http://www.w3.org/TR/xlink/>)...:
>
>                <D:owner>
>                     <D:href xlink:role="DAV:principal-homepage"
> DAV:href="http://www.ics.uci.edu/~ejw/contact.html">
>                          Jim Whitehead
>                     </D:href>
>                     <D:href xlink:role="DAV:principal-email"
> DAV:href="mailto:ejw@foobar.com">
>                          Jim Whitehead
>                     </D:href>
>                     <D:href xlink:role="DAV:principal-resource"
> DAV:href="/users/ejw">
>                          Jim Whitehead
>                     </D:href>
>                </D:owner>
>
> or a simpler version that probably wouldn't "break" Office:
>
>                <D:owner xlink:role="DAV:principal-resource"
> DAV:href="/users/ejw">
>                      Jim Whitehead
>                </D:owner>
>
>
>
>
> Julian
>
>
>
>
>

Received on Monday, 24 September 2001 14:18:52 UTC