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
sub(_at_)user(_dot_)panix(_dot_)net -> user-sub(_at_)panix(_dot_)net(_dot_)
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