On Mon, Sep 7, 2026, at 06:23, Timo Gerke wrote:
> - Serialization Layer: Relying on third-party parser heuristics
> to secure a highly exposed, high-volume wire interface remains
> a structural vulnerability. In high-performance/high-
> reliability (HP/HR) environments—utilizing architectures like
> the latest IBM Telum processors—unregulated JSON parsing under
> volumetric load risks blocking complete cores and breaking
> line-rate streaming.
You keep stating this like it's a fact, despite having never addressed my
response "there are people who run planet-scale email systems in this
discussion, and they are not concerned about this".
> - Deterministic Guardrails: To resolve these constraints, the
> specification should structurally enforce a strictly flat
> representation (hard nesting limit of d=1 or d=2). This
> ensures sequential, stream-oriented processing with a constant
> memory footprint per connection.
Have you read the schema? There is actually a nesting limit on the JSON in
Message-Instance headers. Here's an extracted Message-Instance recipe from one
of my examples:
m=4 → m=3 — hop 4 removed a header and two body lines
{
"b": [ {"c":[1,15]},
{"d":["Here's some extra text.", ""]},
{"c":[16,63]} ],
"h": { "extra-header": [ {"d":["yes"]} ] }
}
Restore Extra-Header: yes, and re-insert two lines after body line 15 (63 lines
→ 65).
You'll notice that the deepest is that "h" tag. The depth is
OUTER-HASH => "h" => header-field-name => ARRAYOF => HASH "d": ARRAY.
That's more than 2, but it's bounded. Nothing is deeper than this.
> - Key Lifecycles: Infrastructure-level key rotation in the DNS
> must remain strictly separated from transaction-level
> signature validity. To preserve cryptographic deniability on
> archived data stores, the protocol layout should discourage
> lifetime validation properties from bleeding into transient
> transport metadata.
That is orthogonal to the structure. Key lifetimes belongs in a BCP. I think
we may be in close to agreement here.
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
