Change:
This change also reserves short profile IDs for "well-known" use. Fixes URL
Can we please try to resolve this question soon to unblock implementation?
NAME NAME Any objection to merging this?
The template says it's an integer (in what range?), but the ClientHello says it's 0-255 bytes. I think it's probably easiest to say it's a string of 0-255 bytes, with the empty string reserved to mean "no template". I guess if you want to get fancy you could reserve all 1-4 byte strings.
Agreed. If you want to send a PR, I wouldn't object.
This LGTM.

Discussion:
The following elements are defined: <del> identifies the profile being defined. </del> <ins> identifies the profile being defined (default: "").  If present, this key MUST contain a hex-encoded sequence of 0-255 bytes (the "profile ID").  IDs whose decoded length is 4 bytes or less are reserved (see reserved-profiles).  When a reserved value is used (including the default value), other keys MUST NOT appear in the template, and a client MUST NOT accept the template unless it recognizes the ID. </ins> indicates that both sides agree to the single TLS version specified by the given integer value (772 == 0x0304 for TLS 1.3).

value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <del> OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use.  For a ServerHello this field is not required.  Should we make this field optional? </del> Encrypted records use DTLS 1.3 RFC9147 record framing, comprising a configuration octet followed by optional connection ID, sequence number, and length fields.  The encryption process and additional

The cTLS ClientHello is defined as follows. <del> The client uses the "profile_id" field to inform the server about the compression profile being used (see template-based-specialization). This field MUST be set to a zero-length value and only if no compression profile is used.  Non zero-length values are agreed out of band between the client and server, as part of the specification of the compression profile. </del> <ins> The "profile_id" field MUST identify the profile that is in use.  A zero-length ID corresponds to the cTLS default protocol. </ins> 3.2.

Version 772 corresponds to the hex representation 0x0304, named group "29" (0x001D) represents X25519. <del> OPEN ISSUE: Should we have a registry of well-known profiles? </del> 5. WARNING: This document is effectively brand new and has seen no

Template Keys", on the Transport Layer Security (TLS) Parameters page, with a "Specification Required" registration policy and the following initial contents: <ins> 6.3. This document requests that IANA open a new registry entitled "Well- known cTLS Profile IDs", on the Transport Layer Security (TLS) Parameters page, with the following columns: ID value: A sequence of 1-4 octets. Template: A JSON object. Note: An explanation or reference. The ID values of length 1 are subject to a "Standards Action" registry policy.  Values of length 2 are subject to an "RFC Required" policy.  Values of length 3 and 4 are subject to a "First Come First Served" policy.  Values longer than 4 octets are not subject to registration and MUST NOT appear in this registry. The initial registry contents are: </ins>