Fwd: [IANA #1180847] Last Call: <draft-ietf-quic-http-32.txt> (Hypertext Transfer Protocol Version 3 (HTTP/3)) to Proposed Standard

[Lars Eggert <[e-mail]>]

Forwarding Mike's response to the list, to there is an archive to link to.

Lars

> Begin forwarded message:
> 
> From: Mike Bishop <[e-mail]>
> Subject: RE: [IANA #1180847] Last Call: <draft-ietf-quic-http-32.txt> (Hypertext Transfer Protocol Version 3 (HTTP/3)) to Proposed Standard
> Date: December 3, 2020 at 22:22:54 GMT+2
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Jana Iyengar <[e-mail]>
> 
> I don't believe I've seen anything else on this thread.  There is a separate
> issue filed during Last Call,
> https://github.com/quicwg/base-drafts/issues/4387, suggesting that we reduce
> the number of greasing codepoints reserved.  However, I think the same
> questions (and same answer) apply regardless of what happens there -- we don't
> want the reserved ranges to be present in the registry, but we do want IANA
> never to give those out.  We have an open issue that either needs to be closed
> because this is agreeable or resolved by changing the documents.
> 
> -----Original Message-----
> From: Mike Bishop
> Sent: Tuesday, November 17, 2020 4:00 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Jana Iyengar <[e-mail]>
> Subject: RE: [IANA #1180847] Last Call: <draft-ietf-quic-http-32.txt>
> (Hypertext Transfer Protocol Version 3 (HTTP/3)) to Proposed Standard
> 
> Thanks for the review!
> 
> With regard to the GREASE values (the questions below), we specifically did
> not want the values shown as Reserved for two different reasons.  First, as a
> practical matter, 148 quadrillion reserved entries would be difficult to list
> on the page and will drown any actual reservations.  Second, the point of
> these values is that an implementer should be following the guidance to ignore
> unknown values; having an explicit list encourages an explicitly defined
> reaction.
> 
> The intent, which we wanted to confirm was possible, was simply to say that
> IANA should not accept registrations for these values.  That feels
> functionally equivalent to Reserved; if it's possible to be "reserved but not
> listed," that's a reasonable implementation.  If it's necessary to have the
> note present, I prefer the "will not be assigned by IANA" language you've used
> for the Error Code registry over noting them as Reserved.
> 
> These questions will apply to QUIC Transport as well, which contains similar
> language for its registries, so I've copied the editors for that document as
> well.
> 
> To the other items:
> - I believe the HTTP/3 registries should be a group separate from the QUIC
> registries; having them fall immediately after the group of HTTP/2 registries
> seems like a sensible outcome.
> - I will send an e-mail to [e-mail] to initiate the review of
> the H3 ALPN token.
> 
> -----Original Message-----
> From: Sabrina Tanamal via RT <[e-mail]>
> Sent: Monday, November 16, 2020 2:39 PM
> Cc: [e-mail]; Mike Bishop <[e-mail]>; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: [IANA #1180847] Last Call: <draft-ietf-quic-http-32.txt> (Hypertext
> Transfer Protocol Version 3 (HTTP/3)) to Proposed Standard
> 
> (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/
> 
> 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
> 
> (END IANA COMMENTS)
>