HTTP/3
draft-ietf-quic-http-34

[Ballot comment]
Another well written document coming out of the QUIC WG, thank you for that.

Some minor comments:

4.1.1.  Field Formatting and Compression

  As in previous versions of HTTP, field names are strings containing a
  subset of ASCII characters that are compared in a case-insensitive
  fashion.  Properties of HTTP field names and values are discussed in
  more detail in Section 5.1 of [SEMANTICS].  As in HTTP/2, characters
  in field names MUST be converted to lowercase prior to their
  encoding.  A request or response containing uppercase characters in
  field names MUST be treated as malformed (Section 4.1.3).

Why make the comparison case-insensitive given that the request MUST only use lowercase characters?  Presumably implementations will just do a regular case sensitive comparison?

4.1.1.2.  Field Compression

Given that section 4.1.1.1.  states that "Pseudo-header fields are not HTTP fields.", it might be helpful to be explicit that pseudo-header fields are also compressed using QPACK.


6.1.  Bidirectional Streams

So as to not unnecessarily limit
  parallelism, at least 100 requests SHOULD be permitted at a time.
 
Given that this section is about streams, perhaps better if the limit is stated in terms of streams, e.g., perhaps change "requests" to "request streams".

10.6.  Use of Compression

  Implementations communicating on a secure channel MUST NOT compress
  content that includes both confidential and attacker-controlled data
  unless separate compression contexts are used for each source of
  data.  Compression MUST NOT be used if the source of data cannot be
  reliably determined.
 
This wasn't entirely clear to me.  I presume (perhaps wrongly) that the issue is about the use of compression before the confidential data has been encrypted.  I.e., I would presume that compressing a stream of data that includes both encrypted and non encrypted data is okay?  Perhaps this could be clarified.

Thanks,
Rob

[Ballot comment]
I support Barry and Ben's DISCUSS (to the extent that I understand it :-))

Other than that, I found this document easily readable, sane, and useful. I with I could say that about more documents...

[Ballot discuss]
[note to Lucas/chairs: a few (three, I think) of these discusses/comments
have preexisting github issues created by the editors over the past couple days
due to some out of band discussions; if we can easily reuse them instead of
creating new ones that would be preferred]

(discuss point 1)
Mike already filed https://github.com/quicwg/base-drafts/issues/4761
and I think we can keep the discussion there.
But to reiterate, we reference [SEMANTICS] for certificate validation
and use in determining authority for the "https" scheme, yet the
additional prose discussion we offer (with CN-ID and DNS-ID as the
certificate fields to validate against, though not by that name) does
not match what's currently present in [SEMANTICS].  Discussion so far on
the linked issue against [SEMANTICS] suggests that [SEMANTICS] will
change, but we should not go forward with this document until we've
resolved the disparity.  (One might also wonder whether we need to
duplicate the content ourselves or should just reference the other
document(s).)

There is a related topic in that our current formulation in this
document treats CN-ID and DNS-ID as equivalently recommended, but
current recommendations (including in RFC 6125) are to prefer SAN-based
names over the (legacy) CN-ID.  I believe there are even some efforts
underway in the Web ecosystem to move to fully deprecating the use of
CN-ID; at present I believe that some entities require that any name
present in the CN-ID be replicated as a DNS-ID as well.  If we are to
proceed with giving equal preference to CN-ID and DNS-ID, I think that
we need to justify or at least call out the divergence from current IETF
guidance.
[Martin filed https://github.com/quicwg/base-drafts/issues/4769 for
the topic regarding whether CN-ID is mandatory or even recommended.]


(discuss point 2)
I also think that the procedure, as written, for coalescing HTTP
requests against different URI authority components onto a single HTTP/3
connection is under-specified and seems inconsistent both with earlier
WG conclusions and with previous IETF-mandated practices for certificate
validation.

[begin historical tracethrough]
There appears to be quite a long history in this space (and I probably
missed some of it, even).  The idea of coalescing has been around back
from the days when we only allowed Alt-Svc as discovery for using QUIC
(no direct access), with
https://github.com/quicwg/base-drafts/issues/940 being an early issue
leading to https://github.com/quicwg/base-drafts/pull/1024/files, with
text that requires both Alt-Svc and valid certificate in order to be
authoritative.  Then we had
https://github.com/quicwg/base-drafts/issues/2223 that notes that this
Alt-Svc requirement is more restrictive than RFC 7540, which allegedly
only requires the certificate to match a given name.  (One might argue
that 7540's "additionally depends on having a certificate that is valid"
implies the "depends on the host having resolved to the same IP address"
still applies, though of course ORIGIN weakens that if it was ever
present and this is not terribly relevant to the current question.)
Comments on #2223 seem to confirm that the intent is to largely parallel
what HTTP/2 does; I'll come back to that in a bit.  The corresponding
text changes here are
https://github.com/quicwg/base-drafts/pull/3558/files that brings in the
concept that "a server is considered authoritative for all URIs with the
'https' scheme for which the hostname in the URI is present in the
authenticated certificate provided by the server, either as [...]".
This text got moved a bit and reworded slightly in response to the
secdir review (https://github.com/quicwg/base-drafts/pull/4419/files),
but the intent is largely still present as "If a server presents a valid
certificate and proof that it controls the corresponding private key,
then a client will accept a secured TLS session with that server as
being authoritative for all origins with the "https" scheme and a host
identified in the certificate."
[end historical tracethrough]

So now we have text that says:

  If a server presents a valid certificate and proof that it controls
  the corresponding private key, then a client will accept a secured
  TLS session with that server as being authoritative for all origins
  with the "https" scheme and a host identified in the certificate.

This seems problematic to me, and divergent from HTTP/2, in that it
focuses on the contents of a certificate *all* being valid/authoritative,
as opposed to a certificate being valid for a given host/name.  To quote
§9.1.1 of RFC 7540:

  For "https" resources, connection reuse additionally depends on
  having a certificate that is valid for the host in the URI.  The
  certificate presented by the server MUST satisfy any checks that the
  client would perform when forming a new TLS connection for the host
  in the URI.

A representative discussion of these checks is included in RFC 6125, and
the general procedure for (server) certificate validation takes as input a
candidate name of a service or entity that the client is attempting to
contact, a certificate (chain) and signature presented by the server,
and the application context in which the decision is being made [0].  In
short, the question is always "do I (as the client) trust the peer
entity to act as this specific name?", and the answer may differ across
names present in a single certificate!  So I think we need to refresh
this text once more, to bring back the sense that for each name that we
might want to allow the server to act as an authority for, we have to do
the normal validation checks.  Saying that we validate a certificate
once along with proof of possession of its private key and then the
holder of the key is a valid authority for all names in the certificate
invites violation of the client's security policy.  For example, the
client's trust database might not allow the CA(s) in the presented chain
to certify some of the names contained in the certificate, among other
reasons.

(discuss point 2.1)
There is probably some extra excitement surrounding revocation, in that
the "normal certificate validation procedures" typically involve some form
of attempt at a revocation check.  What should happen if this check
determines that the certificate has been revoked is not entirely clear.
Presumably the attempt to use a new name from the certificate would
fail, but does it also imply that the entire connection should be torn
down, since it was built using the now-revoked certificate?

(discuss point 2.2)
In practice, the procedure of "check the name in question against the
certificate chain" seems to mean that a client that is willing to
coalesce connections needs to retain the certificate and chain presented
by the peer, so that it is available as input to the certificate
validation engine (typically accessed via the TLS stack, I suppose) at
the time when an authentication decision needs to be made for a given
name.  This operational practice, as well as the actual mechanics of
running a fresh certificate validation procedure, should probably be
mentioned down in Section 3.3 where we discuss the actual connection reuse
procedures.  In particular, I think it would be very benficial to
indicate what protocol interactions trigger an attempt by the client to
validate a new name from the certificate for use as the authority for
HTTP responses, as well as to note clearly that the certificate+chain
have to be retained in order to run these checks.

(discuss point 2.3)
I think we should also look at the procedures for server push as they
relate to coalescing; my understanding is that pushed responses are
allowed to be for requests to a different authority, and thus that a
client will need to discard or reject pushes that are from an authority
that the client does not accept the peer as being authoritative for.  I
guess this is in some sense a check that the client always has to do for
all pushed responses, but I'm not entirely sure whether or where that is
currently described.

[0] This context includes things like the set of trust anchors, as well
as potentially information about restrictions on trust anchors,
revocation checks, pinning or other restrictive information that reduces
the set of CAs that might be allowed to certify a given name, etc.

[Ballot comment]
Thanks for another clear and well-written document.  I especially
appreciated Appendix A.


Thanks to Hilarie Orman for the secdir review and to the team for
responding to it!  It looks like one of the secdir review comments
didn't get its own github issue, so perhaps we can discuss it now:

> I would like to see the Security Considerations spell out exactly
> what security features HTTP expects from QUIC.

Perhaps we could add a line to Section 1.2 where we discuss how QUIC
provides comparable confidentiality and integrity to TLS+TCP, along the
lines of "HTTP/3 relies on QUIC to provide that confidentiality and
integrity protection of data, as well as to provide peer authentication
and reliable, in-order, per-stream delivery."


With all HTTP/3 frames being sent on QUIC streams, including
connection-wide control frames on the control stream, we are in the
situation where QUIC flow control can prevent the conveyance of HTTP
control messages.  This is in some sense covered in Appendix A.2.3,
since "all HTTP/3 frame types defined in this document are sent on
streams", but the corresponding PR discussion seems to have mostly
focused on how this applies to request/response headers, and while the
discussion in #204 does confirm that it is intentional for flow control
to apply, that doesn't really cover whether it is worth noting as a
potentially surprising difference from HTTP/2.  While the HTTP frames
currently defined for the control stream might not be too catastrophic
to be blocked from sending (assuming that SETTINGS will typically get
through in the initial window), I do still wonder if giving specific
guidance on flow control for the HTTP control stream could be useful.
(E.g., calling out that an endpoint might terminate the connection if
blocked by flow control on the control stream for an extended duration,
or even requiring preferential treatment for window updates.)

Section 4.1.1

  Such intermediaries
  SHOULD also remove other connection-specific fields, such as Keep-
  Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they
  are not nominated by the Connection field.

I don't understand why Transfer-Encoding is intrinsically
connection-scoped.  [HTTP11] seems to discuss it acting on a "message"
and being tied to a specific request or response.

Section 9

Is there anything useful to say about whether an HTTP extension might
want to make use of QUIC frames other than STREAM?  In the spirit of
greasing, I worry that if we don't say something, "all HTTP/3 frames go
in QUIC STREAM frames" might become an implicit invariant.  (Yes, I know
about draft-ietf-quic-datagram.)

Section 10.5.2

There is some good discussion in [HTTP-SEMANTICS] about the risk of
CONNECT being used as an arbitrary tunnel, that is probably worth
referencing from here.

  The CONNECT method can be used to create disproportionate load on a
  proxy, since stream creation is relatively inexpensive when compared
  to the creation and maintenance of a TCP connection.  A proxy might
  also maintain some resources for a TCP connection beyond the closing
  of the stream that carries the CONNECT request, since the outgoing
  TCP connection remains in the TIME_WAIT state.  Therefore, a proxy
  cannot rely on QUIC stream limits alone to control the resources
  consumed by CONNECT requests.

I'm not sure how well this last sentence translates from HTTP/2 to
HTTP/3 -- in HTTP/2 the limit is on the number of concurrent streams,
but QUIC gives a hard cap on the absolute stream number, so IIUC an
endpoint could refuse to allow new streams until TCP state had quiesced.
(Of course, this would also prevent any new HTTP requests from being
sent...)

Section 10.9

I think it might be worth another sentence to reiterate that when
[HTTP-REPLAY] talks about "the TLS layer", this applies to the TLS
handshake layer as used as part of QUIC v1, and when it talks about
"early data" that means QUIC 0-RTT.  FWIW, I made a quick pass through
RFC 8470 to look for references to TLS, and didn't find any references
to TLS that would not also apply to QUIC v1's usage of TLS.  (It does
have things like "early data received on that TLS connection" that do
not strictly speaking apply to HTTP/3, but I don't see that one as
particularly problematic.)

Section 11.2.1, 11.2.2

We give the HTTP/3 experts (and registrants) some guidance that
coordinating with the HTTP/2 registries is useful.  Do we want to add a
note to or otherwise update the guidance for the HTTP/2 registries to
give analogous advice to the HTTP/2 experts?

[Mike already opened https://github.com/quicwg/base-drafts/issues/4760
based on some out-of-band discussion, which I incorporate here by reference.
Summary: We probably want the DEs to be able to reject requests to stomp
on a value already used in the other protocol, in addition to the first
unassigned value and excessive/bulk requests.]

Section 11.2.2

I note that RFC 7540 marked setting code 0x0 reserved for h2; should we
mirror that?

Section 12.1

[ALTSVC] doesn't exactly seem to be referenced in a normative manner
anymore.  Back when it was the only way to do HTTP/3 it made sense, but
the current description seems mostly to be saying that "other services
could use Alt-Svc to initiate HTTP/3" which is arguably not really
something you have to know in order to implement and use this spec.

Section 12.2

Can we review the places that reference [HTTP11]?  It seems like we may
be deferring to it for the semantics of, e.g., CONNECT, and OPTIONS with
asterisk-form authority, which would seem to make it a normative
reference, which I understand to be something we're trying to avoid.

Appendix A.3

(nit) I note that A.2.5 gave the codepoints for the HTTP/2 frame types being
discussed; should do the analogous thing for HTTP/2 settings types?

[Ballot discuss]
Thanks, Mike, for the excellent editing work on a very clear and well written document.

In Section 4.1.1 I’m confused by the combination of the following two paragraphs, and would like to discuss what I’m missing:

  Like HTTP/2, HTTP/3 does not use the Connection header field to
  indicate connection-specific fields; in this protocol, connection-
  specific metadata is conveyed by other means.  An endpoint MUST NOT
  generate an HTTP/3 field section containing connection-specific
  fields; any message containing connection-specific fields MUST be
  treated as malformed (Section 4.1.3).

...

  This means that an intermediary transforming an HTTP/1.x message to
  HTTP/3 will need to remove any fields nominated by the Connection
  field, along with the Connection field itself.  Such intermediaries
  SHOULD also remove other connection-specific fields, such as Keep-
  Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they
  are not nominated by the Connection field.

Given the MUST in the first, how can the second only be SHOULD?  Wouldn’t such an intermediary, acting as the HTTP/3 client, be producing a malformed message if it did not “remove other connection-specific fields”?

[Ballot comment]
The work on this document and its companions is greatly appreciated!

Thank you to Hilarie Orman for the SECDIR review.

** Section 3.1.  “The host must be listed either as the CN field …”, why not a normative MUST just as there is in the next sentence around the required use of iPAddress?

** Section 3.3  Per “Once a connection exists to a server endpoint, this connection MAY be reused for requests with multiple different URI authority components”, it might be worth repeating here that in cases of https, changes in the authority components still need to occur within the bounds of the certificate validation practices noted in Section 3.1 and in Section 4.3.4 of draft-ietf-httpbis-semantics.

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and two nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

For many comments, please bear with my lack of expertise in HTTP in general.

-- Section 1.1 --
This section mixes "HTTP/1.1" and "HTTP/1.x" and it is unclear to me what the link is between the first 2 sentences.

-- Section 3.1 --
In "clients SHOULD attempt to use TCP-based versions of HTTP in this case." Should the version(s) of HTTP be specified or is it done on purpose to allow a HTTP/4 over TCP (if ever) ?

-- Section 4.2 --
Should this section mention the work in MASQUE? While I am not really familiar with MASQUE, isn't it using the CONNECT H/2 method (e.g., draft-ietf-masque-connect-udp albeit for UDP) ?

-- Section 4.4 --
Should the client behavior be specified when server does not respect "A server SHOULD use Push IDs sequentially, beginning from zero. " ?

-- Section 5.3 --
Should the CONNECT method behavior be specified when the client does an immediate closure?

-- Section 5.4 --
Should the server behavior be specified when the QUIC transport aborts ? It is mostly obvious that all states will be cleared but what about the CONNECT method ?

-- Section 11.2.1 and others --
I must admit that the purpose of the special "0x1f * N + 0x21" values are unknown to me (or is it only for application padding as described in the security section?) but shouldn't they be reserved in the IANA registry?

== NITS ==

-- Section 1 --
" These semantics have most commonly been used with
  HTTP/1.1, over a variety of transport and session layers, and with
  HTTP/2 over TLS. "
 
The asymmetric use of comas is puzzling, should there be a coma after "HTTP/2" ?

-- Section 11.2 --
Should "and a contact of the HTTP working group (ietf-http-wg@w3.org)." rather be "and a contact of the W3C HTTP working group (ietf-http-wg@w3.org)." ?

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

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

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: draft-ietf-quic-transport.

The IANA Functions Operator has questions about the actions requested in the IANA Considerations section of this document.

IANA Question --> [ RFC-to-be Section 11.2 of the current draft request creation of three new registries: frame types, settings and error codes. Should those registries be placed on the registry page created by draft-ietf-quic-transport or should a new registry page for HTTP/3 be created separate from the registry for QUIC?

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

First, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs on the Transport Layer Security (TLS) Extensions registry page located at:

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

a single, new registration will be made as follows:

Protocol: HTTP/3
Identification Sequence: 0x68 0x33 ("h3")
Specification: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the HTTP/3 Frame Type registry. The registry will be created on a registry page to be decided as a result of the answer to the question from IANA above.

IANA will add a note to the registry indicating that: " each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) are reserved."

IANA Question --> are those values to be marked as reserved in the new registry?

The registration policy for the new registry is as follows:

0x00 - 0x3f - Standards Action or IESG Approval
0x40 - 3FFFFFFFFFFFFFFF - Specification Required

There are initial registrations in the new registry as follows:

+==============+=======+=============================+
| Frame Type | Value | Specification |
+==============+=======+=============================+
| DATA | 0x0 | [ RFC-to-be Section 7.2.1 ] |
+--------------+-------+-----------------------------+
| HEADERS | 0x1 | [ RFC-to-be Section 7.2.2 ] |
+--------------+-------+-----------------------------+
| Reserved | 0x2 | N/A |
+--------------+-------+-----------------------------+
| CANCEL_PUSH | 0x3 | [ RFC-to-be Section 7.2.3] |
+--------------+-------+-----------------------------+
| SETTINGS | 0x4 | [ RFC-to-be Section 7.2.4 ] |
+--------------+-------+-----------------------------+
| PUSH_PROMISE | 0x5 | [ RFC-to-be Section 7.2.5 ] |
+--------------+-------+-----------------------------+
| Reserved | 0x6 | N/A |
+--------------+-------+-----------------------------+
| GOAWAY | 0x7 | [ RFC-to-be Section 7.2.6 ] |
+--------------+-------+-----------------------------+
| Reserved | 0x8 | N/A |
+--------------+-------+-----------------------------+
| Reserved | 0x9 | N/A |
+--------------+-------+-----------------------------+
| MAX_PUSH_ID | 0xd | [ RFC-to-be Section 7.2.7 ] |
+--------------+-------+-----------------------------+

Third, a new registry is to be created called the HTTP/3 Settings registry. The registry will be created on a registry page to be decided as a result of the answer to the question from IANA above.

IANA will add a note to the registry indicating that: " each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFF) are reserved."

IANA Question --> are those values to be marked as reserved in the new registry?

The registration policy for the new registry is as follows:

0x00 - 0x3f - Standards Action or IESG Approval
0x40 - 3FFFFFFFFFFFFFFF - Specification Required

There are initial registrations in the new registry as follows:

+========================+=======+===============================+===========+
| Setting Name | Value | Specification | Default |
+========================+=======+===============================+===========+
| Reserved | 0x2 | N/A | N/A |
+------------------------+-------+-------------------------------+-----------+
| Reserved | 0x3 | N/A | N/A |
+------------------------+-------+-------------------------------+-----------+
| Reserved | 0x4 | N/A | N/A |
+------------------------+-------+-------------------------------+-----------+
| Reserved | 0x5 | N/A | N/A |
+------------------------+-------+-------------------------------+-----------+
| MAX_FIELD_SECTION_SIZE | 0x6 | [ RFC-to-be Section 7.2.4.1 ] | Unlimited |
+------------------------+-------+-------------------------------+-----------+

Fourth, a new registry is to be created called the HTTP/3 Error Code registry. The registry will be created on a registry page to be decided as a result of the answer to the question from IANA above.

IANA will add a note to the registry indicating that: " each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFF) are reserved."

IANA Question --> are those values to be marked as reserved in the new registry?

The registration policy for the new registry is as follows:

0x00 - 0x3f - Standards Action or IESG Approval
0x40 - 3FFFFFFFFFFFFFFF - Specification Required

There are initial registrations in the new registry as follows:

+===========================+========+==============+=============================+
| Name | Value | Description | Specification |
+===========================+========+==============+=============================+
| H3_NO_ERROR | 0x0100 | No error | [ RFC-to-be Section 8.1 ] |
+---------------------------+--------+--------------+-----------------------------+
| H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General | [ RFC-to-be Section 8.1 ] |
| | | protocol | |
| | | error | |
+---------------------------+--------+--------------+-----------------------------+
| H3_INTERNAL_ERROR | 0x0102 | Internal | [ RFC-to-be Section 8.1 ] |
| | | error | |
+---------------------------+--------+--------------+-----------------------------+
| H3_STREAM_CREATION_ERROR | 0x0103 | Stream | [ RFC-to-be Section 8.1 ] |
| | | creation | |
| | | error | |
+---------------------------+--------+--------------+-----------------------------+
| H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical | [ RFC-to-be Section 8.1 ] |
| | | stream was | |
| | | closed | |
+---------------------------+--------+--------------+-----------------------------+
| H3_FRAME_UNEXPECTED | 0x0105 | Frame not | [ RFC-to-be Section 8.1 ] |
| | | permitted | |
| | | in the | |
| | | current | |
| | | state | |
+---------------------------+--------+--------------+-----------------------------+
| H3_FRAME_ERROR | 0x0106 | Frame | [ RFC-to-be Section 8.1 ] |
| | | violated | |
| | | layout or | |
| | | size rules | |
+---------------------------+--------+--------------+-----------------------------+
| H3_EXCESSIVE_LOAD | 0x0107 | Peer | [ RFC-to-be Section 8.1 ] |
| | | generating | |
| | | excessive | |
| | | load | |
+---------------------------+--------+--------------+-----------------------------+
| H3_ID_ERROR | 0x0108 | An | [ RFC-to-be Section 8.1 ] |
| | | identifier | |
| | | was used | |
| | | incorrectly | |
+---------------------------+--------+--------------+-----------------------------+
| H3_SETTINGS_ERROR | 0x0109 | SETTINGS | [ RFC-to-be Section 8.1 ] |
| | | frame | |
| | | contained | |
| | | invalid | |
| | | values | |
+---------------------------+--------+--------------+-----------------------------+
| H3_MISSING_SETTINGS | 0x010a | No SETTINGS | [ RFC-to-be Section 8.1 ] |
| | | frame | |
| | | received | |
+---------------------------+--------+--------------+-----------------------------+
| H3_REQUEST_REJECTED | 0x010b | Request not | [ RFC-to-be Section 8.1 ] |
| | | processed | |
+---------------------------+--------+--------------+-----------------------------+
| H3_REQUEST_CANCELLED | 0x010c | Data no | [ RFC-to-be Section 8.1 ] |
| | | longer | |
| | | needed | |
+---------------------------+--------+--------------+-----------------------------+
| H3_REQUEST_INCOMPLETE | 0x010d | Stream | [ RFC-to-be Section 8.1 ] |
| | | terminated | |
| | | early | |
+---------------------------+--------+--------------+-----------------------------+
| H3_CONNECT_ERROR | 0x010f | TCP reset | [ RFC-to-be Section 8.1 ] |
| | | or error on | |
| | | CONNECT | |
| | | request | |
+---------------------------+--------+--------------+-----------------------------+
| H3_VERSION_FALLBACK | 0x0110 | Retry over | [ RFC-to-be Section 8.1 ] |
| | | HTTP/1.1 | |
+---------------------------+--------+--------------+-----------------------------+

Fifth, a new registry is to be created called the HTTP/3 Stream Types registry. The registry will be created on a registry page to be decided as a result of the answer to the question from IANA above.

The registration policy for the new registry is as follows:

0x00 - 0x3f - Standards Action or IESG Approval
0x40 - 3FFFFFFFFFFFFFFF - Specification Required

IANA will put a note in the new registry that indicates that each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through
0x3ffffffffffffffe) will not be assigned by IANA.

There are initial registrations in the new registry as follows:

+================+=======+=============================+========+
| Stream Type | Value | Specification | Sender |
+================+=======+=============================+========+
| Control Stream | 0x00 | [ RFC-to-be Section 6.2.1 ] | Both |
+----------------+-------+-----------------------------+--------+
| Push Stream | 0x01 | [ RFC-to-be Section 4.4 ] | Server |
+----------------+-------+-----------------------------+--------+

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
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-11-16):

From: The IESG
To: IETF-Announce
CC: magnus.westerlund@ericsson.com, lucaspardue.24.7@gmail.com, draft-ietf-quic-http@ietf.org, quic-chairs@ietf.org, quic@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Hypertext Transfer Protocol Version 3 (HTTP/3)) to Proposed Standard


The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'Hypertext Transfer Protocol Version 3 (HTTP/3)'
  as Proposed Standard

This document is part of a combined 26-day last call for multiple
related documents that defines the QUIC protocol and the HTTP mapping
onto QUIC. The documents are:

  - draft-ietf-quic-transport
  - draft-ietf-quic-recovery
  - draft-ietf-quic-tls
  - draft-ietf-quic-invariants
  - draft-ietf-quic-http
  - draft-ietf-quic-qpack

Due to its GitHub-centric work style, the QUIC WG requests that LC review
comments are individually filed as issues in the WG repository at
https://github.com/quicwg/base-drafts if at all possible. A summary email may with
URLs to the individual issue should then also be sent to the relevant mailing list
(primarily last-call@ietf.org and quic@ietf.org).

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 2020-11-16. 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 QUIC transport protocol has several features that are desirable
  in a transport for HTTP, such as stream multiplexing, per-stream flow
  control, and low-latency connection establishment.  This document
  describes a mapping of HTTP semantics over QUIC.  This document also
  identifies HTTP/2 features that are subsumed by QUIC, and describes
  how HTTP/2 extensions can be ported to HTTP/3.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-httpbis-semantics: HTTP Semantics (None - IETF stream)
    draft-ietf-httpbis-cache: HTTP Caching (None - IETF stream)

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.

Shepherd Writeup for QUIC "base drafts"1. SummaryThis publication requests covers the following I-Ds that together define
the QUIC protocol:-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.2. Document Announcement Write-UpTechnical Summary:QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.Working Group Summary:As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.Document Quality:There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.Personnel:The document shepherds for the individual I-Ds are:-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11The responsible AD for the document set is Magnus Westerlund.3. Document Shepherd ReviewThe document shepherds extensively reviewed the documents before this
publication request.4. Document Shepherd Review ConcernsThe document shepherds have no concerns about the depth or breadth of
the reviews for these documents.5. Broader ReviewsParts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.6. Document Shepherd General ConcernsThe document shepherds have no general concerns about these documents.7. IPR Disclosure ObligationThe editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.8. Filed IPR Disclosuresdraft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.9. Strength of ConsensusThe consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.10. DiscontentNo discontent was voiced.11. Document NitsThe IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it's difficult to ascertain
whether its results are accurate (there are many "Failure fetching the
file, proceeding without it." errors).12. Formal Review CriteriaNo formal review requirements are applicable to this document set.13. Split ReferencesAll references within this document set have been identified as either
normative or informative.14. Normative ReferencesThe document set contains the following normative references to I-Ds:-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semanticsAll of these are on track for timely publication in their respective
WGs.15. Downward ReferencesThe TLS document has the following downrefs: * RFC8439 (CHACHA) * AES16. RFC Status ChangesPublication of this document set will not change the status of any
existing RFCs.17. IANA Considerations ReviewThe IANA considerations of the document set have been reviewed and no
issues were identified.18. New "Expert Review" RegistriesThe document set defines several IANA registries that allow for
"Provisional Registrations" and "Permanent Registrations", which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.19. Validation of Formal Language PartsNo formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.20. YANGThe document set does not contain a YANG model.