69 New Emoji Have Been Approved By Unicode - Just in case you thought this Emoji stuff was a flash in the pan 🍳💥
https://www.forbes.com/sites <https://www.forbes.com/sites>
69 New Emoji Have Been Approved By Unicode Mar 30, 2017 @ 10:31 PM
Emojipedia
Emoji 5.0 / Photo Credit: Emojipedia <http://emojipedia.org/> Emojipedia founder and Chief Emoji Officer Jeremy Burge has announced <http://blog.emojipedia.org/final-2017-emoji-list/> that the Unicode Consortium has approved 69 emoji as part of the Emoji 5.0 update for 2017. The Unicode Consortium is a non-profit that develops software internationalization standards and data. Emoji 5.0 includes new smileys, foods, drinks, flags and people. And the Emoji 5.0 update will include new fantasy characters for the first time like mermaids (and mermen), zombies, elves, genies and vampires.
The Emoji 5.0 update is slated to release in June 2017 and it actually contains 239 emoji in total when gender and skin tone recommendations are included. After the Unicode Consortium encodes the new emoji, vendors like Apple, Google, Microsoft, Facebook and Twitter decide when to implement the changes. Google and Apple will likely implement the new emoji between October and December 2017. But the companies may potentially modify the emoji based on their preferences. For example, Apple replaced the gun emoji with a water gun in a previous emoji update. These 69 emoji will be joining approximately 2,000 other emoji that are already available. Here is a video that Emojipedia released introducing the new emoji:
There are a number of noteworthy additions in the Emoji 5.0 update. The update includes gender-inclusive versions of children, adults and older adults. Additions to the “faces” category include a star-struck face, a face with a raised eyebrow (inspired by Stephen Colbert), an exploding head, a face with symbols over the mouth (swearing), a shushing face, a face with a hand over the mouth and a face with a monocle. New emoji in the “animals” category include a zebra, a giraffe, a hedgehog, a sauropod, a T-Rex and a cricket. Emoji 5.0 includes the flags of England, Scotland and Wales. And emoji being introduced to the “food” category are a cut of meat (steak), a coconut, broccoli, a pretzel, a sandwich, cereal, canned food, a dumpling, a fortune cookie, a hot pie, a takeout box and a cup with a straw.
In this release, no gendered versions of breast-feeding, a bearded person or person with headscarf are being added. Male and female options will be available for yoga, rock climbing and person in steamy room. According to Burge via the Los Angeles Times <http://www.latimes.com/business/technology/la-fi-tn-new-emoji-gender-neutral...>, the bearded man, a woman in a hijab and the giraffe were some of the most requested emoji.
The proposal <https://www.forbes.com/sites/amitchowdhry/2016/11/29/hijab-gender-neutral-br...> of an emoji woman wearing a hijab was sought by a teenager named Rayouf Alhumedi, which was supported by Reddit co-founder Alexis Ohanian. The gender neutral emoji were proposed by Adobe designer Paul Hunt. And interestingly, the Ministry for Foreign Affairs of Finland pushed for the person in steamy room (sauna) emoji.
The Unicode Consortium has made it a priority to include diverse sets of emoji in every release. In November 2015, the Unicode Consortium published Emoji Version 2.0, which introduced skin tone modifier support. About a year later, the Unicode Consortium added 16 new emoji professions (including female and male versions) along with a rainbow flag. And the prospect of a redhead emoji is currently being discussed <http://blog.emojipedia.org/utc-provides-feedback-on-redhead-emoji/>.
Here is a list of the emoji contained in the Emoji 5.0 update <http://emojipedia.org/emojipedia/5.0/>:
- Face With One Eyebrow Raised (aka Colbert Emoji)
- Grinning Face With Star Eyes
- Grinning Face With One Large and One Small Eye
- Face With Finger Covering Closed Lips (aka Shhh)
- Serious Face With Symbols Covering Mouth (aka Swearing Face)
- Smiling Face With Smiling Eyes and Hand Covering Mouth
- Face With Monocle
- Shocked Face With Exploding Head
- Face With Open Mouth Vomiting
- Child (Gender-Inclusive; supports skin tones)
- Adult (Gender-Inclusive; supports skin tones)
- Older Adult (Gender-Inclusive; supports skin tones)
- Person With Headscarf (aka Hijab; supports skin tones)
- Bearded Person (Supports skin tones)
- Breast-Feeding (Supports skin tones)
- Woman Mage (aka Witch; supports skin tones)
- Man Mage (aka Wizard; supports skin tones)
- Woman Fairy (Supports skin tones)
- Man Fairy (Supports skin tones)
- Woman Vampire (Supports skin tones)
- Man Vampire (Supports skin tones)
- Merwoman (aka Mermaid; supports skin tones)
- Merman (Supports skin tones)
- Woman Elf (Supports skin tones)
- Man Elf (Supports skin tones)
- Woman Genie
- Man Genie
- Woman Zombie (Supports skin tones)
- Man Zombie (Supports skin tones)
- Woman in Steamy Room (aka Woman in Sauna; supports skin tones)
- Man in Steamy Room (aka Man in Sauna; supports skin tones)
- Woman Climbing (aka Female Rock Climber; supports skin tones)
- Man Climbing (aka Male Rock Climber; supports skin tones)
- Woman in Lotus Position (aka Meditation or Yoga; supports skin tones)
- Man in Lotus Position (aka Meditation or Yoga; supports skin tones)
- I Love You Hand Sign (Supports skin tones)
- Palms Up Together (Supports skin tones)
- Brain
- Orange Heart
- Scarf
- Gloves
- Coat
- Socks
- Billed Cap (aka Baseball Cap)
- Zebra Face
- Giraffe Face
- Hedgehog
- Sauropod
- T-Rex
- Cricket
- Coconut
- Broccoli
- Pretzel
- Cut of Meat (aka Steak)
- Sandwich
- Bowl With Spoon (aka Cereal)
- Canned Food
- Dumpling
- Fortune Cookie
- Takeout Box
- Pie
- Cup With Straw (aka Soda or Milkshake)
- Chopsticks
- Flying Saucer
- Sled
- Curling Stone
- Flag for England
- Flag for Scotland
- Flag for Wales
What are your thoughts about the new emoji? Which of these emoji do you plan to use the most? Please leave a comment!
Don Hollander Universal Acceptance Steering Group Skype: don_hollander
Interesting... I saw a few that would be appropriate for the hieroglyphic record of our efforts from that new set. ;) I see this on the agenda for the Redmond/Seattle group meetings - are we deciding if this is in scope or not? I talk often about the many groups of developers that I interact with in my efforts towards solutions in UA, and on the plus side, Emoji support seems to get attention from the developers at the moment. On the plus side of things, maybe that attention opens the door to 'while you are under the hood looking at your code to support Emoji, take a look at how you are handling domains' discussions. Emoji domains on the left side of the dot do work in a small subset of the existing TLDs, but for the most part are not really available en masse. This plays out a couple ways within developer/executives for defining the work scope. - 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. - UA readiness initiative as guise for introducing Emoji support - Developer wants to add Emoji but need story to justify it, so they define the project as being performed to give access to the next billion customers and while they are 'in the code' add Emoji support. Now, on the challenges side of things, this could be scope expansion if we are going to incorporate Emoticon support into our discussions. 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. Software behavior seems to often me that the application 'automagically' transposes them to or from their ASCII representation, like in many messenger applications. Try :) in skype, facebook other messenger and in most cases it converts to the emoji smiley face. I am not saying we should not be looking at the Emoji support concept, but there are some massive things to address which widen our scope immensely. - There would have an issue with the interplay of IDNA and the 'automagic' emoji handling / conversion apps perform. - There would be issues where there are standards that might break in the presence of ASCII characters used to compose emoji by users into apps that don't translate 'automagically', where those characters break the format of the protocol or are illegal in or confuse protocols being handled in an expected manner (such as but not limited to ":", ";", "/" etc.). - [long other list of things but those two are quite large and I was hoping to remain in the tl;dr realm on this] Seems to me like leveraging the interest of people to add Emoji support may be opening a window of opportunity for the conversations around UA, and we might benefit there, but I would encourage that we let the conversations on Emoji domains run their courses elsewhere so that we don't become distracted by them or try to boil that larger ocean. -Jothan Jothan Frakes Tel: +1.206-355-0230 On Fri, Mar 31, 2017 at 7:18 AM, Don Hollander <don.hollander@icann.org> wrote:
69 New Emoji Have Been Approved By Unicode Mar 30, 2017 @ 10:31 PM [image: Emoji 5.0 / Photo Credit: Emojipedia]
Emojipedia
Emoji 5.0 / Photo Credit: Emojipedia <http://emojipedia.org/>
Emojipedia founder and Chief Emoji Officer Jeremy Burge has announced <http://blog.emojipedia.org/final-2017-emoji-list/> that the Unicode Consortium has approved 69 emoji as part of the Emoji 5.0 update for 2017. The Unicode Consortium is a non-profit that develops software internationalization standards and data. Emoji 5.0 includes new smileys, foods, drinks, flags and people. And the Emoji 5.0 update will include new fantasy characters for the first time like mermaids (and mermen), zombies, elves, genies and vampires.
The Emoji 5.0 update is slated to release in June 2017 and it actually contains 239 emoji in total when gender and skin tone recommendations are included. After the Unicode Consortium encodes the new emoji, vendors like Apple, Google, Microsoft, Facebook and Twitter decide when to implement the changes. Google and Apple will likely implement the new emoji between October and December 2017. But the companies may potentially modify the emoji based on their preferences. For example, Apple replaced the gun emoji with a water gun in a previous emoji update. These 69 emoji will be joining approximately 2,000 other emoji that are already available. Here is a video that Emojipedia released introducing the new emoji:
There are a number of noteworthy additions in the Emoji 5.0 update. The update includes gender-inclusive versions of children, adults and older adults. Additions to the “faces” category include a star-struck face, a face with a raised eyebrow (inspired by Stephen Colbert), an exploding head, a face with symbols over the mouth (swearing), a shushing face, a face with a hand over the mouth and a face with a monocle. New emoji in the “animals” category include a zebra, a giraffe, a hedgehog, a sauropod, a T-Rex and a cricket. Emoji 5.0 includes the flags of England, Scotland and Wales. And emoji being introduced to the “food” category are a cut of meat (steak), a coconut, broccoli, a pretzel, a sandwich, cereal, canned food, a dumpling, a fortune cookie, a hot pie, a takeout box and a cup with a straw.
In this release, no gendered versions of breast-feeding, a bearded person or person with headscarf are being added. Male and female options will be available for yoga, rock climbing and person in steamy room. According to Burge via the Los Angeles Times <http://www.latimes.com/business/technology/la-fi-tn-new-emoji-gender-neutral...>, the bearded man, a woman in a hijab and the giraffe were some of the most requested emoji.
The proposal <https://www.forbes.com/sites/amitchowdhry/2016/11/29/hijab-gender-neutral-br...> of an emoji woman wearing a hijab was sought by a teenager named Rayouf Alhumedi, which was supported by Reddit co-founder Alexis Ohanian. The gender neutral emoji were proposed by Adobe designer Paul Hunt. And interestingly, the Ministry for Foreign Affairs of Finland pushed for the person in steamy room (sauna) emoji.
The Unicode Consortium has made it a priority to include diverse sets of emoji in every release. In November 2015, the Unicode Consortium published Emoji Version 2.0, which introduced skin tone modifier support. About a year later, the Unicode Consortium added 16 new emoji professions (including female and male versions) along with a rainbow flag. And the prospect of a redhead emoji is currently being discussed <http://blog.emojipedia.org/utc-provides-feedback-on-redhead-emoji/>.
Here is a list of the emoji contained in the Emoji 5.0 update <http://emojipedia.org/emojipedia/5.0/>:
- Face With One Eyebrow Raised (aka Colbert Emoji)
- Grinning Face With Star Eyes
- Grinning Face With One Large and One Small Eye
- Face With Finger Covering Closed Lips (aka Shhh)
- Serious Face With Symbols Covering Mouth (aka Swearing Face)
- Smiling Face With Smiling Eyes and Hand Covering Mouth
- Face With Monocle
- Shocked Face With Exploding Head
- Face With Open Mouth Vomiting
- Child (Gender-Inclusive; supports skin tones)
- Adult (Gender-Inclusive; supports skin tones)
- Older Adult (Gender-Inclusive; supports skin tones)
- Person With Headscarf (aka Hijab; supports skin tones)
- Bearded Person (Supports skin tones)
- Breast-Feeding (Supports skin tones)
- Woman Mage (aka Witch; supports skin tones)
- Man Mage (aka Wizard; supports skin tones)
- Woman Fairy (Supports skin tones)
- Man Fairy (Supports skin tones)
- Woman Vampire (Supports skin tones)
- Man Vampire (Supports skin tones)
- Merwoman (aka Mermaid; supports skin tones)
- Merman (Supports skin tones)
- Woman Elf (Supports skin tones)
- Man Elf (Supports skin tones)
- Woman Genie
- Man Genie
- Woman Zombie (Supports skin tones)
- Man Zombie (Supports skin tones)
- Woman in Steamy Room (aka Woman in Sauna; supports skin tones)
- Man in Steamy Room (aka Man in Sauna; supports skin tones)
- Woman Climbing (aka Female Rock Climber; supports skin tones)
- Man Climbing (aka Male Rock Climber; supports skin tones)
- Woman in Lotus Position (aka Meditation or Yoga; supports skin tones)
- Man in Lotus Position (aka Meditation or Yoga; supports skin tones)
- I Love You Hand Sign (Supports skin tones)
- Palms Up Together (Supports skin tones)
- Brain
- Orange Heart
- Scarf
- Gloves
- Coat
- Socks
- Billed Cap (aka Baseball Cap)
- Zebra Face
- Giraffe Face
- Hedgehog
- Sauropod
- T-Rex
- Cricket
- Coconut
- Broccoli
- Pretzel
- Cut of Meat (aka Steak)
- Sandwich
- Bowl With Spoon (aka Cereal)
- Canned Food
- Dumpling
- Fortune Cookie
- Takeout Box
- Pie
- Cup With Straw (aka Soda or Milkshake)
- Chopsticks
- Flying Saucer
- Sled
- Curling Stone
- Flag for England
- Flag for Scotland
- Flag for Wales
*What are your thoughts about the new emoji? Which of these emoji do you plan to use the most? Please leave a comment!*
Don Hollander Universal Acceptance Steering Group Skype: don_hollander
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/ 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
On 3/31/2017 12:28 PM, Andrew Sullivan 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?
An input into the evolving emoji specifications might be useful, so that the issue of why they are so unsuitable for identifier gets some raised visibility. The twin problem with emoji is first, that they look very concrete when presented as images - unlike some "foreign" scripts, everybody thinks they can read/recognize them; and second, that they are incredibly appealing to people who view DNS labels as expression of their identity. From a technical point it might be enough to point to the IDNA parameters, but from an outreach point of view, this falls woefully short. (I do like Andrew's various summaries of the issue; they should get incorporated into UTR#51 ...) A./
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/ 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
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> 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/ 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
Could someone provide the reference information about what is and is not allowed from Unicode for a valid IDN? If a Unicode value is marked as both text and Emoji, is it allowed? The ones I know about off-the-top of my head -- ‼ and ‽ are likely not but the list at http://www.unicode.org/reports/tr51/index.html implies many. In fact, it seems like 0-9 can be identified as Emoji (per http://unicode.org/Public/emoji/4.0/emoji-data.txt). From: 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> Cc: 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/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.unicode.org%2Freports%2Ftr36%2F&data=02%7C01%7Cstuartst%40exchange.microsoft.com%7C797d1565717940a9171c08d478d5f741%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636266307758006582&sdata=OnvSgcLBlEHc7Wh%2BkddNcv3epmVFXZ3bwWPzCglXZ4U%3D&reserved=0> 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>
I would start with RFC 5892. -Dennis From: <ua-discuss-bounces@icann.org> on behalf of "UA-discuss@icann.org" <ua-discuss@icann.org> Reply-To: Stuart Stuple <stuartst@microsoft.com> Date: Sunday, April 2, 2017 at 12:04 PM To: Jothan Frakes <jothan@jothan.com>, Andrew Sullivan <ajs@anvilwalrusden.com> Cc: "UA-discuss@icann.org" <ua-discuss@icann.org> Subject: [EXTERNAL] 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 🍳💥 Could someone provide the reference information about what is and is not allowed from Unicode for a valid IDN? If a Unicode value is marked as both text and Emoji, is it allowed? The ones I know about off-the-top of my head -- ‼ and ‽ are likely not but the list at http://www.unicode.org/reports/tr51/index.html implies many. In fact, it seems like 0-9 can be identified as Emoji (per http://unicode.org/Public/emoji/4.0/emoji-data.txt). From: 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> Cc: 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/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.unicode.org%2Freports%2Ftr36%2F&data=02%7C01%7Cstuartst%40exchange.microsoft.com%7C797d1565717940a9171c08d478d5f741%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636266307758006582&sdata=OnvSgcLBlEHc7Wh%2BkddNcv3epmVFXZ3bwWPzCglXZ4U%3D&reserved=0> 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>
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] On Behalf Of Jothan Frakes Sent: Saturday, April 1, 2017 1:06 AM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: 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/ 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>
Further clarifying: My opinions apply to anything outside of IDNA, not just emoji – if it’s not allowed by IETF and/or IDNA, it’s problematic. That doesn’t mean our point of view can’t involve trying to influence IETF and IDNA. I think those might be interesting courses of action if we want to sign up for something difficult. I don’t know that we have the level of commitment for that. As Andrew explains, it would be tricky and hard and long-term, so it is a good topic for discussion at UASG. From: Mark Svancarek Sent: Monday, April 3, 2017 8:09 AM To: 'Jothan Frakes' <jothan@jothan.com>; Andrew Sullivan <ajs@anvilwalrusden.com> Cc: 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 🍳💥 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/ 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>
Hi, On Mon, Apr 03, 2017 at 04:24:36PM +0000, Mark Svancarek via UA-discuss wrote:
My opinions apply to anything outside of IDNA, not just emoji – if it’s not allowed by IETF and/or IDNA, it’s problematic.
I think you may want to spend a little more time with the Unicode standard, because most of the reasons that the IETF "disallows" something is because it doesn't conform to the categories useful for identifiers. I.e. identifiers are best composed of letters and digits and maybe some other things (see the PRECIS framework for more discussion), and emoji aren't any of those things. It's not the IETF that is saying emoji make bad identifiers. It's Unicode. If you want to lobby someone, go talk to them. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
I understand what you are saying about letters, digits and others, but I am not familiar with Unicode defining good identifiers - where is that? -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Monday, April 3, 2017 10:41 AM To: 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 🍳💥 Hi, On Mon, Apr 03, 2017 at 04:24:36PM +0000, Mark Svancarek via UA-discuss wrote:
My opinions apply to anything outside of IDNA, not just emoji – if it’s not allowed by IETF and/or IDNA, it’s problematic.
I think you may want to spend a little more time with the Unicode standard, because most of the reasons that the IETF "disallows" something is because it doesn't conform to the categories useful for identifiers. I.e. identifiers are best composed of letters and digits and maybe some other things (see the PRECIS framework for more discussion), and emoji aren't any of those things. It's not the IETF that is saying emoji make bad identifiers. It's Unicode. If you want to lobby someone, go talk to them. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
On Mon, Apr 03, 2017 at 06:59:13PM +0000, Mark Svancarek wrote:
I understand what you are saying about letters, digits and others, but I am not familiar with Unicode defining good identifiers - where is that?
http://unicode.org/reports/tr31/ As near as I can tell (but I haven't checked exhaustively), emoji are Identifier_Type Not_XID. It's interesting because, according to Mark Davis, e.g.♠ U+2660 BLACK SPADE SUIT is legal under UTS#46 (because legal under IDNA2003). It's an emoji because it became one when some of the symbols in Unicode 3.2 got the emoji property when later versions of Unicode came out. Note that there definitely _are_ things disallowed by IDNA2008 that would be ok under UAX#31, because IDNA was trying to internationalize LDH and UAX#31 is more general than that. But my reading is that UAX#31 explicitly approves of such additional restriction. Hope that helps, A -- Andrew Sullivan ajs@anvilwalrusden.com
Thanks! I'll become more informed. -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Monday, April 3, 2017 12:27 PM To: 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 🍳💥 On Mon, Apr 03, 2017 at 06:59:13PM +0000, Mark Svancarek wrote:
I understand what you are saying about letters, digits and others, but I am not familiar with Unicode defining good identifiers - where is that?
http://unicode.org/reports/tr31/ As near as I can tell (but I haven't checked exhaustively), emoji are Identifier_Type Not_XID. It's interesting because, according to Mark Davis, e.g.♠ U+2660 BLACK SPADE SUIT is legal under UTS#46 (because legal under IDNA2003). It's an emoji because it became one when some of the symbols in Unicode 3.2 got the emoji property when later versions of Unicode came out. Note that there definitely _are_ things disallowed by IDNA2008 that would be ok under UAX#31, because IDNA was trying to internationalize LDH and UAX#31 is more general than that. But my reading is that UAX#31 explicitly approves of such additional restriction. Hope that helps, A -- Andrew Sullivan ajs@anvilwalrusden.com
Halon 4.0: "Live staging and SMTPUTF8 coming up in Halon 4.0" https://halon.io/blog/live-staging-smtputf8-halon-4-0/ Of particular note is the sentence: "Another major feature is SMTPUTF8, which allows for international (and emoji!) email addresses." André Schappo
Sure - and the short version of my initial comment had suggested we perhaps as part of our discussion we have a prepared message around 'while you are under the hood to add smileys, why not enable access to a massive group of new customers' Jothan Frakes Tel: +1.206-355-0230 On Mon, Apr 3, 2017 at 8:08 AM, Mark Svancarek <marksv@microsoft.com> 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] *On Behalf Of *Jothan Frakes *Sent:* Saturday, April 1, 2017 1:06 AM *To:* Andrew Sullivan <ajs@anvilwalrusden.com> *Cc:* 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> 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/ 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
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 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/ 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>
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>
participants (8)
-
Andre Schappo -
Andrew Sullivan -
Asmus Freytag -
Don Hollander -
Jothan Frakes -
Mark Svancarek -
Stuart Stuple -
Tan Tanaka, Dennis