W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002


From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 28 Jan 2002 16:11:15 +0100
To: "Jason Crawford" <ccjason@us.ibm.com>, "Daniel Brotsky" <dbrotsky@adobe.com>
Cc: "Clemm, Geoff" <gclemm@Rational.Com>, <w3c-dist-auth@w3c.org>, "Julian Reschke" <julian.reschke@gmx.de>
Message-ID: <JIEGINCHMLABHJBIGKBCIEGCDOAA.julian.reschke@gmx.de>
> From: Jason Crawford [mailto:ccjason@us.ibm.com]
> Sent: Monday, January 28, 2002 4:07 PM
> To: Daniel Brotsky
> Cc: Clemm, Geoff; w3c-dist-auth@w3c.org; Julian Reschke
> Julian's XLink based proposal sounds fine to me.
> Dan, I assume you understand and sympathize with Geoff's hesitance to
> having the server try to reveal the creator of the lock. Is there
> any other
> info about a lock that ACL's don't provide that you feel needs to be
> provided?
> Geoff, Julian, are we sure we can't just define DAV:owner (rather than a
> new field) more restrictively to comply with your Julian's proposal?

My understanding is that recent interoperability tests have shown that
existing clients WILL break if the server doesn't round-trip whatever the
client provided. So we can't restrict it.

> Lisa, Geoff, Julian, Can you think out the interoperability scenarios and
> issues of Julian's proposal?  (I wasn't at the interops so I'm
> not familiar
> with the current uses of DAV:owner and how Julian's proposal affects the
> currently deployed systems and if there are transition issues.)

My proposal shouldn't affect interoperability because it's a new child
Received on Monday, 28 January 2002 10:40:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:24 UTC