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

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.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Thursday, October 10, 2002 11:30 AM
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 5:10 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: 3.5: VERSION-CONTROL response codes
>
>
> To date, we've limited 3253 modifications to demonstrable
> semantic problems with the protocol (e.g. the Label header)
> or interoperability problems (the use of an OPTIONS body).
> I personally would not want to modify/extend the protocol
> simply for "consistency".  This makes the protocol too much of a
> moving target for implementors.

I agree with this. However, I'm not sure about how intrusive this change is.

- Right now the response code for VERSION-CONTROL conflicts with the
recommendations from RFC2616. With the current wording, client writers can
rely on  getting a 200 on success. I think we should relax that so that 201
is allowed as well (yes, I think this needs to be mentioned as an erratum).

- All the other changes then follow from standard RFC2616 semantics, and or
similar definitions in DeltaV.

Julian

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