- 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