On Thu, Apr 2, 2026 at 3:25 PM David Benjamin <[email protected]> wrote:
> I think trying to cite IANA registries is a distraction. IANA registries > are *not* enough. To meaningfully define a codepoint, you need to say > what the codepoint means. That's why our IANA registries have document > references. Moreover, to be well-defined, it needs to be a TLS-specific > document, not just the underlying crypto, to write the small handful of > TLS-specific definitions needed to glue things together. > > Now, *those* documents are candidates for citing, and our registries *do* > sometimes reference drafts, as they do here. One *could* argue that > people should just be OK citing drafts. But I cannot *entirely* blame > folks for being reticent to cite drafts when the IETF spends so much energy > to emphasize that drafts are not done. They have expiry, there is no > indication whether people expect to define a new one with different > semantics, etc. For things that the IETF *does* intend to publish, we > have all spent quite a lot of energy making sure people downstream of us > know that it's not "official" until it's published. We all did this because > it's harmful for standards work if people freeze intermediate snapshots > that aren't done. > ISTM that the "freezing" here happened at the time of code point assignment. We can't have it both ways. Either we tell everyone that drafts are > perfectly fair game to implement, with no stopgap against people > inadvertently ossifying things that aren't yet done, or there must be ways > for drafts to progress into a state that signals they are done. That > durable state doesn't have to be an RFC, but it's the only one the IETF has > defined right now. > > One could say, ah, the problem is the IETF needs to define a non-RFC end > state, and that *that's* not TLS WG's business. But it *is* very much the > TLS WG's business that we're worrying about this at all, because we've > managed to spend a disproportionate amount of time waffling on technically > trivial documents. > I don't think that this analysis is really correct. Stepping back from this document, we have roughly two categories of algorithms (and other extensibility points): A. Those which have the support [0] of the TLS WG. B. Those which do not have the support of the TLS WG but some set of people nevertheless wants ot use. Type A algorithms get published as RFCs. The current registry structure was designed to allow people with Type B algorithms to nevertheless reserve code points without the TLS WG getting involved, either on the basis of some non-RFC specification or by persuading the ISE to publish their RFC. The reason we did this is not because we want to promote the use of those algorithms but rather because we know people will use them anyway and we want to avoid contamination of the code point space. Now, sometimes, as in this case, we get people who want to use an algorithm ask the TLS WG to publish an RFC because they don't want to use the code point without an RFC. However, the reason these documents aren't being published as RFCs is because there's not consensus that have consensus promote their use, so I don't think publishing them as an RFC so that others can more readily use them is a very strong argument. If people find it somewhat harder to use algorithms for which there isn't consensus why is that bad? With that said, if we want to make a shift like that contemplated draft-barnes-tls-this-could-have-been-an-email, such that even documents which the WG does feel positively about and otherwise could have gotten consensus to publish as RFCs are just I-Dsor emails, then we perhaps do in fact need some permanent definition of the algorithm, but that doesn't seem to be the case here. -Ekr [0] By support I mean "enough people in favor that they can be published in the IETF".
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
