[ALAC] Singular/Plural in new gTLDs

Fri Sep 6 00:04:51 UTC 2013

Hi Edmon.

You are right. I am not confused. I looked at it in terms of theoretical
applicability (I.e., if you have a similar problem between case A and case
B, could the method of solving the problem of case A be applied to case B).
One must let the imagination soar  to explore all possibilities and then
narrow it down when it comes down to brass tacks.

Hmm. I am starting to sound like Carlton. Speaking in metaphors.

Anyways, Alan: let's see a draft so that we can be more concrete and
constructive.

Rinalia
On Sep 6, 2013 7:11 AM, "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
>
>