- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 24 Sep 2001 23:11:15 +0200
- To: "Webdav WG" <w3c-dist-auth@w3c.org>
Interesting. So both Adobe clients and MS Webfolders assume that in a LOCK response, the DAV:owner will be identical with what they have submitted? I think this is a bug. Has it been reported? (I know that at least Adobe occasionally is following this list). Julian > -----Original Message----- > 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: > - 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 17:11:29 UTC