Speaking as chair: On 10 Sep 2026, at 13:27, Timo Gerke wrote:
The core issue lies within the message transport layer (the email headers). Introducing nested JSON structures for recipes creates significant validation risks at the Milter level. Even with stable parsers, you cannot eliminate Parsing Differentials. If two compliant parsers (e.g., Milter vs. downstream MTA) interpret a nested JSON object differently - like key ordering or duplicate keys—the cryptographic canonization breaks completely. This is a classic Insecure Design vector.
As Hannah said in a later email, this does sound like a reason to make a point in the Security Considerations section, but I'm not seeing a lot of justification for your position to abandon JSON because of this.
Regarding y2k38 and expiration: Leaving representation "out of scope" is a risk for critical infrastructure running legacy 32-bit hardware. Relying on transient DNS deletion also ignores long-term immutable archiving, where historic signatures must remain deterministically verifiable independent of active DNS states.
Again, this seems like perhaps an issue for security considerations, but specifying internal data representation is never part of protocol specifications in my experience.
Since Bron already admitted the current "gummiband" design breaks at the edge nodes, there is no functional Running Code here. And without running code, there is no Rough Consensus for spec-06.
Running code is not a requirement for rough consensus. And determination of rough consensus will be done by the chairs.
pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
