--On Friday, 22 February, 2008 14:15 -0500 Jeff Macdonald
<jmacdonald(_at_)e-dialog(_dot_)com> wrote:
On Fri, Feb 22, 2008 at 01:37:20PM -0500, John C Klensin wrote:
Hi.
The discussion about whether HT should be included as a
permitted character in email message local-parts has
identified another issue that might benefit from explanation.
These things were discussed as "any escaped ASCII character
from %0 to %127" or "control characters" in the 821/2821
context. Since we got rid of the control characters, we've
started talking about white space and whether or not HT is
valid white space.
But, one way or the other, it isn't white space (in the 2822
and ABNF sense) either. Any of these characters that are
permitted in address local-parts are just characters. In
particular, 821/2821/2821bis make no guarantees that any pair
of "joe jones"@example.com (one SP character)
"joe jones"@example.com (two SP characters)
"joe jones"@example.com (one HT character)
"joe jones"@example.com (one SP character, then one HT
character)
Will reach the same mailbox.
Should we insert a comment in paragraph 2 of section 2.4
(which discusses case matching or the lack thereof) that
points this out? If so, should we encourage implementations
to treat these sequences as "white space", just as we
encourage them to treat addresses as case-insensitive?
It seems to me that this would probably be useful if we leave
HT out of the valid character list and even more so if we
include it.
Isn't the local part interpretation up to the receiving
system? Those
may be the same mailboxes for example.com but not foo.com?
Absolutely. The cited paragraph is an explicit warning against
senders assuming that the receiving system will treat strings
that different in case as equivalent and advice to receiving
systems that making that distinction may confuse a lot of
people. What I was suggesting was augmenting that text to point
out that, while we generally treat all "white space" strings as
equivalent, it is equally inappropriate (vis-a-vis
case-sensitivity) to make that assumption in sending and that
receivers should probably exercise caution.
Sorry if I wasn't clear.
john