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