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: Sun, 27 Oct 2002 20:15:28 +0100
To: <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMELJFKAA.julian.reschke@greenbytes.de>

(I'd like to see this issue added to the issues list)

> From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
> Sent: Friday, October 11, 2002 4:06 PM
> To: Clemm, Geoff; ietf-dav-versioning@w3.org
> Subject: 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 
> 

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
Received on Sunday, 27 October 2002 14:16:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:44 GMT