- 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>
> 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 > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > 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 element.
Received on Monday, 28 January 2002 10:40:03 UTC