<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">Given an email address local-part@domain-name</div>
<div class=""><br class="">
</div>
<div class="">The restrictions for a domain-name has been fairly well defined though perhaps in some need of revision. Plus, registries can further restrict permitted characters. Verisign make such restrictions as lists of permitted unicode characters. The
Chinese list makes for an interesting read eg the only permitted character in the CJK Compatibility Ideographs block is U+FA28 﨨 <a href="http://www.verisign.com/assets/languagefiles/CHI.html" class="">http://www.verisign.com/assets/languagefiles/CHI.html</a></div>
<div class=""><br class="">
</div>
<div class="">The point I am making WRT the domain-name is that, currently, it is largely determined by standards, standards groups and registries.</div>
<div class=""><br class="">
</div>
<div class="">With EAI and the local-part I consider we have an opportunity for more freedom in choice of permitted characters. I would like to see the local-part more user oriented. Give users more freedom to choose their local-part identities. So yes I am
in support of, for example, emoji in the local-part.</div>
<div class=""><br class="">
</div>
<div class="">There is, of course, the issue of security. I consider that currently one of the most serious security issues is that many systems nowadays hide part of the email address and it can be impossible to get some systems to default to display the full
email address.</div>
<div class=""><br class="">
</div>
<div class="">Take email addresses of the form (there are other forms)</div>
<div class=""><br class="">
</div>
<div class="">comment <full email address></div>
<div class=""><br class="">
</div>
<div class="">One web mail system I use shows ONLY the comment part. In order for me to see the full email address I need to click the from: field and then hover over the partial email address which is displayed in order to view the full email address. It is
really really infuriating and really really flawed security. I have never found a setting to make it display the full email address. I do go through the tedious process of viewing and checking the full email address with the click and the hover but how many
people would bother.</div>
<div class=""><br class="">
</div>
<div class="">An email identity is not just the comment part, it is not just the local-part, it is the full email address. It is the full email address that is the unique identitifier. Personally, I would happily see the demise of the comment part. The comment
part is spoofing made easy.</div>
<div class=""><br class="">
</div>
<div class="">So, I think there should be an open discussion on the permitted unicode characters for the local-part. I certainly do not think the local part permitted characters should be as restrictive as the IDNA standards.</div>
<div class=""><br class="">
</div>
<div class="">André Schappo</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 3 Apr 2017, at 16:08, Mark Svancarek via UA-discuss <<a href="mailto:UA-discuss@icann.org" class="">UA-discuss@icann.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)" class="">
<style class=""><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="blue" vlink="purple" class="">
<div class="WordSection1">
<p class="MsoNormal">The topic is in scope for discussion at the UASG meeting. We should have a point of view and share it. We should have a point of view on the work John and Asmus are doing, too.<o:p class=""></o:p></p>
<p class="MsoNormal"><o:p class=""> </o:p></p>
<p class="MsoNormal">I agree with Andrew’s points about emojis at this time.<o:p class=""></o:p></p>
<p class="MsoNormal"><a name="_MailEndCompose" class=""> </a></p>
<span style="mso-bookmark:_MailEndCompose" class=""></span>
<p class="MsoNormal"><b class="">From:</b> <a href="mailto:ua-discuss-bounces@icann.org" class="">
ua-discuss-bounces@icann.org</a> [<a href="mailto:ua-discuss-bounces@icann.org" class="">mailto:ua-discuss-bounces@icann.org</a>]
<b class="">On Behalf Of </b>Jothan Frakes<br class="">
<b class="">Sent:</b> Saturday, April 1, 2017 1:06 AM<br class="">
<b class="">To:</b> Andrew Sullivan <<a href="mailto:ajs@anvilwalrusden.com" class="">ajs@anvilwalrusden.com</a>><br class="">
<b class="">Cc:</b> <a href="mailto:ua-discuss@icann.org" class="">ua-discuss@icann.org</a><br class="">
<b class="">Subject:</b> Re: [UA-discuss] 69 New Emoji Have Been Approved By Unicode - Just in case you thought this Emoji stuff was a flash in the pan
<span style="font-family:"Segoe UI Emoji",sans-serif" class="">🍳💥</span><o:p class=""></o:p></p>
<p class="MsoNormal"><o:p class=""> </o:p></p>
<div class="">
<div class="">
<p class="MsoNormal">I started to reply in thread but I think it is better to say that i am aware of and we are in violent agreement about emoji issues with IDNA.<o:p class=""></o:p></p>
</div>
<div class="">
<div class="">
<p class="MsoNormal"><o:p class=""> </o:p></p>
<div class="">
<p class="MsoNormal">On Mar 31, 2017 12:29, "Andrew Sullivan" <<a href="mailto:ajs@anvilwalrusden.com" class="">ajs@anvilwalrusden.com</a>> wrote:<o:p class=""></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in" class="">
<div class="">
<p class="MsoNormal" style="margin-bottom:12.0pt">On Fri, Mar 31, 2017 at 12:00:53PM -0700, Jothan Frakes wrote:<br class="">
> I see this on the agenda for the Redmond/Seattle group meetings - are we<br class="">
> deciding if this is in scope or not?<o:p class=""></o:p></p>
</div>
<p class="MsoNormal">In scope for what? Emoji are just not allowed in the server-part<br class="">
unless you're suggesting that this group ought to be promoting names<br class="">
that are contrary to every IETF specification on the matter and are<br class="">
contrary to the ICANN IDN guidelines. If this group is in fact going<br class="">
to recommend sugh things, I predict that the future of acceptance is<br class="">
going to be even further from universal than you'd like.<br class="">
<br class="">
Perhaps you're talking about recommendations for use of emoji in<br class="">
local-parts, since email addresses are identifiers. Given the<br class="">
discussion in <a href="http://www.unicode.org/reports/tr36/" target="_blank" class="">
http://www.unicode.org/reports/tr36/</a> about visual<br class="">
spoofing, I hope the recommendation is just that emoji are interesting<br class="">
but poorly suited for identifiers. Since people can put literally<br class="">
anything they want in the local-part, they're going to do what they<br class="">
want anyway.<o:p class=""></o:p></p>
<div class="">
<p class="MsoNormal" style="margin-bottom:12.0pt"><br class="">
> efforts towards solutions in UA, and on the plus side, Emoji support seems<br class="">
> to get attention from the developers at the moment.<o:p class=""></o:p></p>
</div>
<p class="MsoNormal">Of course it does. Emoji are fun and cool. The problem is that<br class="">
they'll create an enormous security problem if people try to use them<br class="">
for real in identifiers, at least today.<o:p class=""></o:p></p>
<div class="">
<p class="MsoNormal" style="margin-bottom:12.0pt"><br class="">
> Emoji domains on the left side of the dot do work in a small subset of the<br class="">
> existing TLDs<o:p class=""></o:p></p>
</div>
<p class="MsoNormal">In some browsers. And what is this "the left side of the dot" of<br class="">
which you speak? DNS names are hierarchical. There are lots of<br class="">
possible dots.<br class="">
<br class="">
> - Addition of Emoji support as a primary project with an opportunity to<o:p class=""></o:p></p>
<div class="">
<p class="MsoNormal" style="margin-bottom:12.0pt">> introduce UA readiness - Developer 'in the code' for Emoji support can be<br class="">
> more efficient for the team and address the matters that give access to the<br class="">
> next billion customers.<o:p class=""></o:p></p>
</div>
<p class="MsoNormal">I am having a very hard time understanding what "in the code for emoji<br class="">
support" means, so I'd like to narrow that down.<o:p class=""></o:p></p>
<div class="">
<p class="MsoNormal" style="margin-bottom:12.0pt"><br class="">
> What I mean about Emoji is that they are often used as short form and are<br class="">
> composed using characters like :) (colon closeparen) that would be<br class="">
> typically illegal in a DOMAIN, URI, URL, SMTP or other protocol - so it may<br class="">
> open a new set of challenges beyond the already daunting set we're hoping<br class="">
> to chip away at in the existing quixotic list.<o:p class=""></o:p></p>
</div>
<p class="MsoNormal">The string ":)" is perfectly legal in the DNS but not legal in IDNA or<br class="">
under the LDH rules. It's extremely hard to use, however. The same<br class="">
is true in local-parts of email.<o:p class=""></o:p></p>
<div class="">
<p class="MsoNormal" style="margin-bottom:12.0pt"><br class="">
> messenger applications. Try :) in skype, facebook other messenger and in<br class="">
> most cases it converts to the emoji smiley face.<o:p class=""></o:p></p>
</div>
<p class="MsoNormal">Sometimes this is for display and sometimes this is on the wire.<br class="">
Figuring out which would be important. I can think of recommendations<br class="">
that would be useful to developers here, but they might be more<br class="">
properly developed as technical recommendations.<br class="">
<br class="">
> - There would have an issue with the interplay of IDNA and the<o:p class=""></o:p></p>
<div class="">
<p class="MsoNormal" style="margin-bottom:12.0pt">> 'automagic' emoji handling / conversion apps perform.<o:p class=""></o:p></p>
</div>
<p class="MsoNormal">Like that emoji and all punctuation are both not allowed under IDNA.<br class="">
<br class="">
Best regards,<br class="">
<br class="">
A<br class="">
<span style="color:#888888" class=""><br class="">
--<br class="">
Andrew Sullivan<br class="">
<a href="mailto:ajs@anvilwalrusden.com" class="">ajs@anvilwalrusden.com</a></span><o:p class=""></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p class=""> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>