Original text:
22.  22.1. <del> IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" under a "QUIC Protocol" heading. </del>  <del> The "QUIC Transport Parameters" registry governs a 16-bit space. This space is split into two spaces that are governed by different policies.  Values with the first byte in the range 0x00 to 0xfe (in hexadecimal) are assigned via the Specification Required policy RFC8126.  Values with the first byte 0xff are reserved for Private Use RFC8126. </del>  <del> Registrations MUST include the following fields: </del>  <del> The numeric value of the assignment (registrations will be between 0x0000 and 0xfeff). </del>  <del> A short mnemonic for the parameter. </del>  A reference to a publicly available specification for the value. <del> The nominated expert(s) verify that a specification exists and is readily accessible.  Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious). </del>  The initial contents of this registry are shown in iana-tp-table. Additionally, each value of the format "31 * N + 27" for integer <del> values of N (that is, "27", "58", "89", ...) MUST NOT be assigned by IANA. </del>  <del> 22.2. </del>  IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a <del> "QUIC Protocol" heading. </del>  <del> The "QUIC Frame Types" registry governs a 62-bit space.  This space is split into three spaces that are governed by different policies. Values between 0x00 and 0x3f (in hexadecimal) are assigned via the Standards Action or IESG Review policies RFC8126.  Values from 0x40 to 0x3fff operate on the Specification Required policy RFC8126.  All other values are assigned to Private Use RFC8126. </del>  <del> Registrations MUST include the following fields: The numeric value of the assignment (registrations will be between 0x00 and 0x3fff).  A range of values MAY be assigned. </del>  A short mnemonic for the frame type. <del> A reference to a publicly available specification for the value. The nominated expert(s) verify that a specification exists and is readily accessible.  Specifications for new registrations need to describe the means by which an endpoint might determine that it can send the identified type of frame.  An accompanying transport parameter registration (see iana-transport-parameters) is expected for most registrations.  The specification needs to describe the </del>  format and assigned semantics of any fields in the frame. <del> Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious). </del> The initial contents of this registry are tabulated in frame-types. <del> 22.3. </del>  IANA [SHALL add/has added] a registry for "QUIC Transport Error <del> Codes" under a "QUIC Protocol" heading. </del>  The "QUIC Transport Error Codes" registry governs a 62-bit space. This space is split into three spaces that are governed by different <del> policies.  Values between 0x00 and 0x3f (in hexadecimal) are assigned via the Standards Action or IESG Review policies RFC8126.  Values from 0x40 to 0x3fff operate on the Specification Required policy RFC8126.  All other values are assigned to Private Use RFC8126. Registrations MUST include the following fields: </del>  <del> The numeric value of the assignment (registrations will be between 0x0000 and 0x3fff). </del>  A short mnemonic for the parameter. A brief description of the error code semantics, which MAY be a summary if a specification reference is provided. <del> A reference to a publicly available specification for the value. The nominated expert(s) verify that a specification exists and is readily accessible.  Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious). </del> The initial contents of this registry are shown in iana-error-table. 11.  11.1. This document creates a new registration for the identification of 11.2.  This document establishes a registry for HTTP/3 frame type codes. <del> The "HTTP/3 Frame Type" registry governs a 62-bit space.  This space is split into three spaces that are governed by different policies. Values between "0x00" and "0x3f" (in hexadecimal) are assigned via the Standards Action or IESG Review policies RFC8126.  Values from "0x40" to "0x3fff" operate on the Specification Required policy RFC8126.  All other values are assigned to Private Use RFC8126. </del>  While this registry is separate from the "HTTP/2 Frame Type" registry defined in HTTP2, it is preferable that the assignments parallel each one registry, every effort SHOULD be made to avoid assigning the corresponding value to an unrelated operation. <del> New entries in this registry require the following information: </del>  A name or label for the frame type. <del> The 62-bit code assigned to the frame type. </del>  <del> A reference to a specification that includes a description of the frame layout and its semantics, including any parts of the frame that are conditionally present. The entries in the following table are registered by this document. </del>  Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. <del> 11.3. </del>  This document establishes a registry for HTTP/3 settings.  The <del> "HTTP/3 Settings" registry governs a 62-bit space.  This space is split into three spaces that are governed by different policies. Values between "0x00" and "0x3f" (in hexadecimal) are assigned via the Standards Action or IESG Review policies RFC8126.  Values from "0x40" to "0x3fff" operate on the Specification Required policy RFC8126.  All other values are assigned to Private Use RFC8126.  The designated experts are the same as those for the "HTTP/2 Settings" registry defined in HTTP2. </del>  While this registry is separate from the "HTTP/2 Settings" registry defined in HTTP2, it is preferable that the assignments parallel each SHOULD be made to avoid assigning the corresponding value to an unrelated operation. <del> New registrations are advised to provide the following information: </del>  A symbolic name for the setting.  Specifying a setting name is optional. <del> The 62-bit code assigned to the setting. </del>  <del> An optional reference to a specification that describes the use of the setting. The value of the setting unless otherwise indicated.  SHOULD be the most restrictive possible value. The entries in the following table are registered by this document. </del>  Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. <del> 11.4. </del>  This document establishes a registry for HTTP/3 error codes.  The <del> "HTTP/3 Error Code" registry manages a 62-bit space.  The "HTTP/3 Error Code" registry operates under the "Expert Review" policy RFC8126. </del>  Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new registrations for possible duplication with existing error codes. Use of existing registrations is to be encouraged, but not mandated. <del> New registrations are advised to provide the following information: </del>  A name for the error code.  Specifying an error code name is optional. <del> The 62-bit error code value. A brief description of the error code semantics, longer if no detailed specification is provided. </del>  <del> An optional reference for a specification that defines the error code. The entries in the following table are registered by this document. </del>  <del> 11.5. </del>  This document establishes a registry for HTTP/3 unidirectional stream types.  The "HTTP/3 Stream Type" registry governs a 62-bit space. <del> This space is split into three spaces that are governed by different policies.  Values between "0x00" and 0x3f (in hexadecimal) are assigned via the Standards Action or IESG Review policies RFC8126. Values from "0x40" to "0x3fff" operate on the Specification Required policy RFC8126.  All other values are assigned to Private Use RFC8126. </del>  <del> New entries in this registry require the following information: </del>  A name or label for the stream type. <del> The 62-bit code assigned to the stream type. A reference to a specification that includes a description of the stream type, including the layout semantics of its payload. </del> Which endpoint on a connection may initiate a stream of this type. Values are "Client", "Server", or "Both".  The entries in the following table are registered by this document. Additionally, each code of the format "0x1f * N + 0x21" for integer

Reviewer comments:
This overhauls the system for IANA registries to use a unified scheme that allows provisional registration. This seems pretty complicated in terms of nailing down all the corner cases, but it is fairly simple in practice: Provisional registration is easy, it only requires that the requester provide contact information and (ideally) the codepoint they want. They could provide more, but at their discretion. Permanent registration requires that you fill out the fields. Experts are required for both, but only really to prevent spam. We have a few more requirements for permanent registrations of frame types, but that is more for the purposes of advice, because sending an new frame leads to protocol errors if you haven't agreed to that in the past. I've sketched out a strawman for a codepoint reclamation process. That advises that experts try to find some use of the codepoint. There is a date on registrations that can guide the selection of codepoints to reclaim, but these can be updated any time by anyone who wants to keep the registration "live". I wanted to sketch this out for transport first, but I intend to update this PR with changes to the HTTP draft if these policies are agreeable.
Could contact information be replaced with a domain name. There is much abuse of contact information and domain names can have private contact information? Also, maintaining an email address is harder over time. I realize the field contact field doesn't say email, but that is sort of implied.
You can specify this so that IANA collects the information and thus can follow up if needed, but where the registry does not display this information. I understand that the authors of RFC 8126 are working on a bis that will make this much more common, if not the default. You can also split the contact information from the change controller, if you want to have, say Joe be the contact but Example Corp be the change controller. There's also a presumption that if the change controller is gone that the change controller for the entire registry (usually the IESG) can make a determination of what to do in the case that a change is needed. For many registries this amounts to "do nothing" since there is no scarcity of code points. In the case of scarcity, that's how you get re-use when the change controllers are gone. Ted
I did that intentionally, mostly just to avoid the wordy reference. I'm happy to defer to you on that. (Julian can say "told you so" again if he likes :)
We have nice registration policies for everything, but that doesn't serve for experimentation very well, because those experiments can clobber each other. See also RFC 6648. The proposal here is to allow for permanent registrations (under the same rules we have now), but to allow FCFS provisional registrations so that we avoid collisions when people start experiments that could be widely deployed. We should also encourage people to choose random values rather than sequential ones.
Does resolve this?
As of , transport parameter identifiers are 16bit integers, with a registry where uses the is reserved for experimentation While keeping Specification Required makes sense for a good chunk of the registry space, I think there will be many experiments that are conducted before a full specification is written (some already exist today and I expect there to be many many more once the protocol is standardized). However, those experiments only have 256 values to play with, and that is bound to cause collisions and headaches down the road. I think the simplest solution to this problem is to use variable length integers for transport parameter identifiers. The TLS presentation language doesn't support them but since we already use VLIs for the values of several transport parameters we're no longer bound by the TLS presentation language. I think there was also support for doing this when it was discussed on , but that issue was closed when the values were changed to VLI with , without changing the identifiers. I'm happy to write the PR if this issue gathers support.
You aren't the first to suggest this one. Let's make sure we at least discuss this directly. We did discuss this in the context of the issues that you cite and decided not to, but that was never the central question. From our perspective, this isn't a significant change to code.
The same for us, too. Am I understanding correctly that the concern here is that extensions of TLS structures tend to use uint16_t as their type identifiers, and that the reusable parser might be constrained to that design pattern?
I thought that this might be the case originally, but it turns out that the blob for transport parameters is generated by QUIC code in mostly all of the cases I have seen. If there is someone out there who is relying on passing a TLS stack a structured grammar and letting the TLS stack perform serialization, then we might want to just leave this alone.
Thank you for the clarification. We do use the TLS stack to encode / decode the transport parameters, therefore we do want see the TLS grammar-based design being preserved. The reason we do not mind the extension type being a varint is because our codec is flexible enough to handle that. URL
We should definitely do something to increase the number of experimentation codepoints from 256. Changing to a varint sounds good. If not, then we should allocate more of the space(ie: [0xf000 - 0xffff]) to experiments.
I agree with NAME and I don't think we need to go varint here, that seems like a bit of an overkill. How about reserving 4096 codepoints for spec required, and leaving the rest (2^16 - 2^12 = 61440) for experimentation: [0x0000 - 0x0fff] uses the RFC8128 Specification Required policy [0x1000 - 0xffff] is reserved for experimentation
Apart from the fact that we want to limit changes at this stage, are there arguments against going varint here? It feels pretty odd that many transport parameters are TLVs where T and L are 16bit and V is varint.
I don't have much of an argument here besides the general principle that we shouldn't provide more flexibility than is necessary. I don't think it's odd that T is fixed-length while the V is varint, FWIW. If no implementations are bothered by the change to varint, then it's a bit of a bikeshed. Let's see if other implementers are bothered.
Split in two ? what the same size ? Don't forget there is also GREASE TP now
From looking at all the integer fields in QUICv1, it looks like at this point everything is a varint except the versions, packet numbers, connection ID lengths (which all have valid reasons for their lengths), and the transport parameter identifier and transport parameter lengths. Switching transport parameters to QUIC format (as opposed to TLS presentation language) feels fitting to me, saves bytes on the wire, and will facilitate innovation down the road.
I'm happy to make transport parameter identifier a varint. NAME Are you(implicitly) suggesting that transport parameter lengths should be varint as well?
I think so, yes. If we're changing implementations might as well make both changes at once (assuming no one wants one of them to be varint but not the other).
I'd be opposed to changing the transport parameter lengths to varints, as that means departure from the TLS notation that we use for defining TPs. It's very different from changing the IDs to varints, which is just changing the type of a particular variable. IIRC, we discussed if we should switch to a different notation, and decided to go with the TLS-based design. At least I have built (or maintained) code based on that.
I agree with Kazuho here: splitting it in half would make plenty of room
I'm in favor of the change that NAME is suggesting in . There's no reason for us to use TLS presentation language, if anything, it just makes the spec harder to read for people who are unfamiliar with the TLS presentation language (if I remember correctly, this came up multiple times on issues here and / or on Slack).
Remember the experience with the X-Options in SMTP or HTML? Do we really want to replicate that?
Discussed in Cupertino. NAME to open a new Editorial issue to only replace the TLS syntax with something easier to understand. NAME to also do a Design PR to shuffle the assigned ranges in the registry.
As discussed in Cupertino, I have closed previous PR and replaced it with: editorial-only PR IANA policy PR
I think that the RFC 6648 lessons need to be considered carefully here. I think that it would be better to use a combination of random selection and provisional registration as a means of handling experiments. Random selection means that we end up colliding with very low probability; provisional registration ensures that registrations are protected. Making the private use space larger does neither. I would prefer to instead remove the private use space completely.
In lots of places, you reference {{iana-policy}} for things that aren't actually described there -- it just contains a pointer to the QUIC spec for the policy. It might be better to point directly to the QUIC spec in those places. (Though given that the section number in QUIC could potentially change, it's also a reasonable argument that we want to have one place to update.) Just want to make sure that's intentional, rather than a copy-paste of the policy from the QUIC registries.

Revised text:
22. <ins> This document establishes several registries for the management of codepoints in QUIC.  These registries operate on a common set of policies as defined in iana-policy. </ins> 22.1.  <ins> All QUIC registries allow for both provisional and permanent registration of codepoints.  This section documents policies that are common to these registries. </ins>  <ins> 22.1.1. </ins>  <ins> Provisional registration of codepoints are intended to allow for private use and experimentation with extensions to QUIC.  Provisional registrations only require the inclusion of the codepoint value and contact information.  However, provisional registrations could be reclaimed and reassigned for another purpose. </ins>  <ins> Provisional registrations require Expert Review, as defined in Section 4.5 of RFC8126.  Designated expert(s) are advised that only registrations for an excessive proportion of remaining codepoint space or the very first unassigned value (see iana-random) can be rejected. </ins>  <ins> Provisional registrations will include a date field that indicates when the registration was last updated.  A request to update the date on any provisional registration can be made without review from the designated expert(s). All QUIC registries include the following fields to support provisional registration: The assigned codepoint. "Permanent" or "Provisional". </ins> A reference to a publicly available specification for the value.  <ins> The date of last update to the registration. Contact details for the registrant. Supplementary notes about the registration. Provisional registrations MAY omit the Specification and Notes fields, plus any additional fields that might be required for a permanent registration.  The Date field is not required as part of requesting a registration as it is set to the date the registration is created or updated. 22.1.2. New uses of codepoints from QUIC registries SHOULD use a randomly selected codepoint that excludes both existing allocations and the first unallocated codepoint in the selected space.  Requests for multiple codepoints MAY use a contiguous range.  This minimizes the risk that differing semantics are attributed to the same codepoint by different implementations.  Use of the first codepoint in a range is intended for use by specifications that are developed through the standards process STD and its allocation MUST be negotiated with IANA before use. For codepoints that are encoded in variable-length integers (integer- encoding), such as frame types, codepoints that encode to four or eight bytes (that is, values 2^14 and above) SHOULD be used unless the usage is especially sensitive to having a longer encoding. Applications to register codepoints in QUIC registries MAY include a codepoint as part of the registration.  IANA MUST allocate the selected codepoint unless that codepoint is already assigned or the codepoint is the first unallocated codepoint in the registry. 22.1.3. A request might be made to remove an unused provisional registration from the registry to reclaim space in a registry, or portion of the registry (such as the 64-16383 range for codepoints that use variable-length encodings).  This SHOULD be done only for the codepoints with the earliest recorded date and entries that have been updated less than a year prior SHOULD NOT be reclaimed. A request to remove a codepoint MUST be reviewed by the designated expert(s).  The expert(s) MUST attempt to determine whether the codepoint is still in use.  Experts are advised to contact the listed contacts for the registration, plus as wide a set of protocol implementers as possible in order to determine whether any use of the codepoint is known.  The expert(s) are advised to allow at least four weeks for responses. If any use of the codepoints is identified by this search or a request to update the registration is made, the codepoint MUST NOT be reclaimed.  Instead, the date on the registration is updated.  A note might be added for the registration recording relevant information that was learned. If no use of the codepoint was identified and no request was made to update the registration, the codepoint MAY be removed from the registry. This process also applies to requests to change a provisional registration into a permanent registration, except that the goal is not to determine whether there is no use of the codepoint, but to determine that the registration is an accurate representation of any deployed usage. 22.1.4. Permanent registrations in QUIC registries use the Specification Required policy RFC8126, unless otherwise specified.  The designated expert(s) verify that a specification exists and is readily accessible.  Expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious). The creation of a registry MAY specify additional constraints on permanent registrations. The creation of a registries MAY identify a range of codepoints where registrations are governed by a different registration policy.  For instance, the registries for 62-bit codepoints in this document have stricter policies for codepoints in the range from 0 to 63. Any stricter requirements for permanent registrations do not prevent provisional registrations for affected codepoints.  For instance, a provisional registration for a frame type iana-frames of 61 could be requested. All registrations made by Standards Track publications MUST be permanent. All registrations in this document are assigned a permanent status and list as contact both the IESG (ietf@ietf.org) and the QUIC working group (quic@ietf.org). 22.2. IANA [SHALL add/has added] a registry for "QUIC Transport Parameters" under a "QUIC" heading. The "QUIC Transport Parameters" registry governs a 16-bit space. This registry follows the registration policy from iana-policy. Permanent registrations in this registry are assigned using the Specification Required policy RFC8126. In addition to the fields in iana-provisional, permanent registrations in this registry MUST include the following fields: A short mnemonic for the parameter. </ins> The initial contents of this registry are shown in iana-tp-table. Additionally, each value of the format "31 * N + 27" for integer  <ins> values of N (that is, "27", "58", "89", ...) are reserved and MUST NOT be assigned by IANA. </ins>  <ins> 22.3. </ins> IANA [SHALL add/has added] a registry for "QUIC Frame Types" under a  <ins> "QUIC" heading. </ins>  <ins> The "QUIC Frame Types" registry governs a 62-bit space.  This registry follows the registration policy from iana-policy.  Permanent registrations in this registry are assigned using the Specification Required policy RFC8126, except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of RFC8126. </ins>  <ins> In addition to the fields in iana-provisional, permanent registrations in this registry MUST include the following fields: </ins> A short mnemonic for the frame type.  <ins> In addition to the advice in iana-policy, specifications for new permanent registrations SHOULD describe the means by which an endpoint might determine that it can send the identified type of frame.  An accompanying transport parameter registration (see iana- transport-parameters) is expected for most registrations. Specifications for permanent registrations also needs to describe the </ins> format and assigned semantics of any fields in the frame.  The initial contents of this registry are tabulated in frame-types.  <ins> 22.4. </ins> IANA [SHALL add/has added] a registry for "QUIC Transport Error  <ins> Codes" under a "QUIC" heading. </ins> The "QUIC Transport Error Codes" registry governs a 62-bit space. This space is split into three spaces that are governed by different  <ins> policies.  Permanent registrations in this registry are assigned using the Specification Required policy RFC8126, except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of RFC8126. </ins>  <ins> In addition to the fields in iana-provisional, permanent registrations in this registry MUST include the following fields: </ins> A short mnemonic for the parameter. A brief description of the error code semantics, which MAY be a summary if a specification reference is provided.  The initial contents of this registry are shown in iana-error-table. 11. <ins> This document registers a new ALPN protocol ID (iana-alpn) and creates new registries that manage the assignment of codepoints in HTTP/3. </ins> 11.1. This document creates a new registration for the identification of 11.2. <ins> New registries created in this document operate under the QUIC registration policy documented in Section 22.1 of QUIC-TRANSPORT. These registries all include the common set of fields listed in Section 22.1.1 of QUIC-TRANSPORT. The initial allocations in these registries created in this document are all assigned permanent status and list as contact both the IESG (iesg@ietf.org) and the HTTP working group (ietf-http-wg@w3.org). 11.2.1. </ins> This document establishes a registry for HTTP/3 frame type codes.  <ins> The "HTTP/3 Frame Type" registry governs a 62-bit space.  This registry follows the QUIC registry policy; see iana-policy. Permanent registrations in this registry are assigned using the Specification Required policy RFC8126, except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of RFC8126. </ins> While this registry is separate from the "HTTP/2 Frame Type" registry defined in HTTP2, it is preferable that the assignments parallel each one registry, every effort SHOULD be made to avoid assigning the corresponding value to an unrelated operation.  <ins> In addition to common fields as described in iana-policy, permanent registrations in this registry MUST include the following field: </ins> A name or label for the frame type.  <ins> Specifications of frame types MUST include a description of the frame layout and its semantics, including any parts of the frame that are conditionally present. </ins>  <ins> The entries in iana-frame-table are registered by this document. </ins> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.  <ins> 11.2.2. </ins> This document establishes a registry for HTTP/3 settings.  The  <ins> "HTTP/3 Settings" registry governs a 62-bit space.  This registry follows the QUIC registry policy; see iana-policy.  Permanent registrations in this registry are assigned using the Specification Required policy RFC8126, except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of RFC8126. </ins> While this registry is separate from the "HTTP/2 Settings" registry defined in HTTP2, it is preferable that the assignments parallel each SHOULD be made to avoid assigning the corresponding value to an unrelated operation.  <ins> In addition to common fields as described in iana-policy, permanent registrations in this registry MUST include the following fields: </ins> A symbolic name for the setting.  Specifying a setting name is optional.  <ins> The value of the setting unless otherwise indicated.  A default SHOULD be the most restrictive possible value. </ins>  <ins> The entries in iana-setting-table are registered by this document. </ins> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.  <ins> 11.2.3. </ins> This document establishes a registry for HTTP/3 error codes.  The  <ins> "HTTP/3 Error Code" registry manages a 62-bit space.  This registry follows the QUIC registry policy; see iana-policy.  Permanent registrations in this registry are assigned using the Specification Required policy RFC8126, except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of RFC8126. </ins> Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new registrations for possible duplication with existing error codes. Use of existing registrations is to be encouraged, but not mandated.  <ins> In addition to common fields as described in iana-policy, permanent registrations in this registry MUST include the following fields: </ins> A name for the error code.  Specifying an error code name is optional.  <ins> A brief description of the error code semantics. </ins>  <ins> The entries in the iana-error-table are registered by this document. </ins>  <ins> 11.2.4. </ins> This document establishes a registry for HTTP/3 unidirectional stream types.  The "HTTP/3 Stream Type" registry governs a 62-bit space.  <ins> This registry follows the QUIC registry policy; see iana-policy. Permanent registrations in this registry are assigned using the Specification Required policy RFC8126, except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of RFC8126. </ins>  <ins> In addition to common fields as described in iana-policy, permanent registrations in this registry MUST include the following fields: </ins> A name or label for the stream type.  Which endpoint on a connection may initiate a stream of this type. Values are "Client", "Server", or "Both". <ins> Specifications for permanent registrations MUST include a description of the stream type, including the layout semantics of the stream contents. </ins> The entries in the following table are registered by this document. Additionally, each code of the format "0x1f * N + 0x21" for integer