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,
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.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Sunday, October 27, 2002 2:15 PM
To: ietf-dav-versioning@w3.org
Subject: RE: 3.5: VERSION-CONTROL response codes



(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).
>