- From: Daniel Brotsky <dbrotsky@adobe.com>
- Date: Tue, 29 Jan 2002 11:36:26 -0800
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Jason Crawford" <ccjason@us.ibm.com>, <w3c-dist-auth@w3c.org>
At 3:49 PM +0100 1/29/02, Julian Reschke wrote: > > From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford >> Sent: Tuesday, January 29, 2002 3:36 PM >> To: Lisa Dusseault >> Cc: Daniel Brotsky; Clemm, Geoff; Julian Reschke; w3c-dist-auth@w3c.org >> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER >> >> >> >> > (b) Add it to a DAV extension. >> >> Given the current grammar, have we left a route to do this? Not as a >> child of DAV:lockinfo I believe. Perhaps as a child of DAV:owner? > >Sure. WebDAV explicitly states that servers and clients MUST ignore unknown >element. What does this "Sure" apply to, Julian? Do you mean that new children of <DAV:lockinfo> can still be introduced? Or do you mean of <DAV:owner>? > >> I believe one of the things we were going to do was define what it meant >> for the server to maintain DAV:owner. At least one person thought there >> was some ambiguity there. Do we still feel that this is an issue? > >Yes. > >1) The examples in RFC2518 do *not* preserve DAV:owner (watch out for >whitespace!). > >2) We currently don't have a clear definition about *what* needs to >preserved as a property value (this is already on the issues list). Whatever >applies to a property value should reply to the DAV:owner element as well. That's why I used my language about "dead properties" in the earlier message: we need to make sure the resolution to that issue drives the DAV:owner issue. dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Tuesday, 29 January 2002 14:37:25 UTC