Re: Document Action: Hypertext Transfer Protocol -- HTTP/1.0 toInformational

> > The IESG has reviewed the Internet-Draft "Hypertext Transfer Protocol
> > -- HTTP/1.0" <draft-ietf-http-v10-spec-05.txt, .ps> and recommends that
> > it be published by the RFC Editor as an Informational RFC, but with the
> > following IESG Note:

> >	The IESG has concerns about this protocol, and expects this
> >	document to be replaced relatively soon by a standards track
> >	document.

> Maybe I'm being a bit picky here, but it should be made clear that there
> are no known plans in the HTTP WG to replace the HTTP/1.0 document, nor to
> replace the HTTP/1.0 protocol described in the document in question. There
> certainly are plans to come out soon with a *different document*, and that
> document will described a *different protocol*, namely HTTP/1.1.

First of all, it's important to view this statement in light of how the IETF
standards process works. Protocols are normally defined and either declared to
be informational or else proceed down the standards track: proposed standard,
draft standard, and finally standard.

A updated protocol can be defined at some point. When complete it normally
obsoletes the older protocol, and if the old version was a standard it is
usually moved to historical status. (The move to historical seems somewhat
haphazard in its application -- for example, RFC1113-1115 (PEM) have been
moved, but RFC1425-1427, which have also been obsoleted by newer documents of
the same or higher grade, have not. I don't pretend to understand the nuances
here.) 

In any case, there is never any attempt to replace or withdraw the document per
se -- once issued, an RFC there forever.

Protocol version numbers offer an interesting twist, however. The usual intent
is for the new version of the protocol to obsolete the old protocol eventually.
I believe this is the intent for, say, RIPv2, SNMPv2, and IPv6. But there seem
to be no hard-and-fast rules for this. As far as I know it would be perfectly
permissible to have two standard protocols, Pv1 and Pv2, with overlapping
functionality and no intent to ever obsolete the earlier version.

Another thing to keep in mind is that the history of protocol versioning in the
IETF doesn't present a pretty picture. We have cases where things were clearly
botched, like MIME-version. We have cases of near-botches, such as IMAP3.  The
inescapable conclusion is that the IETF really doesn't do versioning very well.
Whether this is a problem intrinsic to the IETF or simply a protocol with
protocol versions in general is a matter of opinion.

In any case, I view the IESG statement as effectively saying that "this
protocol will be marked as obsolete the minute there is something to obsolete
it with". This is a strong statement and one quite different from the implicit
default, which I would characterize as "this protocol, like any other, may be
obsoleted by something else in the future". I do think the use of the term
"replace" in this context was unforunate, since it is not the term that is
normally used, nor does it accurately convey a sense of what actually happens.
I recommend that the IESG change the wording to use the term "obsolete"
explicitly.

Wording aside, this is a strong statement for the IESG to make, and I would
also characterize it as a measure of just how uncomfortable the IESG is with
HTTP/1.0. (Please note that I'm simply making an observation here -- I am not
offering an opinion of whether or not I think the IESG is correct in its
assessment.)

> Of course, there are also plans to try to get as much of the world to adopt
> the new protocol as soon as we can. However, this is an implementation
> issue.

I'm a bit unclear as to the nature of your discomfort. If you were concerned
that the document will simply disappear, that just doesn't happen. Obsoleting
one RFC with another, however, is another matter -- this *is* the mechanism
the IETF uses to indicate to the world that people should adopt a new
protocol instead of the old one. 

If you're still uncomfortable with this document being obsoleted at some point,
then I think we may have a problem that deserves further discussion.

				Ned

Received on Tuesday, 2 April 1996 15:03:27 UTC