Would this be in scope or not?
While listening to a presentation on UA given to staff, an issue related to internationalized email addresses came back to my mind. I haven't been tracking UA for a few months now, focusing on other projects. I learned of this list and flipped quickly through the archives. So may be my concern isn't quite on-topic. I mean, this is not about getting software to properly handle the spectrum of Unicode characters. Taking a step back, ICANN is about identifiers, and we are striving towards a globally available system that features uniqueness in the mapping of identifiers to "reality." (One of the core concerns about IDNA 2008 is that the mapping from what's-on-a-business-card to whats-in-the-DNS is two-way and repeatable.) Specifically this has been about domain names but by extension through Universal Acceptance, email addresses. Along those lines I have been thinking about they increasing use of email addresses as identifiers for just about all on-line sites. Stores, utilities, and more seriously, medical professionals have made me think of this, as well as the option to either 1) get a free identifier 2) get one tied to your ISP/utility or 3) create your own. I've come to be a bit afraid about stability of this system. On one hand, the identifier I use is used in many places and in many ways, hence changing it is a pain. On the other hand, who guarantees that the identifier will last "long enough" and not change hands if I (or an executor) don't maintain it. The standard for the mailbox name (as in mailbox@domainname) is that the treatment of the mailbox name is up to the domain name. "Dots" are immaterial to mail operators (which has proven to be a surprise), the "+" might be treated specially, etc. I squirm when I think that there's a desire to think of email names as global and unique. So, in a way, it seems like the wrong foundation for an ICANN effort. (Languages have had to adopt '@' already. Not sure about '+' and other syntactic sugar in mailbox names. Yet I understand the "killer" app necessity of IDN email for the new TLDs. I totally get that, and I bet so do the members of the list, so I won't belabor the point. The question though is - how to you build a castle on sand? It's not clear to me that ICANN could drive a standard handling of mailbox names, I think that would be quixotic. Then again maybe tackling mailbox names isn't necessary, maybe all we really need to do is get clients to work with an expanded definition of what a mailbox name is. (Lurking in me is the thought of "variants" and how they might cause trouble in mailbox names if there's no canonical form as defined in IDNA 2008 for domain names.) Ed Lewis Senior Technologist, Office of CTO
It's not clear to me that ICANN could drive a standard handling of mailbox names, I think that would be quixotic. Then again maybe tackling mailbox names isn't necessary, maybe all we really need to do is get clients to work with an expanded definition of what a mailbox name is. (Lurking in me is the thought of "variants" and how they might cause trouble in mailbox names if there's no canonical form as defined in IDNA 2008 for domain
[[Ram]] The goal would not be for ICANN to drive either the standard or adoption. Instead, the goal would be for ICANN to help improve awareness of the problem space, and then provide a coordination function so appropriate parties can determine solution sets for the defined problems.
I'm going to agree with Ram that the most important thing that ICANN do at present is help in the essential Universal *awareness* elements of universal acceptance as well as with facilitation with the coordinating functions. - RSM
It's not clear to me that ICANN could drive a standard handling of mailbox names, I think that would be quixotic. Then again maybe tackling mailbox names isn't necessary, maybe all we really need to do is get clients to work with an expanded definition of what a mailbox name is. (Lurking in me is the thought of "variants" and how they might cause trouble in mailbox names if there's no canonical form as defined in IDNA 2008 for domain
[[Ram]] The goal would not be for ICANN to drive either the standard or adoption. Instead, the goal would be for ICANN to help improve awareness of the problem space, and then provide a coordination function so appropriate parties can determine solution sets for the defined problems.
The standard for the mailbox name (as in mailbox@domainname) is that the treatment of the mailbox name is up to the domain name. "Dots" are immaterial to mail operators (which has proven to be a surprise), the "+" might be treated specially, etc. I squirm when I think that there's a desire to think of email names as global and unique. So, in a way, it seems like the wrong foundation for an ICANN effort. (Languages have had to adopt '@' already. Not sure about '+' and other syntactic sugar in mailbox names.
The practices mentioned here --- immaterial dots, treating +substrings differently, case insensitivity --- have evolved outside the context of internationalized email addresses. I believe ICANN and this group can have a real impact at promoting EAI (RFC 6532 et al) adoption while taking no stance on subjective local-part practices like these. (There might be areas where we choose to weigh in: local-parts are technically case-sensitive, but one could imagine that there are security implications if an e-commerce site were to allow user@example and User@example to be separate accounts. But those problems already exist and are not specific to EAI.) On Thu, Mar 12, 2015 at 2:31 PM, Richard Merdinger <rmerdinger@godaddy.com> wrote:
I'm going to agree with Ram that the most important thing that ICANN do at present is help in the essential Universal *awareness* elements of universal acceptance as well as with facilitation with the coordinating functions. - RSM
It's not clear to me that ICANN could drive a standard handling of mailbox names, I think that would be quixotic. Then again maybe tackling mailbox names isn't necessary, maybe all we really need to do is get clients to work with an expanded definition of what a mailbox name is. (Lurking in me is the thought of "variants" and how they might cause trouble in mailbox names if there's no canonical form as defined in IDNA 2008 for domain
[[Ram]] The goal would not be for ICANN to drive either the standard or adoption. Instead, the goal would be for ICANN to help improve awareness of the problem space, and then provide a coordination function so appropriate parties can determine solution sets for the defined problems.
Brent: Where are conventions/ good practices/best practices for the localname part of an e-mail address developed? Is this something that the UA group could facilitate during a face to face gathering? If so, should it? Could these conventions (etc) be language or script specific? For example, by convention not supporting a dot in a right to left script. (This way you can determine which is the domain and which is the local name part - the domain always has a dot.) Don On 13/03/2015, at 12:06 pm, Brent London <brentlondon@google.com<mailto:brentlondon@google.com>> wrote: The standard for the mailbox name (as in mailbox@domainname) is that the treatment of the mailbox name is up to the domain name. "Dots" are immaterial to mail operators (which has proven to be a surprise), the "+" might be treated specially, etc. I squirm when I think that there's a desire to think of email names as global and unique. So, in a way, it seems like the wrong foundation for an ICANN effort. (Languages have had to adopt '@' already. Not sure about '+' and other syntactic sugar in mailbox names. The practices mentioned here --- immaterial dots, treating +substrings differently, case insensitivity --- have evolved outside the context of internationalized email addresses. I believe IC! ANN and this group can have a real impact at promoting EAI (RFC 6532 et al) adoption while taking no stance on subjective local-part practices like these. (There might be areas where we choose to weigh in: local-parts are technically case-sensitive, but one could imagine that there are security implications if an e-commerce site were to allow user@example and User@example to be separate accounts. But those problems already exist and are not specific to EAI.) On Thu, Mar 12, 2015 at 2:31 PM, Richard Merdinger <rmerdinger@godaddy.com<mailto:rmerdinger@godaddy.com>> wrote: I'm going to agree with Ram that the most important thing that ICANN do at present is help in the essential Universal *awareness* elements of universal acceptan! ce as well as with facilitation with the coordinating functions. - RSM
It's not clear to me that ICANN could drive a standard handling of mailbox names, I think that would be quixotic. Then again maybe tackling mailbox names isn't necessary, maybe all we really need to do is get clients to work with an expanded definition of what a mailbox name is. (Lurking in me is the thought of "variants" and how they might cause trouble in mailbox names if there's no canonical form as defined in IDNA 2008 for domain
[[Ram]] The goal would not be for ICANN to drive either the standard or adoption. Instead, the goal would be for ICANN to help improve awareness of the problem space, and then provide a coordination function so appropriate parties can determine solution sets for the defined problems.
Where are conventions/ good practices/best practices for the localname part of an e-mail address developed? Is this something that the UA group could facilitate during a face to face gathering? If so, should it?
I believe --- someone correct me if I'm mistaken --- that they developed organically. Since each domain can configure it's local-part rules (mostly) however it wants, there was/is no technical need for coordination for most conventions. So as long as everyone's conforming to the internet mail RFCs, Gmail can decide to ignore dots (.) without negatively affecting outlook.com . Could these conventions (etc) be language or script specific? For example,
by convention not supporting a dot in a right to left script. (This way you can determine which is the domain and which is the local name part - the domain always has a dot.)
I think this is possible, especially if we're anticipating a security/abuse issue. My sense is that the m3aawg <https://www.maawg.org/> would be the right forum for coming up with a more detailed proposal. It theoreticallly could be implemented independently: If major mail providers together decided to spam-reject all RTL email addresses with a dot in the local-part, it could help shape this type of convention. But I suspect that a coordination a decision like that would need to go through an anti-abuse working group of some sort first. On Fri, Mar 13, 2015 at 3:08 AM, Don Hollander <don.hollander@icann.org> wrote:
Brent:
Where are conventions/ good practices/best practices for the localname part of an e-mail address developed?
Is this something that the UA group could facilitate during a face to face gathering? If so, should it?
Could these conventions (etc) be language or script specific? For example, by convention not supporting a dot in a right to left script. (This way you can determine which is the domain and which is the local name part - the domain always has a dot.)
Don
On 13/03/2015, at 12:06 pm, Brent London <brentlondon@google.com> wrote:
The standard for the mailbox name (as in mailbox@domainname) is that the
treatment of the mailbox name is up to the domain name. "Dots" are immaterial to mail operators (which has proven to be a surprise), the "+" might be treated specially, etc. I squirm when I think that there's a desire to think of email names as global and unique. So, in a way, it seems like the wrong foundation for an ICANN effort. (Languages have had to adopt '@' already. Not sure about '+' and other syntactic sugar in mailbox names.
The practices mentioned here --- immaterial dots, treating +substrings differently, case insensitivity --- have evolved outside the context of internationalized email addresses. I believe IC! ANN and this group can have a real impact at promoting EAI (RFC 6532 et al) adoption while taking no stance on subjective local-part practices like these.
(There might be areas where we choose to weigh in: local-parts are technically case-sensitive, but one could imagine that there are security implications if an e-commerce site were to allow user@example and User@example to be separate accounts. But those problems already exist and are not specific to EAI.)
On Thu, Mar 12, 2015 at 2:31 PM, Richard Merdinger <rmerdinger@godaddy.com
wrote:
I'm going to agree with Ram that the most important thing that ICANN do at present is help in the essential Universal *awareness* elements of universal acceptan! ce as well as with facilitation with the coordinating functions. - RSM
It's not clear to me that ICANN could drive a standard handling of mailbox names, I think that would be quixotic. Then again maybe tackling mailbox names isn't necessary, maybe all we really need to do is get clients to work with an expanded definition of what a mailbox name is. (Lurking in me is the thought of "variants" and how they might cause trouble in mailbox names if there's no canonical form as defined in IDNA 2008 for domain
[[Ram]] The goal would not be for ICANN to drive either the standard or adoption. Instead, the goal would be for ICANN to help improve awareness of the problem space, and then provide a coordination function so appropriate parties can determine solution sets for the defined problems.
Agree with Ram and Rich. Adding that once a good solution set is found from the platform it will be in scope to then advocate that to the broader community, which is another awareness function. So I see our job in a few phases: 1. raise awareness of the issues 2. facilitate the convening of parties to identify solution sets (the actual development of the solution may be beyond the immediate ICANN "venue") 3. once reasonably sound solution(s) are identified promote and advocate such solutions to address the issues Edmon
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Richard Merdinger Sent: Friday, March 13, 2015 5:31 AM To: Ram Mohan; Edward Lewis; ua-discuss@icann.org Subject: Re: [UA-discuss] Would this be in scope or not?
I'm going to agree with Ram that the most important thing that ICANN do at present is help in the essential Universal *awareness* elements of universal acceptance as well as with facilitation with the coordinating functions. - RSM
It's not clear to me that ICANN could drive a standard handling of mailbox names, I think that would be quixotic. Then again maybe tackling mailbox names isn't necessary, maybe all we really need to do is get clients to work with an expanded definition of what a mailbox name is. (Lurking in me is the thought of "variants" and how they might cause trouble in mailbox names if there's no canonical form as defined in IDNA 2008 for domain
[[Ram]] The goal would not be for ICANN to drive either the standard or adoption. Instead, the goal would be for ICANN to help improve awareness of the problem space, and then provide a coordination function so appropriate parties can determine solution sets for the defined problems.
participants (6)
-
Brent London -
Don Hollander -
Edmon Chung -
Edward Lewis -
Ram Mohan -
Richard Merdinger