W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2002

RE: 3.5: VERSION-CONTROL response codes

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Thu, 7 Nov 2002 13:22:06 +0100
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCGEOOFLAA.julian.reschke@greenbytes.de>

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, October 28, 2002 11:38 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: 3.5: VERSION-CONTROL response codes
> I'll add the issues identified in (1) to the issues/errata list.
> I think clarifying that VERSION-CONTROL can return 201 is
> uncontroversial, so I'll just make that as an editorial change.
> Does anyone object to having VERSION-CONTROL be required to
> return a Location header with the newly created version, just
> as CHECKIN does?  This does seem like a reasonable thing to require,

Note that this would only apply to VERSION-CONTROL when applied to a version
controlled resource. When creating a working resource, it would return 201
but no Location header (because the resource at the request URI was

> to make sure that the client can get a reliable handle to the
> version it just created.
> As for the extension (marshalling the version and vhr info in
> the response body), since this is just an optimization of information
> that can currently be obtained via PROPFIND or the DAV:version-tree
> report, I'd prefer to see that written up in a draft
> that is referenced in the "proposed extensions" section of the
> deltav page, to keep the "issues and errata" document for errors and
> ambiguities in 3253.


Would it make sense to start a draft that contains *all* proposed extensions
the working group agrees on?


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 7 November 2002 07:22:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC