- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Sat, 4 Nov 2006 10:47:53 -0800
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Robert Sayre <sayrer@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Oct 17, 2006, at 7:30 PM, Roy T. Fielding wrote: > > On Oct 17, 2006, at 5:38 PM, Robert Sayre wrote: >> Does anyone think mandatory-to-implement authentication schemes or >> transport-layer security mechanisms will be helpful and realistic? > > Not without changing the HTTP version number, but I suppose that > I shouldn't assume that is obvious. HTTP/1.1 has already been > deployed and I have no interest in declaring any of those > implementations broken just because they failed to anticipate a > not-yet-specified secure auth mechanism. That ship has sailed. Not only is that not obvious, I'm not sure it's true. Publishing a new RFC is not a declaration that implementations of previous RFCs are broken. Nobody expects functioning crystal balls. Changing a version number is a choice that's subject to all kinds of consideration and judgement, rather than a choice that's subject to hard-and-fast rules. (Even if there were rules/guidelines in a given spec about when a version number should change, future protocol authors might find good reasons to violate those, and HTTP has little or no such guidelines.) What's the utility of a version number in HTTP? This is helpful as an explanation of the last change in number: "the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities." and " No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values." So I guess a decision that CLIENTS MUST support Basic and Digest in a new HTTP RFC, might be signalled by a minor version bump. The version bump could signal that support along with a bundle of other capabilities if necessary. The server can use that information to change its behavior and work better with that client. My personal opinion on that is it's probably not of sufficient usefulness for the disruption it would cause -- unless the bundle overall were more than just auth improvements -- because servers can already send auth challenges prompting the client to use Digest if it can. But if a WG were to decide it was worthwhile, then that would be fine and reasonable. But a decision that SERVERS MUST support Basic and Digest -- well that doesn't need a version bump at all to work. We already have a way for servers to advertise support insofar as that's necessary for those algorithms. Lisa
Received on Saturday, 4 November 2006 18:48:08 UTC