[ALAC] Singular/Plural in new gTLDs

Carlton Samuels carlton.samuels at gmail.com
Fri Sep 6 00:06:37 UTC 2013


........ see, in some quarters an IDN variant is the very definition of an "
*organic claim to 'similarity'*".

I believe there was a conscious decision to contain, if not frustrate, that
view; I used the term 'ring fence' as shorthand for that objective.

Contortions that make their way into the consciousness via use of language,
especially for folks that don't belong to the mouth breathing set, is
always purposeful.

Give the man a prize.

-Carlton




==============================
Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*
=============================


On Thu, Sep 5, 2013 at 6:11 PM, Edmon <edmon at isoc.hk> wrote:

> 2. seems to be a dangerous discussion as it is framed...
> I understand that Rinalia, you are not confusing the two, but those who are
> not particularly fond of IDN Variants often use these discussions to
> confuse
> the matter.
>
> There has been discussions about the issue not just on plurals but also IDN
> versions of an English TLD.  I think they are important discussions to be
> had, especially as we prepare for 2nd round of new gTLDs in the future.
> Nevertheless, it will need to be a rather separate discussion and must not
> be confused with the IDN Variant TLD issue.
>
> Edmon
>
>
>
>
>
> > -----Original Message-----
> > From: alac-bounces at atlarge-lists.icann.org [mailto:alac-bounces at atlarge-
> > lists.icann.org] On Behalf Of Rinalia Abdul Rahim
> > Sent: Wednesday, September 4, 2013 12:53 PM
> > To: Alan Greenberg
> > Cc: ALAC Working List
> > Subject: Re: [ALAC] Singular/Plural in new gTLDs
> >
> > 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" <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 <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
> > >> > ALAC at atlarge-lists.icann.org
> > >> >
> https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge-
> > lists.icann.org/mailman/listinfo/alac>
> > >> >
> > >> > At-Large Online: http://www.atlarge.icann.org
> > >> > ALAC Working Wiki: https://community.icann.org/**
> > >> display/atlarge/At-
> >
> Large+**Advisory+Committee+(ALAC)<
> https://community.icann.org/display/atlarg
> e/
> > At-Large+Advisory+Committee+(ALAC)>
> > >>
> > >
> > > ______________________________**_________________
> > > ALAC mailing list
> > > ALAC at atlarge-lists.icann.org
> > > https://atlarge-lists.icann.**org/mailman/listinfo/alac<
> https://atlarge-
> > lists.icann.org/mailman/listinfo/alac>
> > >
> > > At-Large Online: 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
> > ALAC at atlarge-lists.icann.org
> > https://atlarge-lists.icann.org/mailman/listinfo/alac
> >
> > At-Large Online: http://www.atlarge.icann.org
> > ALAC Working Wiki: https://community.icann.org/display/atlarge/At-
> > Large+Advisory+Committee+(ALAC)
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2013.0.3392 / Virus Database: 3222/6632 - Release Date: 09/02/13
>
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
>
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki:
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>



More information about the ALAC mailing list