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

From: S Moonesamy <[email-masked]>
Date: Sat, 26 Oct 2013 15:37:28 -0700

At 06:07 21-10-2013, The IESG wrote:
>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

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?

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.

Regards,
S. Moonesamy

1. msg-id: [email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Oct 2013 02:21:24 -0700

Hi Julian,
At 14:06 27-10-2013, Julian Reschke wrote:
>I have no preference here and will await what the IESG will say :-)

Ok. :-)

>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 am okay with the above comment about the protocol.  I commented 
about the registries in another message.  Some of the registries 
might have to be updated.  In my opinion the charter would not 
prohibit registration updates.

>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.

Regards,
S. Moonesamy

---

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
> 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

---

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

On 2013-10-27 00:37, S Moonesamy wrote:
> 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?

> 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