are confusing similar gTLDs not confusing if the same registry has them all?

[Wendy Seltzer]

Milton L Mueller wrote:
> Avri
> I do not understand the rationale for your position.
> If I were .com, or .org, or .anything, of course I would want to have a similar-meaning or looking domain in different languages.
>
> I am not sure how .com can be considered "confusingly similar" to two chinese characters that mean "company" in putonghua. But even if it is, by some warped definition, how can it be "confusing" when both are run by the same company?

Because who's to assure that the same registry back-end will run them
such that end-user confusion (if it exists) is alleviated?  It might
just as easily extort its customers to "buy them all or we'll sell to
your competitors."

I dispute the basic premise of "confusing similarity" in most pairings,
but if that's a given, I'd object to letting a registry leverage claims
from one TLD string into rights in others.

--Wendy



> If Pepsi registers a trademark that is visually, aurally, or linguistically similar to its own logos or trademarked names, then of course there is no legal problem with that. Confusing means that you think it's Pepsi but it's not. If it is similar to Pepsi's brand and it is in fact Pepsi behind it, it's not confusing.
>
> With IDNs in particular, there is a pro-consumer case to be made for allowing the operator of .foo to have various IDN TLDs resembling .foo so that customers who already have a ascii .foo name can have something similar in IDN.
>
> Can you tell us more about what policy objective you are trying to achieve by preventing existing registry operators from applying for IDN strings related to their existing ASCII strings?
>
> --MM
> ________________________________________
> From: Non-Commercial User Constituency [NCUC-DISCUSS at LISTSERV.SYR.EDU] On Behalf Of Avri Doria [avri at LTU.SE]
> Sent: Wednesday, April 14, 2010 6:47 PM
> To: NCUC-DISCUSS at LISTSERV.SYR.EDU
> Subject: [NCUC-DISCUSS] are confusing similar gTLDs not confusing if the same registry has them all?
>
> Hi,
>
> The following is  a line from and IDNG Drafting Team where Chuck is proposing the following.
>
> Begin forwarded message:
>
>> I don't think that delay of the overall process is an option.  At the same time, I believe that a simple clarifying statement from the GNSO Council could be crafted on this issue.  It could be something along the lines of the following: "Recommendation 2 of the GNSO new gTLD recommendations (restriction of confusingly similar new gTLDs) was not intended to prevent an applicant from applying for multiple IDN versions of the same gTLD, whether that gTLD is an existing gTLD or a new gTLD."  I strongly believe that that is an accurate statement regardless of how one defines confusingly similar.
>
>
> I have sent a note indicating that I do not believe this is an accurate statement.
>
> I believe we should add a discussion of this to our meeting as it may be brought up in the Council meeting.
>
> I do not know where NCSG stands on the issue of a single applicant applying for the same stream in a multitude of scripts and being excused from the confusing similarly rules because it is all one registry applying for the names - e.g. .com in a multitude of scripts.  Especially since they believe that they should be no binding to rules of synchronicity (e.g. if you have the name in one, you have the same name in the other and it is an alias).
>
> i am personally against making any changes to the DAG without extensive discussions and under what if any constraints one would put on applicants in such a situation.
>
> The thread can be found starting at: http://forum.icann.org/lists/gnso-idng/msg00397.html
>
> looking forward to hearing people's view on the topic.
>
> a.
>
>


--
Wendy Seltzer -- wendy at seltzer.org
phone: +1.914.374.0613
Fellow, Silicon Flatirons Center at University of Colorado Law School
Fellow, Berkman Center for Internet & Society at Harvard University
http://cyber.law.harvard.edu/seltzer.html
http://www.chillingeffects.org/
https://www.torproject.org/