- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 28 Jan 2002 20:40:40 +0100
- To: "Jason Crawford" <ccjason@us.ibm.com>, "Lisa Dusseault" <lisa@xythos.com>
- Cc: "Daniel Brotsky" <dbrotsky@adobe.com>, "Clemm, Geoff" <gclemm@Rational.Com>, "Julian Reschke" <julian.reschke@gmx.de>, <w3c-dist-auth@w3c.org>
> From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, January 28, 2002 8:17 PM > To: Lisa Dusseault > Cc: Daniel Brotsky; Clemm, Geoff; Julian Reschke; w3c-dist-auth@w3c.org > Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER > > > > << > We can't redefine DAV: owner. As you suggest, there are current deployed > uses of DAV:owner and there would indeed be transition issues. > >> > If that's the case, let me take a stab at the transition situation of > Julian's proposal. > > Julian proposes a second field for information called > DAV:lockowner that is > a child of DAV:lockinfo. The field is authored by the client and simply > stored unmodifed by the server. Julian has defined it in such a way that > it's clear what "unmodified" means. > > So... > > Old clients will write to DAV:owner only. Not to the new field. > New clients presumably will write to both the old deprecated DAV:owner and > the new DAV:lockowner. > > New servers will (attempt to) preserve both fields. > > What will old servers do if they receive a lock info with the new > DAV:lockowner field but not the old DAV:owner field? What will > old servers > do if the client provides both? Do some of the interop folks know how > current "old" servers are coded? An old server that doesn't ignore the new element would be broken. Is anybody aware of a server that has this bug?
Received on Monday, 28 January 2002 14:41:16 UTC