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

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

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

Received on Sunday, 27 October 2013 21:06:45 UTC