On Sun, May 27, 2018 at 09:56:30AM -0700, Eric Rescorla wrote: > Well, this is a bit premature because the document hasn't actually been > published, just approved.
It's also not properly addressed -- regular allocations under the "specification required" policy go directly to IANA, whereas RFC 7120 early allocations it is the WG chairs and ADs that need to judge the level of interest in the community. > In any case, I don't think we should assign code point 26 to this > extension. I recognize that you have existing implementations that happen > to use it, but that's a result of the unfortunate decision to squat on a > code point which was right in the way of near future assignments, and those > implementations can change to the new code point. Of course, it might be > useful to add a note to implementations of the compression draft as well. There's a tradeoff between respecting the official allocation processes and avoiding real-world breakage. I think we can all make our own assessments on the former, but for the latter, all the evidence we have so far is a claim from Peter that there exists software that hardcodes this number, with no indication of scale of deployment or ease of updating such software. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
