- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 10 Oct 2002 10:17:43 -0400
- To: ietf-dav-versioning@w3.org
- Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE2973B8D@SUS-MA1IT01>
Could you motivate why we would want to do this? (I'm not saying it's a bad idea, but it is additional text that would need to be added to the protocol definition, and we've got a lot of text already :-). In particular, this information is easily obtainable with a subsequent PROPFIND (and even a streaming PROPFIND, i.e. you can issue the PROPFIND without waiting for the VERSION-CONTROL to succeed). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@greenbytes.de] Sent: Thursday, October 10, 2002 4:32 AM To: ietf-dav-versioning@w3.org Subject: 3.5: VERSION-CONTROL response codes Hi. The VERSION-CONTROL method -- when applied to a versionable but not yet version-controlled resource, creates one or two new resources (being the checked-in version and optionall the version history resource). I'd like to see the definition in 3.5 extended to - allow a 201 to be returned when new resources were created (see [1]) - define that in this case, the Location header should point to the version being created - define an optional response body (DAV:version-control-response) that contains references to the resources being created, such as: <version-control-response xmlns="DAV:"> <checked-in>...</checked-in> <version-history>...</version-history> </version-control-response> (similar marshalling may also be needed for other methods that create new resources) [1] <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.2.2> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 10 October 2002 10:18:35 UTC