Hi David, > Your point is that the RFC gives you something the code points alone > don't: a stable reference that vendors and hardware makers will build > on. A dead draft won't support that. Sure, I agree with all of it. But > that's Richard's whole argument. Publication isn't neutral. It's the > thing that turns some registry entries into products people ship.
I think that is an over-simplification. There are several steps from implementing something at the lowest library level, to actually shipping an end-user product.
Firstly, there are at least two ways an implemented mechanism might be disabled at the library level; either by simply not linking it at build time (only shipping source and instructions on how to include it), or by a software switch that would have to be deliberately turned by the library consumer.
Secondly, the software developer would have to decide which library features to enable, make end user configurable, or disable completely.
So, no, I don't agree that RFC publication drives deployment, more than indirectly and to a point. Publication does however drive implementation at the level corresponding to the RFC, but that happens already at the Internet-Draft level. What publication means is that those implementations will continue to be maintained in future versions of the library. There are already a multitude of libraries out there in the wild that implement the current draft with the IANA code point. Those versions of those libraries will continue to exist even if the Internet-Draft is killed.
Henrick Wibell Hellström, StreamSec On 2026-07-07 12:03, David Stainton wrote:
Hi Henrick, I think you and Richard actually agree, which is the interesting part.As an independent implementer, I would like to weigh in. I believe there might be a misunderstanding here. While it is common for software libraries to implement active Internet-Drafts, this is not a viable long-term solution. Features backed only by a rejected, long-dead draft cannot be safely maintained over time. Furthermore, while hardware isn't my primary domain, I highly doubt any hardware manufacturer would commit resources to implementing a rejected draft.Your point is that the RFC gives you something the code points alone don't: a stable reference that vendors and hardware makers will build on. A dead draft won't support that. Sure, I agree with all of it. But that's Richard's whole argument. Publication isn't neutral. It's the thing that turns some registry entries into products people ship. So "does the RFC drive deployment" isn't really in dispute anymore. You've argued that it does. The real question is whether we want to push deployment toward standalone ML-KEM when X25519MLKEM768 is already there, already Recommended=Y, strictly stronger, and costs almost nothing. And the module-validation case makes this worse, not better. Those deployments patch on validation timelines, not software ones. So "the RFC makes it real" is an argument for caution, not for shipping. Cheers, David Stainton Founder, Katzenpost — post-quantum mix network
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
