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(_at_)EXAMPLE(_dot_)COM has been delivered to
postmaster(_at_)example(_dot_)com
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(_at_)nohats(_dot_)ca is realistically
guaranteed
to be paul(_at_)nohats(_dot_)ca).
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