From nobody Mon Nov 16 21:50:40 2020 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8EE3A0E78 for ; Mon, 16 Nov 2020 21:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJWINKi1Smnw for ; Mon, 16 Nov 2020 21:50:34 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8963A0E77 for ; Mon, 16 Nov 2020 21:50:33 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:f87a:925d:978e:33a7] (unknown [IPv6:2a00:ac00:4000:400:f87a:925d:978e:33a7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 69400610639 for ; Tue, 17 Nov 2020 07:50:24 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1605592224; bh=Ipj2/FrVNWjA8Wr6uN+4a1Y1AasRtpd0C4eOYLve7y0=; h=From:Subject:References:To:Date; b=0nFz4VHb50tnA9TduHJxRsobzuqp/pvzgREcF3nQYnwjnd/efBH84u6H9RienIGmb MBooany37Btj3Cf//3mI8BzfZTBMzDmyy8FAWcEn39zWqvVdJsqQzB+Hud8QC9kkJj 5o12GLP7l455t6cZ8YCwIAhfd3M0/bqKAnfwXxXA= From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_34683931-C74A-4DEF-8B9C-757A7C07FA2A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Fwd: [IANA #1180847] Last Call: (Hypertext Transfer Protocol Version 3 (HTTP/3)) to Proposed Standard Message-Id: References: To: QUIC WG Date: Tue, 17 Nov 2020 07:50:23 +0200 X-MailScanner-ID: 69400610639.A213B X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 05:50:38 -0000 --Apple-Mail=_34683931-C74A-4DEF-8B9C-757A7C07FA2A Content-Type: multipart/alternative; boundary="Apple-Mail=_17358255-C2DB-4DDA-B3CD-3EE0B3075A88" --Apple-Mail=_17358255-C2DB-4DDA-B3CD-3EE0B3075A88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Begin forwarded message: >=20 > From: "Sabrina Tanamal via RT" > Subject: [IANA #1180847] Last Call: = (Hypertext Transfer Protocol Version 3 (HTTP/3)) to Proposed Standard > Date: November 16, 2020 at 21:38:41 GMT+2 > Cc: iesg@ietf.org, mbishop@evequefou.be, lars@eggert.org, = lucaspardue.24.7@gmail.com, magnus.westerlund@ericsson.com, = martin.h.duke@gmail.com, quic-chairs@ietf.org > Resent-From: > Resent-To: lucaspardue.24.7@gmail.com, lars@eggert.org > Reply-To: drafts-lastcall@iana.org >=20 > (BEGIN IANA COMMENTS) >=20 > IESG/Authors/WG Chairs: >=20 > 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. >=20 > 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. >=20 > The IANA Functions Operator has questions about the actions requested = in the IANA Considerations section of this document. >=20 > 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? >=20 > The IANA Functions Operator understands that, upon approval of this = document, there are five actions which we must complete. >=20 > First, in the TLS Application-Layer Protocol Negotiation (ALPN) = Protocol IDs on the Transport Layer Security (TLS) Extensions registry = page located at: >=20 > https://www.iana.org/assignments/tls-extensiontype-values/ >=20 > a single, new registration will be made as follows: >=20 > Protocol: HTTP/3 > Identification Sequence: 0x68 0x33 ("h3") > Specification: [ RFC-to-be ] >=20 > 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." >=20 > 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. >=20 > 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." >=20 > IANA Question --> are those values to be marked as reserved in the new = registry? >=20 > The registration policy for the new registry is as follows: >=20 > 0x00 - 0x3f - Standards Action or IESG Approval > 0x40 - 3FFFFFFFFFFFFFFF - Specification Required >=20 > There are initial registrations in the new registry as follows: >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D+ > | Frame Type | Value | Specification | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D+ > | 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 ] | > +--------------+-------+-----------------------------+ >=20 > 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. >=20 > 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." >=20 > IANA Question --> are those values to be marked as reserved in the new = registry? >=20 > The registration policy for the new registry is as follows: >=20 > 0x00 - 0x3f - Standards Action or IESG Approval > 0x40 - 3FFFFFFFFFFFFFFF - Specification Required >=20 > There are initial registrations in the new registry as follows: >=20 > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= > | Setting Name | Value | Specification | Default | > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= > | 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 | > = +------------------------+-------+-------------------------------+--------= ---+ >=20 > 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. >=20 > 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." >=20 > IANA Question --> are those values to be marked as reserved in the new = registry? >=20 > The registration policy for the new registry is as follows: >=20 > 0x00 - 0x3f - Standards Action or IESG Approval > 0x40 - 3FFFFFFFFFFFFFFF - Specification Required >=20 > There are initial registrations in the new registry as follows: >=20 > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ > | Name | Value | Description | Specification | > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+ > | 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 | | > = +---------------------------+--------+--------------+---------------------= --------+ >=20 > 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. >=20 > The registration policy for the new registry is as follows: >=20 > 0x00 - 0x3f - Standards Action or IESG Approval > 0x40 - 3FFFFFFFFFFFFFFF - Specification Required >=20 > 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. >=20 > There are initial registrations in the new registry as follows: >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+ > | Stream Type | Value | Specification | Sender | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+ > | Control Stream | 0x00 | [ RFC-to-be Section 6.2.1 ] | Both | > +----------------+-------+-----------------------------+--------+ > | Push Stream | 0x01 | [ RFC-to-be Section 4.4 ] | Server | > +----------------+-------+-----------------------------+--------+ >=20 > The IANA Functions Operator understands that these are the only = actions required to be completed upon approval of this document. >=20 > 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. >=20 > Thank you, >=20 > Sabrina Tanamal > Senior IANA Services Specialist >=20 > (END IANA COMMENTS) >=20 --Apple-Mail=_17358255-C2DB-4DDA-B3CD-3EE0B3075A88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Begin forwarded message:

From: = "Sabrina Tanamal via RT" <drafts-lastcall@iana.org>
Subject: = [IANA #1180847] = Last Call: <draft-ietf-quic-http-32.txt> (Hypertext Transfer = Protocol Version 3 (HTTP/3)) to Proposed Standard
Date: = November 16, 2020 at 21:38:41 = GMT+2
Cc: = iesg@ietf.org, mbishop@evequefou.be, lars@eggert.org, lucaspardue.24.7@gmail.com, magnus.westerlund@ericsson.com, martin.h.duke@gmail.com, quic-chairs@ietf.org
Resent-From: = <alias-bounces@ietf.org>
Resent-To: = lucaspardue.24.7@gmail.com, lars@eggert.org
Reply-To: = drafts-lastcall@iana.org

(BEGIN IANA COMMENTS)

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/<= br class=3D"">
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:

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+
| Frame Type | Value | Specification |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+
| 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:

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+
| Setting Name | Value | Specification | = Default |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+
| 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:

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+
| Name | Value | Description | = Specification |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+
| 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:

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+
| Stream Type = | Value | Specification | Sender |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+
| 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

(END IANA COMMENTS)


= --Apple-Mail=_17358255-C2DB-4DDA-B3CD-3EE0B3075A88-- --Apple-Mail=_34683931-C74A-4DEF-8B9C-757A7C07FA2A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl+zZJ8ACgkQVLXDCb9w wVfalQ/+KvhShyv0CHFjENWZ1JZLgrmJuWJlRH6AHGHS2zADIMRAFsl2AFLKIyb6 ccL7/vp2CyM4VnQ+LrqVVZeCWGP5pDstcexwBB6UW4RDWOfXH6FYJELjcV4ApJTj 4rXZntqXHkteUUpdiBQRW83ntHX0OSUF3byaHzbuEz2cuJ2csnVlhrQeirG5oijL v7mik+/Y/0EuVPpWWVK9lDa1/zGiyWXFM+WCIfCVW1Y9TVfp+z0c3gGK+V53V4bb 6RPQVwRQGNaczBKPRQX5U2UPEBcIow/uaDXtn7X43AVeiq89Kf6WeyBvORrBvpBR dFpVOTtknQ0oxhQMusQrNimmMTctq1QXM5+1/kS6rXoq54TUpLvSjC6dpku23qkK 1jyBy2IVJmpE25DG0agTVs6Ah0pUNnTYctVIyz4WR/BBUlqL2wF1LWc/agCQEq7x 5+5uKzgwQrge9MJCL4DPtH41UmUC9SEDfAgmLeMhsrLq0++HaKaovtFH2hWYLV5G qzWCfnsmyW81LQm18/qyejD6o6M+sEfoUSW99MbjU7PVJ0gP8DIz81KYvkB/4ruQ Bhm/LjqBqxN1HA5GJfFLS1tHRuP8magf4HJpb4TpLrK5C39QNj7Lcuu42lBgxNN/ Ppmx1BAcQTgOUAO/VAixG/3lRoMe6YzJvjG0H/kmSY5DUO5mTiE= =bpz/ -----END PGP SIGNATURE----- --Apple-Mail=_34683931-C74A-4DEF-8B9C-757A7C07FA2A--