RE: 3.5: VERSION-CONTROL response codes

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:[email protected]]
Sent: Thursday, October 10, 2002 4:32 AM
To: [email protected]
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