--On Friday, 22 February, 2008 14:15 -0500 Jeff Macdonald
<[EMAIL PROTECTED]> 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
