HTTP/1.1
draft-ietf-httpbis-messaging-19

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-messaging-18. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

IANA understands that one of the actions requested in the IANA Considerations section is dependent upon the approval and completion of IANA Actions in another document:

draft-ietf-httpbis-semantics

First, in the new Hypertext Transfer Protocol (HTTP) Field Name registry located at

https://www.iana.org/assignments/http-fields

and created as a result of the actions in Section 18.4 of draft-ietf-httpbis-semantics, the following entries will be added:

+===================+==========+======+============+
| Field Name | Status | Ref. | Comments |
+===================+==========+======+============+
| Close | standard | 9.6 | (reserved) |
+-------------------+----------+------+------------+
| MIME-Version | standard | B.1 | |
+-------------------+----------+------+------------+
| Transfer-Encoding | standard | 6.1 | |
+-------------------+----------+------+------------+

Second, in the message namespace at

https://www.iana.org/assignments/media-types

the existing registration for message/http will have its reference and template information replaced with a reference to and information from this document.

Third, in the application namespace at

https://www.iana.org/assignments/media-types

the existing registration for application/http will have its reference and template information replaced with a reference to and information from this document.

Fourth, in the HTTP Transfer Coding registry at

https://www.iana.org/assignments/http-parameters

the reference for the registry and the following entries will be updated to a reference of [ RFC-to-be ]:

+============+===============================+===========+
| Name | Description | Reference |
+============+===============================+===========+
| chunked | Transfer in a series of | Section |
| | chunks | 7.1 |
+------------+-------------------------------+-----------+
| compress | UNIX "compress" data format | Section |
| | [Welch] | 7.2 |
+------------+-------------------------------+-----------+
| deflate | "deflate" compressed data | Section |
| | ([RFC1951]) inside the "zlib" | 7.2 |
| | data format ([RFC1950]) | |
+------------+-------------------------------+-----------+
| gzip | GZIP file format [RFC1952] | Section |
| | | 7.2 |
+------------+-------------------------------+-----------+
| x-compress | Deprecated (alias for | Section |
| | compress) | 7.2 |
+------------+-------------------------------+-----------+
| x-gzip | Deprecated (alias for gzip) | Section |
| | | 7.2 |
+------------+-------------------------------+-----------+

In this registry the registration procedure reference will be changed to [ RFC-to-be; Section 7.3 ]

Fifth, also in the HTTP Transfer Coding registry at

https://www.iana.org/assignments/http-parameters

the following entry will be added:

+============+===============================+===========+
| Name | Description | Reference |
+============+===============================+===========+
| trailers | (reserved) | Section |
| | | 12.3 |
+------------+-------------------------------+-----------+

Sixth, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry at

https://www.iana.org/assignments/tls-extensiontype-values/

the following registration will have its reference replaced with a reference to this document:

+==========+=============================+================+
| Protocol | Identification Sequence | Reference |
+==========+=============================+================+
| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | [ RFC-to-be ] |
| | 0x31 0x2e 0x31 ("http/1.1") | |
+----------+-----------------------------+----------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-09-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-messaging@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (HTTP/1.1) to Internet Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'HTTP/1.1'
  as Internet Standard

This second Last Call is specifically on the intended RFC status change, which
was incorrectly set to Proposed Standard on the previous Last Call.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on the intended RFC status change from Proposed Standard to
Internet Standard. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Hypertext Transfer Protocol (HTTP) is a stateless application-
  level protocol for distributed, collaborative, hypertext information
  systems.  This document specifies the HTTP/1.1 message syntax,
  message parsing, connection management, and related security
  concerns.

  This document obsoletes portions of RFC 7230.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7405: Case-Sensitive String Support in ABNF (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc8446: The Transport Layer Security (TLS) Protocol Version 1.3 (Proposed Standard - Internet Engineering Task Force (IETF))

[Ballot comment]
Thanks for addressing my concern about absolute-form target URIs at
origin servers (by confirming in -semantics that scheme-specific
requirements must be met for properly directed requests)!

I read over the diff from -16 to -17 and had only one new (nit-level)
comment:

Section 9.4

  Furthermore, using multiple connections can cause undesirable side
  effects in congested networks.  Using larger number of multiple
  connections can also cause side effects in otherwise uncongested
  networks, because their aggregate and initially synchronized sending
  behavior can cause congestion that would not have been present if
  fewer parallel connections had been used.

nit: "Using larger number of multiple connections" doesn't seem right,
and possibly in more ways than just the singular/plural mismatch.

However, I'll also retain my previous ballot comments, as on further
inspection I'm not sure to what extent they were already covered in
github.

=====BEGIN PREVIOUS BALLOT COMMENT=====
Thanks for another extremely well written document!

The only general comment I have is that [Semantics] did such a good job
of portraying the trailer section as a generic concept that I was
surprised to see it presented as specific to the chunked
transfer-encoding in this document.  It seems to me (naively, of
course), that when the content can accurately be delimited, whether by
Content-Length or the chunked transfer-encoding, a trailer section could
be read after the request or response and clearly distinguished from the
start of a new request or response.  I recognize that we have a
significant deployed base to be mindful of backwards compatibility with,
and so do not propose to recklessly add trailer sections everywhere.  It
might be worth some more prominent acknowledgment that in HTTP/1.1 the
trailers section is limited to the chunked transfer-encoding, and
discussion of why trailers are not usable in other HTTP/1.1 scenarios,
though.

I did make a github PR with a handful of editorial suggestions, at
https://github.com/httpwg/http-core/pull/872 .

2.2

  The presence of such whitespace in a request might be an attempt to
  trick a server into ignoring that field line or processing the line
  after it as a new request, either of which might result in a security
  vulnerability if other implementations within the request chain
  interpret the same message differently.  [...]

Given the previous procedure that gives as a permitted behavior to
"consume the line without further processing", it seems like an attempt
to get the server to ignore the field line would have succeeded if this
procedure is followed?  I suppose the important difference is that the
field line is completely suppressed from any version of the message
transmitted downstream, thus avoiding the opportunity for a different
interpretation.  Regardless, though, it seems like the text of the guidance
as written (not quoted above) reads like it is setting us up for
vulnerabilities in the presence of non-compliant (or HTTP/1.0?)
implementations in the request chain.  We might want to put in a bit
more explanation of how the stated procedure avoids the vulnerability.

Section 3.2

  Recipients of an invalid request-line SHOULD respond with either a
  400 (Bad Request) error or a 301 (Moved Permanently) redirect with
  the request-target properly encoded.  [...]

(I assume 301 rather than 308 was an intentional choice for maximum
compatibility with old/broken clients.)

Section 3.3

  Supplying a default name for authority within the context of a
  secured connection is inherently unsafe if there is any chance that
  the user agent's intended authority might differ from the selected
  default.  A server that can uniquely identify an authority from the
  request context MAY use that identity as a default without this risk.

Is the contents of the TLS SNI extension sufficient request context to
uniquely identify an intended authority?

Section 5.1

                                                    The field line value
  does not include any leading or trailing whitespace: OWS occurring
  before the first non-whitespace octet of the field line value or
  after the last non-whitespace octet of the field line value ought to
  be excluded by parsers when extracting the field line value from a
  field line.

I have in general tried to refrain from commenting on the extensive use
of the phrase "ought to" in this group of documents, but this particular
scenario seems like a strong candidate for a BCP 14 keyword.

Section 9.8


  TLS provides a facility for secure connection closure.  When a valid
  closure alert is received, an implementation can be assured that no
  further data will be received on that connection.  TLS
  implementations MUST initiate an exchange of closure alerts before
  closing a connection.  A TLS implementation MAY, after sending a
  closure alert, close the connection without waiting for the peer to
  send its closure alert, generating an "incomplete close".  [...]

This is written as if it's imposing normative requirements on generic
TLS implementations (not placing restrictions on what TLS
implementations are suitable for HTTPS).  Fortunately, these "MUST
initiate" and "MAY close without waiting" requirements seem to already
be present in RFC 8446...

                                                              This
  SHOULD only be done when the application knows (typically through
  detecting HTTP message boundaries) that it has sent or received all
  the message data that it cares about.

...whereas this SHOULD does not have an obvious analogue in RFC 8446,
and thus it would make sense to retain the BCP 14 keyword for.

NITS

Section 4

                          The rest of the response message is to be
  interpreted in light of the semantics defined for that status code.
  See Section 15 of [Semantics] for information about the semantics of
  status codes, including the classes of status code (indicated by the
  first digit), the status codes defined by this specification,

In some sense it seems that the referenced status codes are defined by
[Semantics], not "this specification".  I was initially going to propose
(in my PR) a change to "defined for", but that seems incorrect and I
don't have a better proposal handy.

Section 5.2

  A sender MUST NOT generate a message that includes line folding
  (i.e., that has any field line value that contains a match to the
  obs-fold rule) unless [...]

Since we don't include the obs-fold production as a component of any
other production, and field-value excludes CRLF, it seems that any such
field line value would already be in violation of the ABNF and thus
forbidden.  I don't really want to advocate for including obs-fold in
the field-value production in -semantics, though, so maybe accepting
this nit is the least bad choice here.

Section 9.2

  A client that has more than one outstanding request on a connection
  MUST maintain a list of outstanding requests in the order sent and
  MUST associate each received response message on that connection to
  the highest ordered request that has not yet received a final (non-
  1xx) response.

"Highest ordered" implies some numerical rank-list of ordering, but we
don't seem to clearly indicate whether older or newer requests receive
higher numerical indices.  It seems simples to just say "oldest" (or
"newest", if that was the intent) rather than applying numerical
ranking.
=====END PREVIOUS BALLOT COMMENT=====

[Ballot comment]
Thanks for a well-written document.  I learned a bunch from reading this, especially the stuff that talked about how mail differs from HTTP.

Just one thing about which to inquire:

There are a few places where a bare SHOULD is present that left me wondering why it's a SHOULD.  For example, from Section 7.1:

  The chunked encoding does not define any parameters.  Their presence
  SHOULD be treated as an error.

Why isn't that a MUST?  Is there a legitimate reason why I might not treat that as an error?

This reappears in Section 7.2, and there were several others that left me with the same curiosity.  Not a major point, but that additional context might be helpful to some implementers -- or, perhaps, some of them really should be MUSTs.

[Ballot discuss]
Let's discuss whether the currently specified procedures for
reconstructing the target URI from a request-target in absolute-form
provide adequate security properties, at the origin server.  I'm
specifically concerned about taking the scheme directly from the request
target, i.e., making the distinction between the "http" and "https"
schemes.  The simple procedure of "take the scheme from the
request-target" would seem to allow for the client to cause the server
to engage processing for the "https" origin without receiving the
protection that https is supposed to provide.  (The converse case does
not immediately seem to present much risk but is probably worth
preventing as well on general principles of retaining consistency.)  I
don't remember seeing any text that would require the server to validate
the scheme from the request-target against the actual properties of the
transport (or the configured fixed URI scheme as might be provisioned
with a trusted outbound gateway, etc.)  While we do reference §7.4 of
[Semantics] with a note that reconstructing the target URI is only part
of the process of identifying a target resource, that part of
[Semantics] does not mention scheme validation as part of rejecting
misdirected requests.

Does the origin server need to validate the scheme from an absolute-form
request-target?  What is the scope of consequences if it fails to do so?

[Ballot comment]
Thanks for another extremely well written document!

The only general comment I have is that [Semantics] did such a good job
of portraying the trailer section as a generic concept that I was
surprised to see it presented as specific to the chunked
transfer-encoding in this document.  It seems to me (naively, of
course), that when the content can accurately be delimited, whether by
Content-Length or the chunked transfer-encoding, a trailer section could
be read after the request or response and clearly distinguished from the
start of a new request or response.  I recognize that we have a
significant deployed base to be mindful of backwards compatibility with,
and so do not propose to recklessly add trailer sections everywhere.  It
might be worth some more prominent acknowledgment that in HTTP/1.1 the
trailers section is limited to the chunked transfer-encoding, and
discussion of why trailers are not usable in other HTTP/1.1 scenarios,
though.

I did make a github PR with a handful of editorial suggestions, at
https://github.com/httpwg/http-core/pull/872 .

2.2

  The presence of such whitespace in a request might be an attempt to
  trick a server into ignoring that field line or processing the line
  after it as a new request, either of which might result in a security
  vulnerability if other implementations within the request chain
  interpret the same message differently.  [...]

Given the previous procedure that gives as a permitted behavior to
"consume the line without further processing", it seems like an attempt
to get the server to ignore the field line would have succeeded if this
procedure is followed?  I suppose the important difference is that the
field line is completely suppressed from any version of the message
transmitted downstream, thus avoiding the opportunity for a different
interpretation.  Regardless, though, it seems like the text of the guidance
as written (not quoted above) reads like it is setting us up for
vulnerabilities in the presence of non-compliant (or HTTP/1.0?)
implementations in the request chain.  We might want to put in a bit
more explanation of how the stated procedure avoids the vulnerability.

Section 3.2

  Recipients of an invalid request-line SHOULD respond with either a
  400 (Bad Request) error or a 301 (Moved Permanently) redirect with
  the request-target properly encoded.  [...]

(I assume 301 rather than 308 was an intentional choice for maximum
compatibility with old/broken clients.)

Section 3.3

  Supplying a default name for authority within the context of a
  secured connection is inherently unsafe if there is any chance that
  the user agent's intended authority might differ from the selected
  default.  A server that can uniquely identify an authority from the
  request context MAY use that identity as a default without this risk.

Is the contents of the TLS SNI extension sufficient request context to
uniquely identify an intended authority?

Section 5.1

                                                    The field line value
  does not include any leading or trailing whitespace: OWS occurring
  before the first non-whitespace octet of the field line value or
  after the last non-whitespace octet of the field line value ought to
  be excluded by parsers when extracting the field line value from a
  field line.

I have in general tried to refrain from commenting on the extensive use
of the phrase "ought to" in this group of documents, but this particular
scenario seems like a strong candidate for a BCP 14 keyword.

Section 9.8


  TLS provides a facility for secure connection closure.  When a valid
  closure alert is received, an implementation can be assured that no
  further data will be received on that connection.  TLS
  implementations MUST initiate an exchange of closure alerts before
  closing a connection.  A TLS implementation MAY, after sending a
  closure alert, close the connection without waiting for the peer to
  send its closure alert, generating an "incomplete close".  [...]

This is written as if it's imposing normative requirements on generic
TLS implementations (not placing restrictions on what TLS
implementations are suitable for HTTPS).  Fortunately, these "MUST
initiate" and "MAY close without waiting" requirements seem to already
be present in RFC 8446...

                                                              This
  SHOULD only be done when the application knows (typically through
  detecting HTTP message boundaries) that it has sent or received all
  the message data that it cares about.

...whereas this SHOULD does not have an obvious analogue in RFC 8446,
and thus it would make sense to retain the BCP 14 keyword for.

NITS

Section 4

                          The rest of the response message is to be
  interpreted in light of the semantics defined for that status code.
  See Section 15 of [Semantics] for information about the semantics of
  status codes, including the classes of status code (indicated by the
  first digit), the status codes defined by this specification,

In some sense it seems that the referenced status codes are defined by
[Semantics], not "this specification".  I was initially going to propose
(in my PR) a change to "defined for", but that seems incorrect and I
don't have a better proposal handy.

Section 5.2

  A sender MUST NOT generate a message that includes line folding
  (i.e., that has any field line value that contains a match to the
  obs-fold rule) unless [...]

Since we don't include the obs-fold production as a component of any
other production, and field-value excludes CRLF, it seems that any such
field line value would already be in violation of the ABNF and thus
forbidden.  I don't really want to advocate for including obs-fold in
the field-value production in -semantics, though, so maybe accepting
this nit is the least bad choice here.

Section 9.2

  A client that has more than one outstanding request on a connection
  MUST maintain a list of outstanding requests in the order sent and
  MUST associate each received response message on that connection to
  the highest ordered request that has not yet received a final (non-
  1xx) response.

"Highest ordered" implies some numerical rank-list of ordering, but we
don't seem to clearly indicate whether older or newer requests receive
higher numerical indices.  It seems simples to just say "oldest" (or
"newest", if that was the intent) rather than applying numerical
ranking.

[Ballot comment]
Thanks to the editors and contributors of this document for a great job. Specially for the security consideration section, it is very well written and anyone implementing this document should pay extra attentions to that section.

I have following comment and question -

*  I consider this as editorial fix hence not holding a discuss but I would like to see this addressed. This document uses terminologies defined in section 3 of https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-16#section-3, for example - user agent, client. However, it does not refer to the the semantics doc. I think it must refer to the section 3 of semantic document.

* Section 2.2 :  it says -

          "When a server listening only for HTTP request messages, or processing
  what appears from the start-line to be an HTTP request message,
  receives a sequence of octets that does not match the HTTP-message
  grammar aside from the robustness exceptions listed above, the server
  SHOULD respond with a 400 (Bad Request) response and close the
  connection."
        Is there a reason why it is not a MUST but SHOULD? In my small scale implementation experiments I implemented it as a MUST. I believe if a 400 is send followed by a close connection then it is a "save yourself" action for the server and a MUST thing to do. 

* from the ID nits : there is an unused reference to RFC7231.

[Ballot comment]
Thank you for cleaning up this spec.  I appreciate that the effort it takes to achieve this, but it is very helpful to the wider community in the long term.

Not surprisingly, I only have minor comments.

  Although HTTP makes use of some protocol elements similar to the
  Multipurpose Internet Mail Extensions (MIME) [RFC2045], see
  Appendix B for the differences between HTTP and MIME messages.

Nit: This doesn't parse easily to me, perhaps drop the Although?

  Various ad hoc limitations on request-line length are found in
  practice.  It is RECOMMENDED that all HTTP senders and recipients
  support, at a minimum, request-line lengths of 8000 octets.

I was wondering how this applies to constrained devices, but I assume that very constrained devices should probably be using something like CoAP, and otherwise most device should be able to cope with an 8k buffer.

Nit:
Various fields seem have a arbitrary amount of space before the equals: E.g., "method        = token".  I presume that this whitespace is not meaningful, but wondered if the spec would be clearer if it wasn't there.

  A sender MUST NOT
  apply chunked more than once to a message body

Nit: "apply chunked" doesn't read that well to me ... but I understand what it means.  If you decide to change this, then I would check the other places where "chunked" is used.

 
  A client MUST NOT process, cache, or forward such extra data as a
  separate response, since such behavior would be vulnerable to cache
  poisoning.

The intent in this paragraph seemed somewhat ambiguous.  E.g., is the requirement that the client must not process/cache the extra data, or that it must not process/cache the extra data as a separate response?  I assume the latter.

  All transfer-coding names are case-insensitive and ought to be
  registered within the HTTP Transfer Coding registry

Would a 2119 SHOULD be better than ought?

  A client MUST
  NOT send a request containing Transfer-Encoding unless it knows the
  server will handle HTTP/1.1 requests (or later minor revisions);

  and also

  A client MUST NOT use the chunked transfer encoding
  unless it knows the server will handle HTTP/1.1 (or later) requests;

Given that we are in 2021, and the HTTP/1.1 spec was published a couple of decades ago, I was wondering whether the MUST NOT is a bit strong?

Thanks,
Rob

[Ballot comment]
(3.3)  "Alternatively, it might be better to redirect the request to a safe resource that explains how to obtain a new client."

Did you mean "obtain a new user agent?"

(7.1) "recipients MUST anticipate potentially large decimal numerals"

s/decimal/hexidecimal (?) The chunk-size is in hex.

(10) This section could use an introductory paragraph. It is not at all clear from the text why someone would enclose message as data or in what context this would occur.

[Ballot comment]
Thanks for this revision to a crucial standards.  Nits only:

** Section 6.1.  Editorial.  s/ A sender MUST NOT apply chunked more than once/ A sender MUST NOT apply chunked encoding more than once/

** Section 11.1. Hopefully s/sprintf/snprintf/

[Ballot comment]
Section 9.1. , paragraph 2, comment:
>    protocols.  Each connection applies to only one transport link.

I'm not sure I understand what is meant by "transport link" and how connections
would "apply" to one.

Section 9.4. , paragraph 4, comment:
>    consumes server resources.  Furthermore, using multiple connections
>    can cause undesirable side effects in congested networks.

Using larger number of multiple connections can even cause side effects in
otherwise uncongested networks, because their aggregate and initially
synchronized sending behavior can *cause* congestion that would not have been
present if fewer parallel connections had been used.

Section 13.1. , paragraph 14, comment:
>    [Welch]    Welch, T. A., "A Technique for High-Performance Data
>              Compression", IEEE Computer 17(6), June 1984.

This can become an informative reference, so to not create a DOWNREF, since it's
only used in the description of an IANA codepoint.

Section 13.2. , paragraph 12, comment:
>    [RFC7230]  Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
>              Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
>              RFC 7230, DOI 10.17487/RFC7230, June 2014,
>              .

I think it is common practice to normatively cite an RFC that is being
obsoleted.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 9.3. , paragraph 3, nit:
-    Connection header field (Section 7.6.1 of [Semantics]), if any:
+    based on the protocol version and Connection header field in the

Section 11.2. , paragraph 2, nit:
-    Request smuggling ([Linhart]) is a technique that exploits
-                      -        -
+    Request smuggling [Linhart] is a technique that exploits

Section 12.3. , paragraph 3, nit:
-    |            | ([RFC1951]) inside the "zlib" | 7.2      |
-                  -        -
-    |            | data format ([RFC1950])      |          |
-                              -        ^
+    |            | [RFC1951] inside the "zlib"  | 7.2      |
+                                              ++
+    |            | data format [RFC1950]        |          |
+                                        ^^

Section 7.1.1. , paragraph 6, nit:
> to accept in the response, and whether or not the client is willing to prese
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 9.5. , paragraph 2, nit:
> tack has received the client's acknowledgement of the packet(s) containing th
>                                ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

Section 9.8. , paragraph 2, nit:
> onse Splitting Response splitting (a.k.a, CRLF injection) is a common techni
>                                    ^^^^^
The abbreviation is missing a period after the last letter.

Section 10.2. , paragraph 17, nit:
>  such that it can be used over many different forms of encrypted connection,
>                                ^^^^^^^^^^^^^^
Consider using "many".

"Appendix B. ", paragraph 2, nit:
>  (which indicate that the client ought stop sending the header field), and t
>                                  ^^^^^^^^^^
Did you mean "ought to stop"?

"B.3. ", paragraph 2, nit:
> ferring to RFC 723x. * Remove acknowledgements specific to RFC 723x. * Move
>                              ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

"B.4. ", paragraph 1, nit:
> pecific to RFC 723x. * Move "Acknowledgements" to the very end and make them
>                              ^^^^^^^^^^^^^^^^
Do not mix variants of the same word ("acknowledgement" and "acknowledgment")
within a single text.

"C.2.2. ", paragraph 4, nit:
> ction 12.4, update the APLN protocol id for HTTP/1.1 (                                      ^^
This abbreviation for "identification" is spelled all-uppercase.

Uncited references: [RFC7231].

Obsolete reference to RFC2068, obsoleted by RFC2616 (this may be on purpose).

These URLs point to tools.ietf.org, which is being deprecated:
* https://tools.ietf.org/html/draft-ietf-httpbis-semantics-16
* https://tools.ietf.org/html/draft-ietf-httpbis-cache-16

These URLs in the document can probably be converted to HTTPS:
* http://packetstormsecurity.com/papers/general/whitepaper_httpresponse.pdf

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-messaging-16. If any part of this review is inaccurate, please let us know.

IANA has a question about one of this document's five actions. See action 4.

Also, IANA understands that one of the actions requested in the IANA Considerations section is dependent upon the approval and completion of IANA Actions in another document:

draft-ietf-httpbis-semantics

First, in the new Hypertext Transfer Protocol (HTTP) Field Name registry located at

https://www.iana.org/assignments/http-fields

and created as a result of the actions in Section 18.4 of draft-ietf-httpbis-semantics, the following entries will be added:

+===================+==========+======+============+
| Field Name | Status | Ref. | Comments |
+===================+==========+======+============+
| Close | standard | 9.6 | (reserved) |
+-------------------+----------+------+------------+
| MIME-Version | standard | B.1 | |
+-------------------+----------+------+------------+
| Transfer-Encoding | standard | 6.1 | |
+-------------------+----------+------+------------+

Second, in the message namespace at

https://www.iana.org/assignments/media-types

the existing registration for message/http will have its reference and template information replaced with a reference to and information from this document.

Third, in the application namespace at

https://www.iana.org/assignments/media-types

the existing registration for application/http will have its reference and template information replaced with a reference to and information from this document.

Fourth, in the HTTP Transfer Coding registry at

https://www.iana.org/assignments/http-parameters

the following entries will be added:

+============+===============================+===========+
| Name | Description | Reference |
+============+===============================+===========+
| chunked | Transfer in a series of | Section |
| | chunks | 7.1 |
+------------+-------------------------------+-----------+
| compress | UNIX "compress" data format | Section |
| | [Welch] | 7.2 |
+------------+-------------------------------+-----------+
| deflate | "deflate" compressed data | Section |
| | ([RFC1951]) inside the "zlib" | 7.2 |
| | data format ([RFC1950]) | |
+------------+-------------------------------+-----------+
| gzip | GZIP file format [RFC1952] | Section |
| | | 7.2 |
+------------+-------------------------------+-----------+
| trailers | (reserved) | Section |
| | | 12.3 |
+------------+-------------------------------+-----------+
| x-compress | Deprecated (alias for | Section |
| | compress) | 7.2 |
+------------+-------------------------------+-----------+
| x-gzip | Deprecated (alias for gzip) | Section |
| | | 7.2 |
+------------+-------------------------------+-----------+

QUESTION: Section 12.3 says, "Please update the 'HTTP Transfer Coding Registry' at  with the
registration procedure of Section 7.3." However, Section 7.3 does not appear to change the current registration procedure (IETF Review). Should that procedure have been changed? Or should IANA place other information from Section 7.3 in a note at the top of the registry?

Fifth, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry at

https://www.iana.org/assignments/tls-extensiontype-values/

the following registration will have its reference replaced with a reference to this document:

+==========+=============================+================+
| Protocol | Identification Sequence | Reference |
+==========+=============================+================+
| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | [ RFC-to-be ] |
| | 0x31 0x2e 0x31 ("http/1.1") | |
+----------+-----------------------------+----------------+

Note:  The actions will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-10):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-messaging@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (HTTP/1.1) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'HTTP/1.1'
  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
last-call@ietf.org mailing lists by 2021-06-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Hypertext Transfer Protocol (HTTP) is a stateless application-
  level protocol for distributed, collaborative, hypertext information
  systems.  This document specifies the HTTP/1.1 message syntax,
  message parsing, connection management, and related security
  concerns.

  This document obsoletes portions of RFC 7230.




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



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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard; this obsoletes a previous standards-track document RFC 7230. This status is indicated in the document and Datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document is the newest revision of the RFCs that describe HTTP/1.1, the last revision of which was made in 2014. This document represents only the parts of HTTP that are specific to the 1.1 version, while the related semantics document covers the version-independent aspects of HTTP.

Working Group Summary & Document Quality:

The working group, led by the group of three editors, has poured a lot of time and effort into ensuring that these core documents are produced with great quality and clarity. This effort to revise the documents began in 2018, and over the past three years, the working group has spent about half of its meeting time discussing the ongoing work on these core documents. A detailed list of all issues that were discussed can be found on the GitHub repo: https://github.com/httpwg/http-core/issues.

The messaging document in particular, as it primarily describes a long-existing version of the protocol, was more straightforward than the semantics document for WG discussion.

Personnel:

Document Shepherd: Tommy Pauly
Responsible Area Director: Francesca Palombini

I’ve reviewed this document as part of issuing the WGLC, and followed the various comments/issues filed by the WG and discussed in our recent interim meeting. I believe this document is quite ready to be forwarded, and is a truly useful and well-written specification.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. This document has been the product of careful and in-depth by the working group over several years, and went through a long last call.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No new reviews are needed here, in my opinion. This document isn’t introducing any new behavior or architecture, but rather consolidating and clarifying existing documents.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The editors have not indicated any IPR on this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR has been reported.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG consensus seems quite solid. During WGLC, we received in-depth reviews from core participants, as well as many GitHub issues from WG participants. From when WGLC started until now, we received 54 issues on the HTTP core documents from people other than document editors.

https://github.com/httpwg/http-core/issues?q=is%3Aissue+is%3Aclosed

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such complaints have been expressed.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  == There is 1 instance of lines with non-ascii characters in the document.

This is part of an address.

  -- The draft header indicates that this document obsoletes RFC7230, but the
    abstract doesn't seem to directly say this.  It does mention RFC7230
    though, so this could be OK.

This is OK, as the abstract does explain the obsoletion.

  == Unused Reference: 'RFC7231' is defined on line 2032, but no explicit
    reference was found in the text

This reference could likely be removed, or added along with 7230.

  ** Downref: Normative reference to an Informational RFC: RFC 1950

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 1952

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch'

  -- Obsolete informational reference (is this intentional?): RFC 2068
    (Obsoleted by RFC 2616)

  -- Duplicate reference: RFC7230, mentioned in 'RFC7230', was also mentioned
    in 'Err4667'.

Recommend that the AD follows up with these downrefs.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document updates the reference for existing media types, but does not create any new registrations.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

These are highlighted by the nits checks:

  ** Downref: Normative reference to an Informational RFC: RFC 1950

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 1952

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch'

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Please see (14) above.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, this document obsoletes portions of RFC 7230. This is described clearly in the document.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA requests for this document are primarily to move references in existing tables to point to this document, along with filling out some information from the semantics document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document uses ABNF rules, which have been validated.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG impact.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard; this obsoletes a previous standards-track document RFC 7230. This status is indicated in the document and Datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document is the newest revision of the RFCs that describe HTTP/1.1, the last revision of which was made in 2014. This document represents only the parts of HTTP that are specific to the 1.1 version, while the related semantics document covers the version-independent aspects of HTTP.

Working Group Summary & Document Quality:

The working group, led by the group of three editors, has poured a lot of time and effort into ensuring that these core documents are produced with great quality and clarity. This effort to revise the documents began in 2018, and over the past three years, the working group has spent about half of its meeting time discussing the ongoing work on these core documents. A detailed list of all issues that were discussed can be found on the GitHub repo: https://github.com/httpwg/http-core/issues.

The messaging document in particular, as it primarily describes a long-existing version of the protocol, was more straightforward than the semantics document for WG discussion.

Personnel:

Document Shepherd: Tommy Pauly
Responsible Area Director: Francesca Palombini

I’ve reviewed this document as part of issuing the WGLC, and followed the various comments/issues filed by the WG and discussed in our recent interim meeting. I believe this document is quite ready to be forwarded, and is a truly useful and well-written specification.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns. This document has been the product of careful and in-depth by the working group over several years, and went through a long last call.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No new reviews are needed here, in my opinion. This document isn’t introducing any new behavior or architecture, but rather consolidating and clarifying existing documents.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The editors have not indicated any IPR on this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR has been reported.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG consensus seems quite solid. During WGLC, we received in-depth reviews from core participants, as well as many GitHub issues from WG participants. From when WGLC started until now, we received 54 issues on the HTTP core documents from people other than document editors.

https://github.com/httpwg/http-core/issues?q=is%3Aissue+is%3Aclosed

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No such complaints have been expressed.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  == There is 1 instance of lines with non-ascii characters in the document.

This is part of an address.

  -- The draft header indicates that this document obsoletes RFC7230, but the
    abstract doesn't seem to directly say this.  It does mention RFC7230
    though, so this could be OK.

This is OK, as the abstract does explain the obsoletion.

  == Unused Reference: 'RFC7231' is defined on line 2032, but no explicit
    reference was found in the text

This reference could likely be removed, or added along with 7230.

  ** Downref: Normative reference to an Informational RFC: RFC 1950

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 1952

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch'

  -- Obsolete informational reference (is this intentional?): RFC 2068
    (Obsoleted by RFC 2616)

  -- Duplicate reference: RFC7230, mentioned in 'RFC7230', was also mentioned
    in 'Err4667'.

Recommend that the AD follows up with these downrefs.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document updates the reference for existing media types, but does not create any new registrations.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

These are highlighted by the nits checks:

  ** Downref: Normative reference to an Informational RFC: RFC 1950

  ** Downref: Normative reference to an Informational RFC: RFC 1951

  ** Downref: Normative reference to an Informational RFC: RFC 1952

  -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch'

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Please see (14) above.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, this document obsoletes portions of RFC 7230. This is described clearly in the document.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA requests for this document are primarily to move references in existing tables to point to this document, along with filling out some information from the semantics document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

This document uses ABNF rules, which have been validated.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG impact.