Hello Bron,
the quoting question doesn't bear on the choice between JSON and a
tag-value encoding, because the difficulty is with the address
characters, not with the container format.
The complex characters in an RFC5321 Forward-path are handled the same
way regardless of what surrounds them. The current spec handles them
with base64: rt= is a tag-value field (rt=base64string *(","
base64string), Section 8.6) whose values are base64-encoded precisely
because the Forward-path "can include characters which would confuse
naive parsers." That is a tag-value field solving the quoting problem
without any JSON.
There is a second way to avoid the problem entirely: carry one address
per header, so no value ever contains more than a single address and
there is no internal separator to protect. No encoding is needed because
there is nothing to disambiguate.
The two approaches differ in one respect worth naming. Base64 encoding
solves the parser problem at the cost of opacity: the recipient
addresses are no longer readable in the header, in a log or in a grep
without a decoding step. This is the same opacity every recipe carries,
for the same reason. One address per header stays in clear text,
inspectable exactly like every other transit header (DKIM-Signature,
ARC, Authentication-Results). For anyone doing operational
troubleshooting on a mail server, that readability is not a small thing.
So the quoting difficulty is resolved independently of JSON and it is
not an argument for a structured format over a tag-value one: the spec's
own rt= field is a tag-value field that already handles it. Whatever the
case for JSON may be, quoting is not part of it.
Regards,
Vittorio Moccia
Il 2026-09-04 04:48 Bron Gondwana ha scritto:
Hi Timo,
Please review the arguments that were made at the time the JSON
structure was introduced and address the quoting complexities and
likelyhood of subtle incompatibilities compared to using an existing
structured format. JSON was chosen because it has a very well defined
structure with widespread availability of compatible parsers.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
