Subject: Last Call: <draft-ietf-httpbis-p1-messaging-24.txt> (Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 21 Oct 2013 06:07:16 -0700

The IESG has received a request from the Hypertext Transfer Protocol Bis
WG (httpbis) to consider the following document:
- 'Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing'
  <draft-ietf-httpbis-p1-messaging-24.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-11-04. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypertext information
   systems.  HTTP has been in use by the World Wide Web global
   information initiative since 1990.  This document provides an
   overview of HTTP architecture and its associated terminology, defines
   the "http" and "https" Uniform Resource Identifier (URI) schemes,
   defines the HTTP/1.1 message syntax and parsing requirements, and
   describes general security concerns for implementations.

Note that this document is part of a set, which should be reviewed together:

* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth
* draft-ietf-httpbis-method-registrations
* draft-ietf-httpbis-authscheme-registrations

The following normative references should be noted as "downward references":
RFC 1950, "ZLIB Compressed Data Format Specification version 3.3"
RFC 1951, "DEFLATE Compressed Data Format Specification version 1.3"
RFC 1952, "GZIP file format specification version 4.3"
Welch, T., "A Technique for High Performance Data Compression"

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/

Once IESG evaluation begins, IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 27 Oct 2013 22:06:23 +0100

On 2013-10-27 00:37, S Moonesamy wrote:
> At 06:07 21-10-2013, The IESG wrote:
> In Section 1:
>    'This HTTP/1.1 specification obsoletes and moves to historic status
>     RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP
>     versioning).  This specification also updates the use of CONNECT to
>     establish a tunnel, previously defined in RFC 2817, and defines the
>     "https" URI scheme that was described informally in RFC 2818.'
>
> RFC 2616 is currently a Draft Standard.  According to RFC 2026:
>
>    "A Draft Standard must be well-understood and known to be quite
>     stable, both in its semantics and as a basis for developing an
>     implementation."
>
> And:
>
>    "A Draft Standard is normally considered to be a final specification,
>     and changes are likely to be made only to solve specific problems
>     encountered.  In most circumstances, it is reasonable for vendors to
>     deploy implementations of Draft Standards into a disruption sensitive
>     environment."
>
> Given that draft-ietf-httpbis-p1-messaging-24 and the other drafts in
> the series is an update of RFC 2616 it is appropriate to move that RFC
> to Obsolete.  The drafts in the series is a substantial revision
> (according to the Document Shepherd). I can understand moving a Proposed
> Standard to Historic.   I read the thread about Issue #254 [1].  I
> didn't find much discussion about moving the specification (RFC 2616)
> which is supposed to be stable to Historic.  What are the implications
> of doing that?

I have no preference here and will await what the IESG will say :-)

> RFC 2616 is updated by RFC 6266 and RFC 6585.  As a note there is about
> explanation about RFC 6266 in draft-ietf-httpbis-p2-semantics-24.  In my
> opinion it is worth considering whether the HTTP status codes specified
> in RFC 6585 should be included in draft-ietf-httpbis-p2-semantics-24.
> That RFC could be included in the series if it is less work.
> ...

Our charter has prohibited us from adding new things to the protocol. 
There are many things (methods, status codes, header fields) that we 
*could* add, but in the end, that's why we have registries.

I believe that keeping new things in separate specs encourages people to 
use the registries instead of relying on a specific set of documents to 
provide the complete picture (today this already is a problem - people 
believing that things not described on 2616 are not "pure" HTTP).

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Oct 2013 11:31:02 +0100

On 2013-10-28 10:21, S Moonesamy wrote:
> ...
>> I believe that keeping new things in separate specs encourages people
>> to use the registries instead of relying on a specific set of
>> documents to provide the complete picture (today this already is a
>> problem - people believing that things not described on 2616 are not
>> "pure" HTTP).
>
> I suggest using the same STD for the set of documents.  It might lessen
> the above problem over time.

-1.

We have registries for exactly that purpose. They provide much better 
control and granularity than including RFCs into document sets.

Best regards, Julian