-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
>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.
that is incorrect
The issue is not that an email address can contain a comma (which of
course would not occur if we did not have more than one address)
an email address can also contain a = character ... and that means that
a naive parser which believes that (<char>)<char><equals><string> is a
valid tag is going to make a mess of it
viz: there is more than one character to hide away from the naive
Note also that recipes can be contain a very wide range of characters
when entire header fields are being replaced.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBap16BmHfC/FfW545EQJtsACgxoNCTsHFQ3vFIrTW0TiL6zg+Z3QAoKzV
UZEMUrLHKYsCIAIdl+jVb3UJ
=oQNC
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
