I suppose, but I worry that would just encourage people to argue that they shouldn't have been discarded. Is there any way to explain that there is a spec for EAI, if you do what it says you will interoperate, and if you do something else, even something else which you imagine to be better, you won't? I always struggle with this. I recognize that the answer is actually very simple and does not require any elaboration. Nevertheless, I have been willing to be more verbose, even redundant, when describing the sorts of downgrading which is disallowed, simply because the topics continued to pop up. But at this point in history, I conclude that everyone on this discussion list (and everyone on the general US-DISCUSS list, which I have cc'd on this reply) should now have been exposed to the discussions and the conclusions and should no longer need so much hand-holding. Based on that conclusion, I will be taking a harder line on the topic of email downgrading. I will start shutting down the topic more aggressively. As I warned in a mail after EAI Summit #2 earlier this year, this may require me to be blunt to the point of rudeness. Apologies in advance. Summary: * The UASG cannot recommend any transformation of a username/nickname at any time for any reason. * The UASG accepts that a replacement of a non-ascii mailbox name with an ascii mailbox name can be used in very limited circumstances (only IF the sending system 'owns' the sending mail address and IF an ascii address is pre-defined in an alias field and IF the first hop is clearly not EAI Ready). * Note that if a "non-owning" sender is aware of such aliases and has them in their local mailbox, the sender may devise a mechanism for performing their own method (manual or otherwise). Regardless, UASG cannot recommend any transformation of the username. * Mailbox administrators can use any characters or set of characters not explicitly disallowed by the RFCs in their mailbox configurations. * IETF PRECIS has defined username and nickname profiles, and these should be taken as good practice recommendations for mailbox administrators when they assign mailboxes. * Please don't start new discussions about downgrading on the mailing list. * If someone does start a new discussion about downgrading on the mailing list, please refrain from participating in that non-production discussion. /marksv -----Original Message----- From: UA-EAI [mailto:ua-eai-bounces@icann.org] On Behalf Of John Levine Sent: Tuesday, March 13, 2018 17:53 To: ua-eai@icann.org Subject: Re: [UA-EAI] Local Part Guidelines w> 1. The UASG cannot recommend any transformation of a mailbox at any time for any reason.
2. The UASG accepts that a replacement of a non-ascii mailbox name
with an ascii mailbox name can be used in very limited circumstances -
basically where the sending system 'owns' the sending mail address and an ascii address is pre-defined in a alias field and the first hop is clearly not EAI Ready.
Yes, those sound right. For #2 another plausible case is that the sender is doing the downgrade and has the aliases in the local address book.
3. Mailbox administrators can use any characters or set of
characters not explicitly disallowed by the RFCs in their mailbox configurations.
* Does the UASG recommend any approach to avoid confusion? I would rather point to someone
else's well considered work in this area. Does such exist?
That's what the IETF PRECIS work was about. The username and nickname profiles are both plausible for local parts. I put references into the Google draft.
4. We may include an Appendix in the EAI Documentation with some
history and examples of transformations that were discarded and why.
I suppose, but I worry that would just encourage people to argue that they shouldn't have been discarded. Is there any way to explain that there is a spec for EAI, if you do what it says you will interoperate, and if you do something else, even something else which you imagine to be better, you won't? R's, JOhn _______________________________________________ UA-EAI mailing list UA-EAI@icann.org<mailto:UA-EAI@icann.org> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.or...