Skip to main content

HTTP/1.1
RFC 9112

Revision differences

Document history

Date Rev. By Action
2022-11-09
19 (System) Received changes through RFC Editor sync (removed Errata tag (all errata rejected))
2022-11-01
19 (System) Received changes through RFC Editor sync (added Errata tag)
2022-06-08
19 (System) IANA registries were updated to include RFC9112
2022-06-06
19 (System)
Received changes through RFC Editor sync (created alias RFC 9112, changed abstract to 'The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for …
Received changes through RFC Editor sync (created alias RFC 9112, changed abstract to '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.', changed pages to 46, changed standardization level to Internet Standard, changed state to RFC, added RFC published event at 2022-06-06, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-httpbis-messaging and RFC 7230, created alias STD 99)
2022-06-06
19 (System) RFC published
2022-04-25
19 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-12-23
19 (System) RFC Editor state changed to AUTH48
2021-11-11
19 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-10-22
19 (System) RFC Editor state changed to REF from EDIT
2021-10-11
19 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-10-08
19 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-10-08
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-10-06
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-09-16
19 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2021-09-16
19 Tero Kivinen Assignment of request for Last Call review by SECDIR to Paul Wouters was marked no-response
2021-09-13
19 (System) RFC Editor state changed to EDIT
2021-09-13
19 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-09-13
19 (System) Announcement was received by RFC Editor
2021-09-13
19 (System) IANA Action state changed to In Progress
2021-09-13
19 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-09-13
19 Cindy Morgan IESG has approved the document
2021-09-13
19 Cindy Morgan Closed "Approve" ballot
2021-09-13
19 Cindy Morgan Ballot approval text was generated
2021-09-13
19 Francesca Palombini The IESG approved the intended status change from Proposed to Internet Standard following the September 9, 2021 IESG Teleconference and follow-up email thread.
2021-09-13
19 (System) Removed all action holders (IESG state changed)
2021-09-13
19 Francesca Palombini IESG state changed to Approved-announcement to be sent from Waiting for AD Go-Ahead
2021-09-12
19 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-09-12
19 Julian Reschke New version available: draft-ietf-httpbis-messaging-19.txt
2021-09-12
19 (System) New version approved
2021-09-12
19 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-09-12
19 Julian Reschke Uploaded new revision
2021-09-06
18 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-09-04
18 Marco Tiloca Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Marco Tiloca. Sent review to list.
2021-09-03
18 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-09-03
18 Sabrina Tanamal
(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 …
(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
2021-09-02
18 Barry Leiba Closed request for Last Call review by ARTART with state 'Withdrawn': This request is a duplicate.  Bug?
2021-09-02
18 Barry Leiba Assignment of request for Last Call review by ARTART to Marco Tiloca was withdrawn
2021-08-24
18 Barry Leiba Request for Last Call review by ARTART is assigned to Marco Tiloca
2021-08-24
18 Barry Leiba Request for Last Call review by ARTART is assigned to Marco Tiloca
2021-08-24
18 Barry Leiba Request for Last Call review by ARTART is assigned to Marco Tiloca
2021-08-24
18 Barry Leiba Request for Last Call review by ARTART is assigned to Marco Tiloca
2021-08-24
18 Gonzalo Salgueiro Assignment of request for Last Call review by ARTART to Gonzalo Salgueiro was rejected
2021-08-24
18 Barry Leiba Request for Last Call review by ARTART is assigned to Gonzalo Salgueiro
2021-08-24
18 Barry Leiba Request for Last Call review by ARTART is assigned to Gonzalo Salgueiro
2021-08-23
18 Cindy Morgan
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 …
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))



2021-08-23
18 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-08-23
18 Francesca Palombini Last call was requested
2021-08-23
18 Francesca Palombini IESG state changed to Last Call Requested from IESG Evaluation::AD Followup
2021-08-23
18 Francesca Palombini Last call announcement was changed
2021-08-23
18 Francesca Palombini Last call announcement was generated
2021-08-23
18 Francesca Palombini Fixing intended RFC status (see https://mailarchive.ietf.org/arch/msg/httpbisa/V0om3C8M-9vsS0761CktqBHK7VU/)
2021-08-23
18 Francesca Palombini Intended Status changed to Internet Standard from Proposed Standard
2021-08-18
18 Julian Reschke New version available: draft-ietf-httpbis-messaging-18.txt
2021-08-18
18 (System) New version approved
2021-08-18
18 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-08-18
18 Julian Reschke Uploaded new revision
2021-07-25
17 Benjamin Kaduk
[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 …
[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=====
2021-07-25
17 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-07-25
17 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-07-25
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-25
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-07-25
17 Julian Reschke New version available: draft-ietf-httpbis-messaging-17.txt
2021-07-25
17 (System) New version approved
2021-07-25
17 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-07-25
17 Julian Reschke Uploaded new revision
2021-06-17
16 (System) Changed action holders to Roy Fielding, Mark Nottingham, Julian Reschke, Francesca Palombini (IESG state changed)
2021-06-17
16 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-06-17
16 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-06-16
16 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to Yes from No Objection
2021-06-16
16 Murray Kucherawy
[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. …
[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.
2021-06-16
16 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-06-16
16 Benjamin Kaduk
[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 …
[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?
2021-06-16
16 Benjamin Kaduk
[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 …
[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.
2021-06-16
16 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-06-16
16 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-06-16
16 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2021-06-16
16 Zaheduzzaman Sarker
[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 …
[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.
2021-06-16
16 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-06-15
16 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-06-14
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-06-14
16 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-06-14
16 Robert Wilton
[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 …
[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
2021-06-14
16 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-06-11
16 Martin Duke
[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 …
[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.
2021-06-11
16 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-06-10
16 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2021-06-10
16 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2021-06-10
16 Olivier Bonaventure Request for Last Call review by TSVART Completed: Ready. Reviewer: Olivier Bonaventure. Sent review to list.
2021-06-10
16 Roman Danyliw
[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 …
[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/
2021-06-10
16 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-06-10
16 Lars Eggert [Ballot discuss]
This document seems to have unresolved IANA issues, so I am holding a DISCUSS
for IANA until the issues are resolved.
2021-06-10
16 Lars Eggert
[Ballot comment]
Section 9.1. , paragraph 2, comment:
>    protocols.  Each connection applies to only one transport link.

I'm not sure I understand what …
[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
2021-06-10
16 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2021-06-10
16 Francesca Palombini Ballot has been issued
2021-06-10
16 Francesca Palombini [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini
2021-06-10
16 Francesca Palombini Created "Approve" ballot
2021-06-10
16 Francesca Palombini IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2021-06-10
16 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-06-09
16 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list.
2021-06-08
16 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-06-08
16 Amanda Baber
(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 …
(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
2021-06-03
16 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2021-06-03
16 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2021-05-27
16 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2021-05-27
16 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2021-05-27
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2021-05-27
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2021-05-27
16 Amy Vezza Placed on agenda for telechat - 2021-06-17
2021-05-27
16 Magnus Westerlund Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2021-05-27
16 Magnus Westerlund Request for Last Call review by TSVART is assigned to Olivier Bonaventure
2021-05-27
16 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-05-27
16 Amy Vezza
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 …
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.




2021-05-27
16 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-05-27
16 Francesca Palombini Last call was requested
2021-05-27
16 Francesca Palombini Last call announcement was generated
2021-05-27
16 Francesca Palombini Ballot approval text was generated
2021-05-27
16 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-05-27
16 Francesca Palombini IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-05-27
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-05-27
16 Julian Reschke New version available: draft-ietf-httpbis-messaging-16.txt
2021-05-27
16 (System) New version approved
2021-05-27
16 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-05-27
16 Julian Reschke Uploaded new revision
2021-05-26
15 (System) Changed action holders to Roy Fielding, Mark Nottingham, Julian Reschke, Francesca Palombini (IESG state changed)
2021-05-26
15 Francesca Palombini IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-04-18
15 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-04-18
15 Francesca Palombini IESG state changed to AD Evaluation from Publication Requested
2021-04-18
15 Francesca Palombini Ballot writeup was changed
2021-04-13
15 Tommy Pauly
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 …
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.
2021-04-13
15 Tommy Pauly Responsible AD changed to Francesca Palombini
2021-04-13
15 Tommy Pauly IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-04-13
15 Tommy Pauly IESG state changed to Publication Requested from I-D Exists
2021-04-13
15 Tommy Pauly IESG process started in state Publication Requested
2021-04-13
15 Tommy Pauly Tag Revised I-D Needed - Issue raised by WGLC cleared.
2021-04-13
15 Tommy Pauly
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 …
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.
2021-04-02
15 Tommy Pauly Notification list changed to tpauly@apple.com because the document shepherd was set
2021-04-02
15 Tommy Pauly Document shepherd changed to Tommy Pauly
2021-04-02
15 Tommy Pauly Changed consensus to Yes from Unknown
2021-04-02
15 Tommy Pauly Intended Status changed to Proposed Standard from None
2021-03-30
15 Julian Reschke New version available: draft-ietf-httpbis-messaging-15.txt
2021-03-30
15 (System) New version approved
2021-03-30
15 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-03-30
15 Julian Reschke Uploaded new revision
2021-02-12
14 Tommy Pauly Tag Revised I-D Needed - Issue raised by WGLC set.
2021-02-12
14 Tommy Pauly IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-01-14
14 Tommy Pauly IETF WG state changed to In WG Last Call from WG Document
2021-01-12
14 Julian Reschke New version available: draft-ietf-httpbis-messaging-14.txt
2021-01-12
14 (System) New version approved
2021-01-12
14 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2021-01-12
14 Julian Reschke Uploaded new revision
2020-12-14
13 Julian Reschke New version available: draft-ietf-httpbis-messaging-13.txt
2020-12-14
13 (System) New version approved
2020-12-14
13 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Mark Nottingham , Julian Reschke
2020-12-14
13 Julian Reschke Uploaded new revision
2020-10-02
12 Julian Reschke New version available: draft-ietf-httpbis-messaging-12.txt
2020-10-02
12 (System) New version approved
2020-10-02
12 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2020-10-02
12 Julian Reschke Uploaded new revision
2020-08-27
11 Julian Reschke New version available: draft-ietf-httpbis-messaging-11.txt
2020-08-27
11 (System) New version approved
2020-08-27
11 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Roy Fielding , Mark Nottingham
2020-08-27
11 Julian Reschke Uploaded new revision
2020-07-12
10 Julian Reschke New version available: draft-ietf-httpbis-messaging-10.txt
2020-07-12
10 (System) New version approved
2020-07-12
10 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Roy Fielding , Mark Nottingham
2020-07-12
10 Julian Reschke Uploaded new revision
2020-07-11
09 Julian Reschke New version available: draft-ietf-httpbis-messaging-09.txt
2020-07-11
09 (System) New version approved
2020-07-11
09 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham , Roy Fielding , Julian Reschke
2020-07-11
09 Julian Reschke Uploaded new revision
2020-05-26
08 Julian Reschke New version available: draft-ietf-httpbis-messaging-08.txt
2020-05-26
08 (System) New version approved
2020-05-26
08 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Mark Nottingham , Roy Fielding
2020-05-26
08 Julian Reschke Uploaded new revision
2020-03-07
07 Julian Reschke New version available: draft-ietf-httpbis-messaging-07.txt
2020-03-07
07 (System) New version approved
2020-03-07
07 (System) Request for posting confirmation emailed to previous authors: Julian Reschke , Roy Fielding , Mark Nottingham
2020-03-07
07 Julian Reschke Uploaded new revision
2019-11-04
06 Julian Reschke New version available: draft-ietf-httpbis-messaging-06.txt
2019-11-04
06 (System) New version approved
2019-11-04
06 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2019-11-04
06 Julian Reschke Uploaded new revision
2019-07-08
05 Julian Reschke New version available: draft-ietf-httpbis-messaging-05.txt
2019-07-08
05 (System) New version approved
2019-07-08
05 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2019-07-08
05 Julian Reschke Uploaded new revision
2019-03-09
04 Julian Reschke New version available: draft-ietf-httpbis-messaging-04.txt
2019-03-09
04 (System) New version approved
2019-03-09
04 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2019-03-09
04 Julian Reschke Uploaded new revision
2018-10-18
03 Julian Reschke New version available: draft-ietf-httpbis-messaging-03.txt
2018-10-18
03 (System) New version approved
2018-10-18
03 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2018-10-18
03 Julian Reschke Uploaded new revision
2018-07-02
02 Julian Reschke New version available: draft-ietf-httpbis-messaging-02.txt
2018-07-02
02 (System) New version approved
2018-07-02
02 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2018-07-02
02 Julian Reschke Uploaded new revision
2018-05-31
01 Julian Reschke New version available: draft-ietf-httpbis-messaging-01.txt
2018-05-31
01 (System) New version approved
2018-05-31
01 (System) Request for posting confirmation emailed to previous authors: Roy Fielding , Julian Reschke , Mark Nottingham
2018-05-31
01 Julian Reschke Uploaded new revision
2018-05-30
00 Mark Nottingham This document now replaces draft-fielding-httpbis-http-messaging instead of None
2018-04-03
00 Julian Reschke New version available: draft-ietf-httpbis-messaging-00.txt
2018-04-03
00 (System) WG -00 approved
2018-04-03
00 Julian Reschke Set submitter to ""Julian F. Reschke" ", replaces to (none) and sent approval email to group chairs: httpbis-chairs@ietf.org
2018-04-03
00 Julian Reschke Uploaded new revision