NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0 (Apple Message framework v1078)
Content-Type:
text/plain; charset=us-ascii
Date:
Sat, 17 Apr 2010 11:07:24 -0400
Reply-To:
Avri Doria <[log in to unmask]>
Subject:
From:
Avri Doria <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
quoted-printable
Sender:
Non-Commercial User Constituency <[log in to unmask]>
Parts/Attachments:
text/plain (212 lines)
Hi,

Thanks.

What I do not have yet is written chapter and verse to quote for the arguments.  It will take me time to get that all sorted and i can use help in doing so.

It might be good to start developing a well formed and well documented NCSG position on this issue.

a.


On 17 Apr 2010, at 09:37, Milton L Mueller wrote:

> I don't think your reply is so weak, especially when it quotes the DAG3 section 3.4.1. 
> Really what he seems to be arguing is that an incumbent TLD operator can control the "meaning" of a TLD, not just string confusion. 
> When Chuck quotes trademark treaties you might remind him that trademark law applies to a wide variety of identifiers, not just domain names, and that TLDs have no colors, are rarely "pronounced" as words or normal names are pronounced - so a lot of the TM confusing similarity stuff just doesn't apply. 
> 
>> -----Original Message-----
>> From: Non-Commercial User Constituency [mailto:NCUC-
>> [log in to unmask]] On Behalf Of Avri Doria
>> Sent: Friday, April 16, 2010 10:27 PM
>> To: [log in to unmask]
>> Subject: Re: [NCUC-DISCUSS] are confusing similar gTLDs not confusing if
>> the same registry has them all?
>> 
>> Hi,
>> 
>>>> Or is that battle already lost?
>>> 
>>> I do not believe it is lost.  The DAG from m reading still upholds the
>> visual criteria for confusing similarity.
>>> 
>>> It is just that Chuck and others repeat that it includes meaning so
>> often and so absolutley that it is gaining currency and while I don't
>> find it in my reading of DAGv3, they claim it is a viable option for
>> objection by a current string holder.
>> 
>> But Chuck is going to fight tooth and nail for the position.
>> 
>> The following is his argument.  i will be working on a response in the
>> next days although i already sent a preliminary response which i will
>> append after his message.
>> 
>> 
>>> 
>>> Let me first start with your minority statement that accompanied the
>>> final GNSS Report:
>>> http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-
>> 08aug07.htm#_T
>>> oc48210874.  If you believed that the GNSO report defined confusing
>>> similarity as visual only and that that was a position of the GNSO
>>> Council, then it would not have been necessary for you to express the
>>> following reservations about that recommendation:
>>> 
>>> "In the first instance I believe that this is essentially a technical
>>> issue that should have been resolved with reference to typography,
>>> homologues, orthographic neighbourhood, transliteration and other
>>> technically defined attributes of a name that would make it
>>> unacceptable. There is a large body of scientific and technical
>>> knowledge and description in this field that we could have drawn on."
>>> 
>>> "By using terms that rely on the legal language of trademark law, I
>>> believe we have created an implicit redundancy between recommendations
>> 2
>>> and 3. I.e., I believe both 2 and 3 can be used to protect trademarks
>>> and other intellectual property rights, and while 3 has specific
>>> limitations, 2 remains open to full and varied interpretation."
>>> 
>>> "As we begin to consider IDNs, I am concerned that the interpretations
>>> of confusingly similar may be used to eliminate many potential TLDs
>>> based on translation. That is, when a translation may have the same or
>>> similar meaning to an existing TLD, that the new name may be
>> eliminated
>>> because it is considered confusing to users who know both."
>>> 
>>> Now let me focus on the language in the final report.  Please see the
>>> Recommendation 2 Discussion in the report, the first item under the
>>> subtitle "TERM OF REFERENCE -- SELECTION CRITERIA".  I first call your
>>> attention to the first item: "i) This recommendation has support from
>>> all the GNSO Constituencies. Ms Doria accepted the recommendation with
>>> the concern expressed below[39]."  As you know, your concerns are the
>>> ones pasted above.
>>> 
>>> Item iii confirms that the issue discussion that ". . . the issues
>> found
>>> below have been discussed at length, both within the Committee and
>>> amongst the Implementation Team."  The discussion goes on in item iv
>> to
>>> say, "The Committee used a wide variety of existing law[42],
>>> international treaty agreements and covenants to arrive at a common
>>> understanding that strings should not be confusingly similar either to
>>> existing top-level domains like .com and .net or to existing
>>> trademarks[43]."  I won't quote all of them here because there are a
>> lot
>>> of them but let me quote a few that are particularly relevant to our
>>> discussion now.
>>> 
>>> Item vii says, ". . .  the 1883 Paris Convention on the Protection of
>>> Industrial Property[48]. It describes the notion of confusion and
>>> describes creating confusion as "to create confusion by any means
>>> whatever"".
>>> 
>>> Item x says, ". . . the European Union Trade Mark Office provides
>>> guidance on how to interpret confusion. "...confusion may be visual,
>>> phonetic or conceptual. A mere aural similarity may create a
>> likelihood
>>> of confusion."
>>> 
>>> Item xi says, ". . . Likelihood of association is not an alternative
>> to
>>> likelihood of confusion, "but serves to define its scope". Mere
>>> association, in the sense that the later mark brings the earlier mark
>> to
>>> mind is insufficient to find a likelihood of confusion, unless the
>>> average consumer, in bringing the earlier mark to mind, is led to
>> expect
>>> the goods or services of both marks to be under the control of one
>>> single trade source. "The risk that the public might believe that the
>>> goods/services in question come from the same undertaking or, as the
>>> case may be, from economically-linked undertakings, constitutes a
>>> likelihood of confusion...". (found at
>>> http://www.patent.gov.uk/tm/t-decisionmaking/t-law/t-law-manual.htm)"
>>> 
>>> There is of course much more in this discussion than I quoted above
>> but
>>> I don't there is anything that says that visual similarity is the only
>>> area of possible confusion.  If you can find anything in the report
>> that
>>> says that, please point it out.
>>> 
>>> As you know, the ICANN Staff implementation team attempted in their
>>> early steps to limit confusing similarity to visual similarity only
>> and
>>> I challenged them on that several times, pointing them to the
>> discussion
>>> section mentioned above. Consequently, in DAG3 we find the following:
>>> "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. (From DAG3 section 2.1.1.1)"  The standards for a string
>>> confusion dispute are found in DAG3 section 3.4.1: "A DRSP panel
>> hearing
>>> a string confusion objection will consider whether the applied-for
>> gTLD
>>> string is likely to result in string confusion. String confusion
>> exists
>>> where a string so nearly resembles another that it is likely to
>> deceive
>>> or cause confusion. For a likelihood of confusion to exist, it must be
>>> probable, not merely possible that confusion will arise in the mind of
>>> the average, reasonable Internet user. Mere association, in the sense
>>> that the string brings another string to mind, is insufficient to find
>> a
>>> likelihood of confusion."  Note there is no restriction to visual
>>> similarity only.
>> 
>> 
>> my weak response:
>> 
>> ---
>> 
>> It is late and I will write in detail with chapter verse and
>> interpretation later.  You will possibly be surprised that i use many of
>> the same lines you have quoted to make my point.
>> 
>> A few quick points now
>> 
>> - As i said the fact that i expressed a concern that something might
>> happen is not an acknowledgment  that this thing has been permitted.   I
>> was predicting the possibility of discussions such as we are having.
>> 
>> - Yes, we discussed many contributions to the point we reached. But none
>> of those discussions firmly established a single standard beyond visual.
>> The fact that the background material from the EU includes conceptual
>> does not mean that this was accepted as part of the standard by the
>> council.  Though of course it might be relevant in a court case, I don't
>> know.
>> 
>> - I do agree that the staff has fuzzed up the borders a wee bit on
>> confusing similarity and yes the DAGv3 does define it a way that allows
>> confusion and that if it stays this way it will eventually  be a court
>> that decides what it really means.  DAGv1 was much better in this
>> respect.
>> 
>> - you quoted
>> 
>> DAG3 section 3.4.1: "A DRSP panel hearing
>> a string confusion objection will consider whether the applied-for gTLD
>> string is likely to result in string confusion. String confusion exists
>> where a string so nearly resembles another that it is likely to deceive
>> or cause confusion. For a likelihood of confusion to exist, it must be
>> probable, not merely possible that confusion will arise in the mind of
>> the average, reasonable Internet user. Mere association, in the sense
>> that the string brings another string to mind, is insufficient to find a
>> likelihood of confusion."
>> 
>> This talks about 'resemblance' which is a term that specifically refers
>> to how things look.
>> 'Mere association' on the other hand is the best one ever get out of
>> translation.
>> 
>> What this has done, is made the issue of transliteration more difficult
>> to argue and this because establishing whether the average Internet user
>> is one who can look at hebrew letters and ascii letter and visually see
>> the same thing could be a little challenging.  One would also have to be
>> able to prove that there was an exception in the transliteration.
>> 
>> More later.
>> 
>> ----
> 

ATOM RSS1 RSS2