RE: HOW_TO_IDENTIFY_LOCK_OWNER

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky
> Sent: Tuesday, January 29, 2002 8:36 PM
> To: Julian Reschke
> Cc: Jason Crawford; w3c-dist-auth@w3c.org
> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER
>
>
> 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>?

Sorry :-)

Sure, we can extend DAV:lockinfo, because we *don't* want to introduce
semantice for for 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.

Agreed. Good plan.

Received on Tuesday, 29 January 2002 16:40:37 UTC