RE: 3.5: VERSION-CONTROL response codes
"Clemm, Geoff" <[email protected]> Thu, 10 Oct 2002 12:46:53 -0400
| Newsgroups | gmane.ietf.deltav |
|---|---|
| Message-ID | <E4F2D33B98DF7E4880884B9F0E6FDEE2973C06@SUS-MA1IT01> |
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:[email protected]] Sent: Thursday, October 10, 2002 11:30 AM To: Clemm, Geoff; [email protected] Subject: RE: 3.5: VERSION-CONTROL response codes > From: [email protected] > [mailto:[email protected]]On Behalf Of Clemm, Geoff > Sent: Thursday, October 10, 2002 5:10 PM > To: [email protected] > 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