I do not think it's necessary to write a draft, this message from the archives
should be enough to mark the two entries as reserved.
I will forward this to the IANA track and Nick and/or Yoav can confirm.
On 12/10/20, 7:14 PM, "Martin Thomson" <m...@lowentropy.net> wrote:
Hey All,
Dry clerical stuff, sorry.
In getting an assignment for the QUIC extension to TLS, the first codepoint
IANA chose to assign was 46. In implementing this, I discovered that this was
assigned a value already in our implementation and I was unable to use that
value.
The history here is that we used a bunch of extension codepoints during the
development of TLS 1.3. 40 and 46 were in that set. 40 was (from memory)
key_share, which we renumbered late in the process due to some incompatible
changes. We stopped using 46 for signaling early data as we factored the
function it provided into another extension. (This is all memory, I'm sure
that you can get more detail by looking at mailing list or git history.)
However we got to this point, the fact is that there is a risk that stacks
have remnants of support for these codepoints as NSS did. I would like to
request that we simply mark these as reserved in the registry.
I believe that the process here requires documentation. If people agree, I
will write a short draft to request the reservation of 40 and 46. That should
be enough; no need to publish an RFC.
Cheers,
Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!CqwNYRnAcLxAixzE-FDKYcayM50-2LsGPtLZnG3BzIe4XF8tptU8hknD09HS$
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
