process for closing out HTTP/1.1

As Jim stated in a previous message, he'll be posting & sending off to
the Internet Drafts editor version -04 of the HTTP/1.1 specification.
While we've struggled with terminology and wording up to now, at this
point we should stop.

We need a document that everyone can live with as HTTP/1.1, that isn't
inconsistent with what we want HTTP to be, and meets the requirements
for a Proposed Standard. Those requirements are laid out in RFC 1602
section 2.3.1. If, after reviewing it, you think that the -04 draft
does not meet all of the criteria, please speak up. The intent is not
to railroad the spec through, it is just to move as expeditiously as
possible. We'd like to submit this to IESG after the requisite 2 week
period, in time for protocol action BEFORE the Montreal meeting.

What RFC 1602 2.3.1 says about Proposed Standard is that it must meet
the following criteria:

  generally stable
	I take this to mean that the major protocol elements are
	stable. Some of the elements of HTTP/1.1 have _not_ been
	stable in the discussions in the committee, but I believe
        these are minor enough to say that the protocol is "generally
        stable.

  has resolved known design choices
	I think this is mainly what we've done: resolving known
        design choices.

  is believed to be well-understood
	The work on "terminology" has tried to clarify those elements
	that are not well understood. Have we succeeded?

  has received significant community review
	While the number of comments on details and wording of
        the specification from a wide variety of individuals
        is evidence of at least some of that review, it's important
        to make sure this has happened.

  appears to enjoy enough community interest to be considered valuable
        For HTTP, this goes without question.

I also note the following:

         The IESG may require implementation and/or operational
         experience prior to granting Proposed Standard status to a
         specification that materially affects the core Internet
         protocols or that specifies behavior that may have significant
         operational impact on the Internet.

If we're held to this paragraph, we will need those of you who are
implementing HTTP/1.1 to be forthcoming about the status of your
understanding of the specification, implementations, and
interoperability tests before we can get Proposed Standard status.

I will also note the following:

         Implementors should treat Proposed Standards as immature
         specifications.  It is desirable to implement them in order to
         gain experience and to validate, test, and clarify the
         specification.  However, since the content of Proposed
         Standards may be changed if problems are found or better
         solutions are identified, deploying implementations of such
         standards into a disruption-sensitive customer base is not
         normally advisable.

Those who plan to ship HTTP/1.1 based on our work should ensure that
the customer base into which they ship it is not
"disruption-sensitive".

Received on Monday, 3 June 1996 10:28:34 UTC