Arnt Gulbrandsen <[email protected]> wrote: > > 2. The localpart is opaque, the document says.
... which is, architecturally, quite correct. > The portion to the left of the at-sign contains a string that is > globally opaque and is called the <local-part>. It is to be > interpreted only by the entity specified by the address's domain > name. > > That's not entirely practical. Anyone who implements address-book > search, "unsubscribe" handlers and code that needs to look up addresses > will find that one has to do lookups case-insensitively. None of these are architecturally correct. Address-book searching will indeed find different capitalization of what seems to be the same address, but that's more a user-interface issue of mail-readers. Automated unsubscribe SHOULD find a way to match something actually sent in a list posting, rather than guess from any of several email address fields. But in practice, anything that "works" is probably "good enough"... > I would like to have an additional paragraph in section 3.1, stating > that although the localpart may or may not be case-sensitive, as the > domain owner pleases, some software and users do treat it as if it were > case-insensitive anyway. Software MUST preserve the case, and SHOULD do > address lookups case-insensitively. I disagree with this point. We've had enough tweaking; and we're describing architecture, not best-practice. "MUST preserve the case", IMHO, is already implied. "SHOULD do address lookups case-insensitively", IMHO, doesn't belong in an architecture document. -- John Leslie <[email protected]>
