- UA-discuss - lists.iana.org

World Hosting Days
by Don Hollander March 22, 2017

March 22, 2017

If you are considering going to the World Hosting Days coming up next week and haven’t yet registered, see below: Please find attached your free multicode : GL17DNF To register online please browse our Website : http://thewhdcloud.com/WHD/Global2017.aspx[thewhdcloud.com] <https://urldefense.proofpoint.com/v2/url?u=http-3A__thewhdcloud.com_WHD_Glo…> Don Hollander Universal Acceptance Steering Group Skype: don_hollander

1 0

UASG Vice-Chair Election results
by Don Hollander March 22, 2017

March 22, 2017

The UASG Election for Vice-Chair has closed and the results independently tallied and agreed by two people. In total, there were 60 votes - about 25% of the potential. Those elected (in alphabetical order) thus become: Edmon Chung Rich Merdinger Mark Svancarek Congratulations to them all. And I look forward to continued involvement from all the candidates. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

9 8

TWNIC
by Andre Schappo March 20, 2017

March 20, 2017

I have had a successful exchange of email between my DataMail 小山(a)xn--wny099c.xn--3ds443g and Ian at Taiwan NIC @台網中心.台灣 taiwanese email address😀 André Schappo

1 0

new update on EAI
by deepak March 17, 2017

March 17, 2017

Dear AllI just found interesting thing ... ZWNJ and ZWJ - Now easy to find. We have updated our https://eai.xgenplus.com to find if label or IDN has ZWNJ or ZWJ. Use unicode to html link. example: deaf&zwnjly - has ZWNJ secondly to simplify converting code point to character. Use unicode to UTF8.U+0033 - Digit 3Thanks. [XGENFOOTER] [-XGENFOOTER] Do not Remove: [HID]2017031717580499[-HID]

1 0

FYI: UA on circleid
by Lars Steffen March 15, 2017

March 15, 2017

Dirk Krischenowski from .berlin published this on circleid today: http://www.circleid.com/posts/20170314_universal_acceptance_new_tlds_reload… All best, Lars

1 0

Universal Acceptance - Public Forum - in B5.1
by Don Hollander March 15, 2017

March 15, 2017

On-line we’re at http://participate.icann.org/cph58-hallb51 Starting at 17:00 CPH time. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

1 0

Draft Notes: UASG Workshop @ ICANN58
by Don Hollander March 14, 2017

March 14, 2017

Please find attached the draft notes from the UASG Workshop held Sunday at the ICANN58 meeting in Copenhagen. It includes a summary of Action Items at the end of the document. Please do let me know if you think there should corrections or additions. Please also note that the slides from the session have been published on the UASG Website https://uasg.tech/ua-presentations/ Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

1 0

Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
by nalini.elkins＠insidethestack.com March 13, 2017

March 13, 2017

Sure. The problem is if you are trying to buy a name for a potential homographic attack or confusion and the original name belongs to someone else. In fact, is a trade mark of the other person. I have been doing some very fun work in this space. I have an algorithm which does permutations of names & we have been working on the homoglyphs. I have done some initial monitoring to see who has registered what names already. For example: www.TRÛMP.com www.TRÜMP.com have already been registered & not by our illustrious leader. Once I get things more figured out, I will set up a server to monitor continously. One of my guys is working on the homoglyphs, we are not happy with the confusables that others have referred to so we are doing our own. If you would like to know who has already registered "Microsoft"-ish names from my initial testing, please contact me privately. Nalini -------------------------------------------- On Mon, 3/13/17, Mark Svancarek <marksv(a)microsoft.com> wrote: Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt To: "nalini.elkins(a)insidethestack.com" <nalini.elkins(a)insidethestack.com>, "Shawn Steele" <Shawn.Steele(a)microsoft.com>, "Richard Merdinger" <rmerdinger(a)godaddy.com>, "Edmon Chung" <edmon(a)registry.asia>, "UA-discuss(a)icann.org" <UA-discuss(a)icann.org> Date: Monday, March 13, 2017, 6:22 AM To avoid the conflict, I could imagine a transaction like: "Your requested domain name Q has been identified as one likely to cause user confusions due to its mix of characters and character sets. (See our Confusables Policy, here). As a result, ownership of this domain name must be bundled with the following additional domain names: X Y Z This bundle of domain names is available for the low price of $$. Unfortunately, we are not able to offer the domain name Q separately from this bundle. If you are not interested in this bundle, might we suggest the following alternatives: H J K Thanks." -----Original Message----- From: nalini.elkins(a)insidethestack.com [mailto:nalini.elkins@insidethestack.com] Sent: Monday, March 13, 2017 1:35 PM To: Shawn Steele <Shawn.Steele(a)microsoft.com>; Richard Merdinger <rmerdinger(a)godaddy.com>; Edmon Chung <edmon(a)registry.asia>; UA-discuss(a)icann.org; Mark Svancarek <marksv(a)microsoft.com> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt >Pretty much all of the concerns regarding the character repertoire can be resolved and the registrar level if the registrars would ensure that they did not allow registrations of multiple domain variations that >might confuse their users. Or if they bundled those registrations. There is a potential conflict of interest here. Registries want to sell as many domains as they can as that is how they make money. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 From: Shawn Steele Sent: ‎3/‎12/‎2017 7:33 PM To: Richard Merdinger; Edmon Chung; Mark Svancarek; UA-discuss(a)icann.org Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt My concern is John’s emphasis on creating very restrictive character rule sets. The most restrictive rules created by IDNA2008 have been ignored because of user demand and backwards compatibility. Eg: no-emoji in labels. People want emoji, but IDNA2008 doesn’t permit it. Part of that is compatibility with the permitted IDNA2003 emoji, however there has also been demand for emoji characters newly added to Unicode. I think that it is appropriate to remind registrars that they are responsible for creating sane rules for their spaces, but it is clear that users do not want to be tied to the most restrictive demands of IDNA2008. Implementations appear to be settling on the Unicode provided idna data and I would much prefer to see the IETF standards point to the IDNA character sets provided by Unicode (while still encouraging registrars to do sane things that make sense for their domains). A good example of something a registrar might want to consider could be something like ü. Some spaces may allow ü without much restriction, however for .de, .ch, .at, etc. it might make sense to recognize that ü has an alternate ue spelling and to provide bundling or blocking of domains like müller.ch and mueller.ch. That kind of rule is very domain/language specific. Though it is not called out as some of the bidi rules are, the RFCs allow registrars to implement such a policy if it fits their purposes. Of course many other behaviors are called out by the IDNA2008 rules. Pretty much all of the concerns regarding the character repertoire can be resolved and the registrar level if the registrars would ensure that they did not allow registrations of multiple domain variations that might confuse their users. Or if they bundled those registrations. -Shawn From: Richard Merdinger [mailto:rmerdinger@godaddy.com] Sent: Saturday, March 11, 2017 11:35 PM To: Edmon Chung <edmon(a)registry.asia>; Mark Svancarek <marksv(a)microsoft.com>; UA-discuss(a)icann.org Cc: Shawn Steele <Shawn.Steele(a)microsoft.com> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Agree, thanks for forwarding Mark This was a very cogent statement of affairs relative to the closing out of known IDN issues (or our current inability to do so). I agree with Edmon in that I think the UA effort should strive to be a catalyst here. --Rich From: <ua-discuss-bounces(a)icann.org> on behalf of Edmon Chung <edmon(a)registry.asia> Date: Sunday, March 12, 2017 at 7:11 AM To: 'Mark Svancarek' <marksv(a)microsoft.com>, "UA-discuss(a)icann.org" <UA-discuss(a)icann.org> Cc: 'Shawn Steele' <Shawn.Steele(a)microsoft.com> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Thanks for forwarding this Mark, This seems to be something useful for UA, perhaps we should work with the IDN team at ICANN (along with the communities networked from the LGR work) to see where we can best support. Edmon -----Original Message----- From: ua-discuss-bounces(a)icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: Sunday, 12 March 2017 12:58 PM To: UA-discuss(a)icann.org Cc: Shawn Steele <Shawn.Steele(a)microsoft.com> Subject: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt FYI, too much stuff from John for me to dig into this a.m. -----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update(a)alvestrand.no Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Hi. For the information of those who may be watching this list but not the IETF announcement one... Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them. It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration. Comments (obviously) welcome. For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including: * Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome. * The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd- unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan. * The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction. It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents. john ---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts(a)ietf.org To: i-d-announce(a)ietf.org Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11 Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce(a)ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ---------- _______________________________________________ Idna-update mailing list Idna-update(a)alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update

4 3

Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
by nalini.elkins＠insidethestack.com March 13, 2017

March 13, 2017

>> FWIW (and to coin a phrase), I'd consider "www.TRÛMP.com" more of a "pun" than a "confusable". It's evocative of "Trump" but is visually distinct. > But of course, you can't actually register TRÛMP.com at all, because upper case characters are not allowed in U-labels. So you'd have to > register trûmp.com, and any sensible Latin variant strategy would require that the undecorated Latin characters would be variants of > decorated Latin characters. I was only displaying the name upper case to make it show up better. Of course, it is not just the "decoration" that is of interest. There are quite a few other characters from other scripts that are confusable possibilities. It is an interesting problem. For example, we took one 6 character name of a business which is trademarked & ran it through my algorithm, we came up with over 1 million possible permutations. This is because you can use more than one character look-alike. Lest you think that this doesn't happen, we have already found names registered which use more than one confusable. And, I have only just started my testing. One of the things that I want to do is to see exactly which "variants" or characters are most often used by potential miscreants. I call them "miscreants" because it is difficult for me to believe that someone who registers a variation of "mybank.com" or "apple.com" has something good on their mind. Nalini

3 2

Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
by nalini.elkins＠insidethestack.com March 13, 2017

March 13, 2017

Thanks for the good conversation, Andrew. It is a very difficult, and possibly impossible problem, with many differing opinions. > why isn't it your problem as a registrant to find these >things (maybe using NaliniAlgo™ ;-) ) and register the ones you find >problematic? I suspect that moving forward I should create a product / service around, as you say, NaliniAlgo™. Look forward to seeing you in Chicago. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Mon, 3/13/17, Andrew Sullivan <ajs(a)anvilwalrusden.com> wrote: Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt To: ua-discuss(a)icann.org Date: Monday, March 13, 2017, 8:46 AM On Mon, Mar 13, 2017 at 03:30:23PM +0000, nalini.elkins(a)insidethestack.com wrote> > I wonder. So, if the problem is hard, then we give up? I do not believe that the problem is merely "hard". It is literally impossible to fix in a general and algorithmic way, if by "fix" you mean "allow a vastly larger number of code points for registration and allow users to use things that are intuitive mnemonics for them and not have collisions". If you're willing to give up one of those dimensions, then that's fine; but you might be willing to give up a different one than someone else. Large TM Holder Corp will want to restrict names as much as possible -- ideally only to TM holders. Individuals might feel differently, and the tussle we have here boils down to that one. > One relatively easy suggestion might be that registries, ALL registries, attempt to detect such names. > And do what? What you're saying is that the people who got into the zone first win not only what they registered, but everything else that someone might want to register that could even possibly be mistaken for it. For the root zone -- necessarily a global resource -- I am probably prepared to support such a view. For other zones, I am less convinced: why isn't it your problem as a registrant to find these things (maybe using NaliniAlgo™ ;-) ) and register the ones you find problematic? > Don't let the perfect be the enemy of the good. I think I have heard you, actually, quote that in some presentation. > Often. But our problem here is not the definition of "perfect". It's the definition of "good". A -- Andrew Sullivan ajs(a)anvilwalrusden.com

1 0