On 4/3/2017 9:41 AM, Andre Schappo wrote:
Given an email address local-part@domain-name
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 﨨 http://www.verisign.com/assets/languagefiles/CHI.html
Only 12 code points in that block are PVALID. U+FA28 is one of them, essentially because it was misidentified as "compatibility", when, in fact, it is a Unified Ideograph.
The point I am making WRT the domain-name is that, currently, it is largely determined by standards, standards groups and registries.
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.
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.
Take email addresses of the form (there are other forms)
comment <full email address>
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.
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.
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.
André Schappo
On 3 Apr 2017, at 16:08, Mark Svancarek via UA-discuss <UA-discuss@icann.org <mailto:UA-discuss@icann.org>> wrote:
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.
I agree with Andrew’s points about emojis at this time.
*From:* ua-discuss-bounces@icann.org <mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] *On Behalf Of *Jothan Frakes *Sent:* Saturday, April 1, 2017 1:06 AM *To:* Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> *Cc:* ua-discuss@icann.org <mailto:ua-discuss@icann.org> *Subject:* 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 🍳💥
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.
On Mar 31, 2017 12:29, "Andrew Sullivan" <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
On Fri, Mar 31, 2017 at 12:00:53PM -0700, Jothan Frakes wrote: > I see this on the agenda for the Redmond/Seattle group meetings - are we > deciding if this is in scope or not?
In scope for what? Emoji are just not allowed in the server-part unless you're suggesting that this group ought to be promoting names that are contrary to every IETF specification on the matter and are contrary to the ICANN IDN guidelines. If this group is in fact going to recommend sugh things, I predict that the future of acceptance is going to be even further from universal than you'd like.
Perhaps you're talking about recommendations for use of emoji in local-parts, since email addresses are identifiers. Given the discussion in http://www.unicode.org/reports/tr36/ <http://www.unicode.org/reports/tr36/> about visual spoofing, I hope the recommendation is just that emoji are interesting but poorly suited for identifiers. Since people can put literally anything they want in the local-part, they're going to do what they want anyway.
> efforts towards solutions in UA, and on the plus side, Emoji support seems > to get attention from the developers at the moment.
Of course it does. Emoji are fun and cool. The problem is that they'll create an enormous security problem if people try to use them for real in identifiers, at least today.
> Emoji domains on the left side of the dot do work in a small subset of the > existing TLDs
In some browsers. And what is this "the left side of the dot" of which you speak? DNS names are hierarchical. There are lots of possible dots.
> - Addition of Emoji support as a primary project with an opportunity to
> introduce UA readiness - Developer 'in the code' for Emoji support can be > more efficient for the team and address the matters that give access to the > next billion customers.
I am having a very hard time understanding what "in the code for emoji support" means, so I'd like to narrow that down.
> What I mean about Emoji is that they are often used as short form and are > composed using characters like :) (colon closeparen) that would be > typically illegal in a DOMAIN, URI, URL, SMTP or other protocol - so it may > open a new set of challenges beyond the already daunting set we're hoping > to chip away at in the existing quixotic list.
The string ":)" is perfectly legal in the DNS but not legal in IDNA or under the LDH rules. It's extremely hard to use, however. The same is true in local-parts of email.
> messenger applications. Try :) in skype, facebook other messenger and in > most cases it converts to the emoji smiley face.
Sometimes this is for display and sometimes this is on the wire. Figuring out which would be important. I can think of recommendations that would be useful to developers here, but they might be more properly developed as technical recommendations.
> - There would have an issue with the interplay of IDNA and the
> 'automagic' emoji handling / conversion apps perform.
Like that emoji and all punctuation are both not allowed under IDNA.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>
