On Mon, 15 Feb 2016, John C Klensin wrote:
Because of that history and consensus, the strong suggestions in 5321 are about as far as one is going to get as far as restrictions/ recommendations on the mailbox names themselves and the "don't try to guess" rule probably isn't going anywhere.
The failure of that community is pretty big and it is clear that the (non)rules that came out of that failure are _still_ causing us problems. It has itself delayed this 3 page document for over a year without any substantial new input or insights. Two problems we do not have: 1) POSTMASTER@xxxxxxxxxxx has been delivered to postmaster@xxxxxxxxxxx since Network Solutions was the only Registry in town. 2) No sentient organisation hands out a LHS with only case differences to different entities (eg PAUL@xxxxxxxxx is realistically guaranteed to be paul@xxxxxxxxx). I find any efforts rejecting a solution because it does not support the above two corner cases to be an exercise in dogma rather than engineering. Two real problems we do have: 1) Phone virtual keyboards and language settings auto-capitalizing recognised names (probably a bigger problem in the US-ASCII world) 2) Browsers in webforms auto-capitalizing recognised names. (probably a bigger problem in the US-ASCII world) I find any efforts ignoring these two things happen at an almost daily rate for those people who use smart phones to be dogma instead of engineering. Then we have two contradicting requirements from the SMTP world: 1) One must only use the _exactly_ inputted local-part 2) One is not allowed to use more than 1 lookup or else it qualifies as "illegal local-part guessing" While I can sympathise with the desire to support UTF-8, EAI and everything else in the local-part, I have done my best contacting people who were involved with EAI and to put their advised text into the draft. If you have improvements to those texts, please share them with us. I have indicated I would be completely fine with saying anything from "anything non-ASCII" should not be lowercased to "anything non-ASCII should be lowercased using [ruleset donated by those people object to the current text]" to "try unmodified, then lowercased". The only unacceptable option to me is "try only what was input by user and ignore all common problems associated with that". So, please provide text for the preferred variant solution.
Nothing I'm aware of (other than probably the WG Charter) prohibits DANE from proposing an update to 5321 and 6530ff, but the history (and probable side-effects that no one has tried to analyze) predicts that the idea won't easily get community consensus.
To put it bluntly, I'd rather commit to 800 hours of unsedated dental drill work than to go anywhere near discussing RFC 5321 related items within the IETF ever again. But I would be happy to watch the fireworks from far far away if you wish to take on that work. Paul