<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Brent:
<div class=""><br class="">
</div>
<div class="">Where are conventions/ good practices/best practices for the localname part of an e-mail address developed?</div>
<div class=""><br class="">
</div>
<div class="">Is this something that the UA group could facilitate during a face to face gathering? If so, should it?</div>
<div class=""><br class="">
</div>
<div class="">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.)</div>
<div class=""><br class="">
</div>
<div class="">Don</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 13/03/2015, at 12:06 pm, Brent London <<a href="mailto:brentlondon@google.com" class="">brentlondon@google.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The standard for the mailbox name (as in mailbox@domainname) is that the<br class="">
treatment of the mailbox name is up to the domain name. "Dots" are<br class="">
immaterial to mail operators (which has proven to be a surprise), the "+"<br class="">
might be treated specially, etc. I squirm when I think that there's a<br class="">
desire to think of email names as global and unique. So, in a way, it<br class="">
seems like the wrong foundation for an ICANN effort. (Languages have had<br class="">
to adopt '@' already. Not sure about '+' and other syntactic sugar in<br class="">
mailbox names.</blockquote>
</div>
<div class=""><br class="">
</div>
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.
<div class=""><br class="">
</div>
<div class="">(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.)</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Thu, Mar 12, 2015 at 2:31 PM, Richard Merdinger <span dir="ltr" class="">
<<a href="mailto:rmerdinger@godaddy.com" target="_blank" class="">rmerdinger@godaddy.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br class="">
<div class="HOEnZb">
<div class="h5"><br class="">
> It's not clear to me that ICANN could drive a standard handling of<br class="">
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.<br class="">
(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<br class="">
2008 for domain<br class="">
<br class="">
[[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.<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>