RE: 3.5: VERSION-CONTROL response codes

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, October 10, 2002 6:47 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: 3.5: VERSION-CONTROL response codes
>
>
> The intrusiveness occurs if we add these extensions as
> a MUST.  If it is a MUST, a client should be able to count
> on them being there, which is where it is a burden on
> server writers (they have to go and rev all their servers
> to provide this new required information).

I wasn't saying that it should be a MUST.

> On the other hand, if we define it in a separate spec,
> it effectively becomes a MAY, which gives clients and servers
> a way of starting to use these extensions without forcing
> existing servers to rev their implementations.
> In a couple of years, it would probably be reasonable to
> absorb a whole set of extensions that have proven to be useful
> in practice, at which point clients can count on them being
> implemented as a bundle.

Well, we can also make it a MAY or a SHOULD and put it into RFC3253bis.

Right now we have:

- the response codes aren't specified, one example (plain V-C) says 200, the
other (V-C in workspace) says 201.

- the document element for the optional response body in fact *is* defined.

So what's left?

1) clarifying that the plain V-C *may* return 201 and optionally may provide
the location of the checked-in version in the Location header

2) possibly allow marshalling of "both" locations (version and VHR) in the
response body.

I think 1) is an erratum, while 2) would be just a useful extension
(although recommended in HTTP).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 11 October 2002 10:06:50 UTC