- From: Jason Crawford <ccjason@us.ibm.com>
- Date: Mon, 28 Jan 2002 14:17:07 -0500
- To: "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
<< 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? J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com
Received on Monday, 28 January 2002 14:32:14 UTC