Codepoint allocation for TLS extension

[Martin Thomson <[e-mail]>]

Hi Everyone,

I'm fairly sure that most people are deploying QUIC with the quic_transport_parameters TLS extension using the 0xffa5 codepoint in the current draft.

Unfortunately, this can't stand.  That's a private use codepoint in TLS.  The final version of QUIC will need a permanent allocation.  This should be a problem in terms of collisions in the short term as QUIC can't conflict with TCP use of TLS, but TLS expressly permits use of this codepoint for private use, so we can't guarantee that TLS stacks won't try to use this codepoint.

I know that this is disruptive, and apologize for this not being clear earlier.  It was originally, but a lot of time has passed since then and I'm sure that many, like me, have forgotten this detail.  

Hopefully this can be rectified without much fuss.  IANA has already requested expert review for the allocation (I believe), so it might just be a matter of getting the final allocation.

Chairs, and AD, 
Following the procedures in Section 3.1 of RFC 7120, this is my request for early allocation of a codepoint, in case that is necessary.  I've provided more context to those involved privately.

I hope to have the final codepoints (version numbers, salt, retry keys, transport parameter extension) in -33, which will go to the IESG for approval in the next few weeks.

--Martin