March 2018 - UA-discuss - lists.iana.org

AUTO: Ahmed Bakhat Masood is out of the office. (returning 22/03/2018)
by Ahmed Bakhat Masood March 21, 2018

March 21, 2018

I am out of the office until 22/03/2018. I will not be able to respond to your mail. For urgent queries, please contact Mr. Shageel Ahmed Dy Director (ICT) at shargeel(a)pta.gov.pk or Mr. Anwar Zeb IT Officer at anwar(a)pta.gov.pk Note: This is an automated response to your message "UA-discuss Digest, Vol 39, Issue 16" sent on 03/21/2018 5:00:06 PM. This is the only notification you will receive while this person is away.

1 0

namespaces on XKCD
by Mark Svancarek March 20, 2018

March 20, 2018

https://www.xkcd.com/1963/

1 0

Re: [UA-discuss] [UA-EAI] Local Part Guidelines
by Mark Svancarek March 14, 2018

March 14, 2018

I suppose, but I worry that would just encourage people to argue that they shouldn't have been discarded. Is there any way to explain that there is a spec for EAI, if you do what it says you will interoperate, and if you do something else, even something else which you imagine to be better, you won't? I always struggle with this. I recognize that the answer is actually very simple and does not require any elaboration. Nevertheless, I have been willing to be more verbose, even redundant, when describing the sorts of downgrading which is disallowed, simply because the topics continued to pop up. But at this point in history, I conclude that everyone on this discussion list (and everyone on the general US-DISCUSS list, which I have cc'd on this reply) should now have been exposed to the discussions and the conclusions and should no longer need so much hand-holding. Based on that conclusion, I will be taking a harder line on the topic of email downgrading. I will start shutting down the topic more aggressively. As I warned in a mail after EAI Summit #2 earlier this year, this may require me to be blunt to the point of rudeness. Apologies in advance. Summary: * The UASG cannot recommend any transformation of a username/nickname at any time for any reason. * The UASG accepts that a replacement of a non-ascii mailbox name with an ascii mailbox name can be used in very limited circumstances (only IF the sending system 'owns' the sending mail address and IF an ascii address is pre-defined in an alias field and IF the first hop is clearly not EAI Ready). * Note that if a "non-owning" sender is aware of such aliases and has them in their local mailbox, the sender may devise a mechanism for performing their own method (manual or otherwise). Regardless, UASG cannot recommend any transformation of the username. * Mailbox administrators can use any characters or set of characters not explicitly disallowed by the RFCs in their mailbox configurations. * IETF PRECIS has defined username and nickname profiles, and these should be taken as good practice recommendations for mailbox administrators when they assign mailboxes. * Please don't start new discussions about downgrading on the mailing list. * If someone does start a new discussion about downgrading on the mailing list, please refrain from participating in that non-production discussion. /marksv -----Original Message----- From: UA-EAI [mailto:ua-eai-bounces@icann.org] On Behalf Of John Levine Sent: Tuesday, March 13, 2018 17:53 To: ua-eai(a)icann.org Subject: Re: [UA-EAI] Local Part Guidelines w> 1. The UASG cannot recommend any transformation of a mailbox at any time for any reason. > 2. The UASG accepts that a replacement of a non-ascii mailbox name >with an ascii mailbox name can be used in very limited circumstances - >basically where the sending system 'owns' the sending mail address and an ascii address is pre-defined in a alias field and the first hop is clearly not EAI Ready. Yes, those sound right. For #2 another plausible case is that the sender is doing the downgrade and has the aliases in the local address book. > 3. Mailbox administrators can use any characters or set of >characters not explicitly disallowed by the RFCs in their mailbox configurations. > * Does the UASG recommend any approach to avoid confusion? I would rather point to someone >else's well considered work in this area. Does such exist? That's what the IETF PRECIS work was about. The username and nickname profiles are both plausible for local parts. I put references into the Google draft. > 4. We may include an Appendix in the EAI Documentation with some >history and examples of transformations that were discarded and why. I suppose, but I worry that would just encourage people to argue that they shouldn't have been discarded. Is there any way to explain that there is a spec for EAI, if you do what it says you will interoperate, and if you do something else, even something else which you imagine to be better, you won't? R's, JOhn _______________________________________________ UA-EAI mailing list UA-EAI(a)icann.org<mailto:UA-EAI@icann.org> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o…

1 0

Issue needs discussion and closure
by Ajay Data March 13, 2018

March 13, 2018

Hello Friends, In UASG workshop today, we had a detailed recap and discussion on UA + EAI issues. During discussion, we agreed the following points to be discussed further and need resolution… 1. Sender ID as xn--anything in local part. If email server receives an email FROM xn--anything@validdomain , should email server at receiving end Do.. a. the conversion of xn--anything to UTF8 string. b. Leave it the way it was received i.e xn-anything 2. Is Mixing of scripts is allowed in mailbox local part While creating a mailbox like.. a. scripta@scriptbdomain - ajay <mailto:ajay@???????.????> @ਡਾਟਾਮੇਲ.ਭਾਰਤ b. scripta+scriptc@scriptbdomain ajayअजय(a)xn--n9bd4bq1db8d.xn--s9brj9c <mailto:?????@???????.????> 3. Alias ID on MUA: We already agreed that Downgrading of Alias is good practice and to be followed by email servers while communicating with legacy systems , however we have not discussed how Alias will be made available on MUA and if there are many Alias, than which will be used for downgrading. Lets discuss. Thanks. Ajay.

10 26

[Reminder] CfP Deadline March 9th for the 42nd Internationalization & Unicode Conference, Santa Clara, CA - September 10-12, 2018
by Jim DeLaHunt March 13, 2018

March 13, 2018

Hello, everyone: Just a reminder, the Internationalization and Unicode Conference (IUC) is accepting presentation proposals for the next few days. I strongly believe that this group has interesting accomplishments that the IUC should hear about. I hope that people will make proposals. I am going to make a proposal myself, and I'll describe it in a separate message. I have a couple more ideas which I am also working on. If anyone who doesn't know this conference would like to know more about it, I have a long history with them and I'm happy to share it. Please feel free to contact me off-list. Best regards, —Jim DeLaHunt, Vancouver, Canada -------- Forwarded Message -------- Subject: CfP Deadline March 9th for the 42nd Internationalization & Unicode Conference, Santa Clara, CA - September 10-12, 2018 Date: Mon, 5 Mar 2018 17:22:56 -0500 From: Unicode Conference <programs(a)unicodeconference.org> To: from.unicodeconf(a)jdlh.com IUC 42 Conference To see this message in your browser click *here <http://www.unicodeconference.org/e-marketing/IUC42-CfP-Reminder-030518.htm>* Internationalization & Unicode Conference 40. October 16-18, 2017 - Santa Clara, CA U.S.A. *Abstract Submission Deadline is Friday, March 9th!* The IUC 42 Program Committee invites you to submit your session, tutorial, or panel abstracts for the 42nd Internationalization & Unicode® Conference (IUC 42) in Santa Clara, California, September 10-12, 2018. Join other industry leaders as they map the future of internationalization, ignite new ideas, and showcase the latest technologies and best practices for creating, managing, and testing global, web, and multilingual software solutions. Let imagination be your only limit! Please submit a brief abstract by the deadline of Friday, March 9, 2018. Submit Now! <http://www.unicodeconference.org/call-for-participation.htm> * *The Program Committee will notify authors by Friday, April 13, 2018. Speaker agreements and materials such as photos, bios and final presentation abstracts will be required from selected presenters by Friday, April 27, 2018. Tutorial Presenters receive complimentary conference registration, and two nights lodging, while Session Presenters receive a fifty percent conference discount and two nights lodging. Please visit our website to view examples of content from past conferences <http://www.unicodeconference.org/past-conferences.htm>. GOLD SPONSOR: Adobe <http://www.unicodeconference.org/adobe-banner> MEDIA SPONSOR: Multilingual <http://www.unicodeconference.org/ml-banner/> *About The Unicode Consortium* The Unicode® Consortium is a non-profit organization founded to develop, extend and promote use of the Unicode Standard and related globalization standards. The membership of the consortium represents a broad spectrum of corporations and organizations in the computer and information processing industry. Members are: Adobe Systems, Apple, Google, Government of Bangladesh, Government of India, IBM, Microsoft, Monotype Imaging, Oracle, SAP, The Society for Natural Language Technology Research, The University of California (Berkeley), The University of California (Santa Cruz), Yahoo!, plus well over a hundred Associate, Liaison, and Individual members. For more information, please contact the Unicode Consortium <http://www.unicode.org/contacts.html>. *About the Event Producer* OMG <http://www.omg.org>® is the Event Producer for the Internationalization & Unicode Conferences. OMG is an international, open membership, not-for-profit computer industry standards consortium. OMG Task Forces develop enterprise integration standards for a wide range of technologies and an even wider range of industries. OMG's modeling standards, including the Unified Modeling Language™ (UML®) and Model Driven Architecture® (MDA®), enable powerful visual design, execution and maintenance of software and other processes, including IT Systems Modeling and Business Process Management. OMG's middleware standards and profiles are based on the Common Object Request Broker Architecture (CORBA®) and support a wide variety of industries. OMG has offices at 109 Highland Avenue, Needham, MA 02494 USA. This email may be considered to be commercial email, an advertisement or a solicitation. For more information about OMG, visit us online at http://www.omg.org. By accepting this email and not responding with an unsubscribe request, you have consented or "opted in" to receive additional correspondence and promotions from OMG and its associated partners and sponsors. Should you wish to opt-out in the future please visit http://www.omg.org/cgi-bin/unsubscribe.cgi.

2 2

Fwd: Re: base1024 encoding using Unicode emojis
by Asmus Freytag March 12, 2018

March 12, 2018

We generally think of emoji as a poor choice for reliable identifiers. Which makes this discussion on the public unicode mailing list somewhat interesting. A./ PS: the discussion is archived https://www.unicode.org/mail-arch/unicode-ml/y2018-m03/0075.html -------- Forwarded Message -------- Subject: Re: base1024 encoding using Unicode emojis Date: Mon, 12 Mar 2018 18:11:09 +0900 From: Martin J. Dürst via Unicode <unicode(a)unicode.org> Organization: Aoyama Gakuin University To: Keith Turner <keith(a)deenlo.com> CC: unicode Unicode Discussion <Unicode(a)unicode.org> On 2018/03/12 02:07, Keith Turner via Unicode wrote: > Yeah, it certainly results in larger utf8 strings. For example a sha256 > hash is 112 bytes when encoded as Ecoji utf8. For base64, sha256 is 44 > bytes. > > Even though its more bytes, Ecoji has less visible characters than base64 > for sha256. Ecoji has 28 visible characters and base64 44. So that makes > me wonder which one would be quicker for a human to verify on average? > Also, which one is more accurate for a human to verify? I have no idea. For > accuracy, it seems like a lot of thought was put into the visual uniqueness > of Unicode emojis. Using emoji to help people verify security information is an interesting idea. What I'm afraid is that even if emoji are designed with distinctiveness in mind, some people may have difficulties distinguish all the various face variants. Also, while emoji get designed so that in-font distinguishability is high, the same may not apply across fonts (e.g. if one has to compare a printed version with a version on-screen). Regards, Martin. >> 2018-03-11 6:04 GMT+01:00 Keith Turner via Unicode <unicode(a)unicode.org>: >> >>> I created a neat little project based on Unicode emojis. I thought >>> some on this list may find it interesting. It encodes arbitrary data >>> as 1024 emojis. The project is called Ecoji and is hosted on github >>> at https://github.com/keith-turner/ecoji >>> >>> Below are some examples of encoding and decoding. >>> >>> $ echo 'Unicode emojis are awesome!!' | ecoji >>> 🐦😱🔫🤜👢🔥🇮🐾💎🗓🔯🚜👖🚢🐙🌩💮🔪🎨🤚👥📤🌈📑 >>> >>> $ echo 🐦😱🔫🤜👢🔥🇮🐾💎🗓🔯🚜👖🚢🐙🌩💮🔪🎨🤚👥📤🌈📑 | ecoji -d >>> Unicode emojis are awesome!! >>> >>> I would eventually like to create a base4096 version when there are more >>> emojis.

2 2

launching a .Brand document
by Mark Svancarek March 11, 2018

March 11, 2018

Neustar has made this document available. At UASG workshop today, we pondered whether a generic document with similar content, but focused on UA-compliance and stripped of anything specific to any particular services provider, might be valuable for outreach. Please download and share your opinion. https://www.launchguide.neustar/

3 3

UASG WOrkshop in San Juan starting shortly in room 209A
by Don Hollander March 10, 2018

March 10, 2018

https://participate.icann.org/sju61-209a Don Don Hollander Secretary General - UASG Skype: Don_Hollander

1 0

IDN Variants and Universal Acceptance
by Don Hollander March 9, 2018

March 9, 2018

Please find attached a slide deck that we'll use in tomorrow's workshop. The topic is not and not so simple, so I am sending it out ahead of time. It is schedule for the morning, but the timing for tomorrow is still fluid. If this is an issue that you're particularly interested in, please let me know and we'll try to ping you before we start. Don

1 0

Mozillaʼs Pontoon
by Andre Schappo March 9, 2018

March 9, 2018

Today, I discovered Mozillaʼs Pontoon which facilitates webpage content translation in place ➜ pontoon.mozilla.org<http://pontoon.mozilla.org> Seems to me this would be a good mechanism to get uasg.tech<https://uasg.tech> translated into multiple languages André Schappo

3 3