Agreed with reserving the code points. Even ignoring the remnants of draft 1.3, we probably should have reserved 40 when we changed it, given the compatibility issues we found.
I don't remember enough of how 46 in draft 1.3 was used to reason about the compatibility implications, but code points are cheap so it's easiest to just reserve it and not worry about it. On Thu, Dec 10, 2020 at 8:22 PM Salz, Rich <rsalz= 40akamai....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
