[ALAC] Singular/Plural in new gTLDs

Alan Greenberg alan.greenberg at mcgill.ca
Wed Sep 4 13:05:45 UTC 2013


Thanks Rinalia.

Regarding 1, yes, is the decision were revered, it would establish 
some new (or larger) contenction sets.

On blocking a name so that it is only one of the TLDs (or 
alternatively bundling them together), a bit problematic if the two 
TLDs are operated by different registries.

Alan

At 04/09/2013 12:53 AM, Rinalia Abdul Rahim wrote:

>Dear Alan,
>
>I support doing something about this.
>
>2 thoughts:
>1. A positive result of intervention on this matter where singular 
>and plural strings are deemed similarly confusing (and thus not 
>allowed) will result in the strings implicated to be in contention. 
>This will no doubt heat up the string contention and objection 
>resolution process. No valued judgment in this, just stating an 
>observation of what to expect.
>
>2. There is a practice in IDN variant management that can 
>theoretically be applied to avoid applicants from having to "buy" 
>two confusingly similar names (if the policy is not to allow 
>singular and plural names). This is the practice/rule of allocating 
>both names to an applicant and then blocking one of those names or 
>allowing both names (perhaps for the price of one - need to check on 
>whether they charge for the "variants" - I suspect not). And yes, 
>the IP-interested folks might have something to say about it 
>depending on whether they are in favor of over-protection or less.
>
>Best regards,
>
>Rinalia
>On Sep 4, 2013 12:29 PM, "Alan Greenberg" 
><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca> wrote:
>That could be done. But first I wanted to find out if there was any 
>interest within the ALAC. If there is little interest, I will do 
>something on my own, but with far less impact than if it is advice 
>from the ALAC.
>
>Also note that this is an issue that is extremely time-sensitive, 
>since if the issue is to be re-opened, it will have to be done very quickly.
>
>Alan
>
>At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
>Dear Alan,
>
>Thank you for monitoring this space. I would suggest opening the 
>discussions within the broader At Large to solicit views and 
>feedback, preferably if the discussions could ensue on both the 
>mailing list as well as the wiki before a statement is drafted.
>
>Kind Regards,
>Sala
>
>Sent from my iPad
>
>On Sep 4, 2013, at 2:02 PM, Alan Greenberg 
><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca> wrote:
>
> > On 24 June 2013 as requested by the GAC, the Board New gTLD 
> Program Committee (NGPC) considered the issue of singular and 
> plural stings being confusingly similar and decided to let the 
> original process stand (subject to individual objections). The 
> record of the decision can be found at 
> <http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.htm#2.d>http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.htm#2.d. 
> Of particular note is a statement issued by three Board members 
> (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who 
> supported the decision but regretted that, based on the Applicant 
> Guidebook wording, they did not believe that they had the leeway to 
> vote against it. One Board member (Mike Silber) did oppose the decision.
> >
> > A central issue is that "confusingly similar" test relies purely 
> on visual similarity and in the eyes of most (who were involved in 
> the decision), adding an "S" makes it a recognizably different string.
> >
> > The salient part of the Applicant Guidebook 
> (<http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf>http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf) 
> is section 2.2.1.1 of Module 2.
> >
> >> This review involves a preliminary comparison of each 
> applied-for gTLD string against existing TLDs, Reserved Names (see 
> subsection 2.2.1.2), and other applied-for strings. The objective 
> of this review is to prevent user confusion and loss of confidence 
> in the DNS resulting from delegation of many similar strings.
> >>
> >> Note: In this Applicant Guidebook, "similar" means strings so 
> similar that they create a probability of user confusion if more 
> than one of the strings is delegated into the root zone.
> >>
> >> The visual similarity check that occurs during Initial 
> Evaluation is intended to augment the objection and dispute 
> resolution process (see Module 3, Dispute Resolution Procedures) 
> that addresses all types of similarity.
> >
> > I believe that the NGPC decision was incorrect. The problem is 
> the belief that "visual similarity" relies purely on what, in 
> computer terminology, would be called "pattern matching". Pattern 
> matching is certainly part of human perception, but it is not 
> limited to that. At issue is whether two strings will be PERCEIVED 
> as being equivalent, and perception is a far more complex (and less 
> understood) issue.
> >
> > The real issue is that if you earlier found something at 
> hilton.hotel, or had decided that the reviews at sheraton.hotel 
> were something you trusted, will you later remember if it was 
> really those sites or hilton.hotels or sheraton.hotels?
> >
> > At best, this could be considered a means of forcing anyone who 
> registers a domain with .hotel or .hotels to register both, and map 
> both of them to the same site. If that were to happen, the 
> predictions of the Intellectual Property Constituency would be 
> borne out, and all of those using these TLDs would have to make 
> double the investment in domain names (presuming this is even 
> possible with differing rules for each TLD). But the impact on 
> users would be minimal.
> >
> > But since we cannot guarantee that both TLDs will remain forever 
> in sync, we do have a user problem. Once cannot expect the typical 
> Internet user to be able to differentiate between two such name 
> spaces, and therefore I believe that we have a genuine case of 
> "confusingly similar". And one that will arguably have as much or 
> more impact on real Internet users, the ones that we are supposed 
> to be here to defend, than any other case I can recall in my 7 year 
> involvement with ICANN At-Large.
> >
> > If others on the ALAC agree, I would be happy to create a 
> statement reflecting what I have said here, that we can, in our 
> formal Advisory Committee role, forward as Advice to the Board.
> >
> > Alan
> >
> > _______________________________________________
> > ALAC mailing list
> > <mailto:ALAC at atlarge-lists.icann.org>ALAC at atlarge-lists.icann.org
> > https://atlarge-lists.icann.org/mailman/listinfo/alac
> >
> > At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org
> > ALAC Working Wiki: 
> <https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>
>
>_______________________________________________
>ALAC mailing list
><mailto:ALAC at atlarge-lists.icann.org>ALAC at atlarge-lists.icann.org
>https://atlarge-lists.icann.org/mailman/listinfo/alac
>
>At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org
>ALAC Working Wiki: 
><https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)



More information about the ALAC mailing list