>My position on this is that the email-arch document is attempting to describe >the overall architecture we've standardized. It is not a place for making new >rules about the interpretation of local parts or anything else for that matter. >As such, the text that's there seems fine. If we're going to mess with this - >and in spite of the issues I'm not convinced we should - it needs to happen in >the context of RFC 5321bis, or better still, in a separate draft.
I haven't heard anyone (other than perhaps you) argue that we should fix the interpretation of local parts here. Dave's language describes the current situation reasonably well, the spec says they're case sensitive, the reality is that they're not. I'm also not averse to future work to adjust the spec to agree with reality, but it's a swamp. One issue is i18n, since we'd doubtless get requests to plan for whatever i18n addresses turn out to be, and it's a rare language with case folding rules as simple as English. If we tried to go further and standardize subaddresses, that would be a much worse swamp. There are at least two delimiters for subaddresses, plus and minus, in common use, and I'm also aware of implementations that put part of the address into the domain, such as [email protected] -> [email protected]. Subaddresses also have IPR issues particularly if used to do spam filtering or sorting, real ones, patents whose owners have a history of asserting them. So let's get this out of the way now, and put on the waders later. R's, John
