Subbiah,
I understand your statement (and as a native Tamil speaker, was rolling on
the floor laughing at your example ;)
I have no issues with the points you bring up regarding "sounding
similar",
and in fact vehemently agree.
To clarify what I meant in my statement - I understood Charles to say that
there is precedent in trademark law regarding confusing similarity using
phonemes. Insofar as there is legal precedent and case law, then we
should
allow the law to run its course.
-Ram
-----Original Message-----
From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx] On
Behalf Of subbiah
Sent: Monday, March 19, 2007 5:47 PM
To: rmohan@xxxxxxxxxxxx
Cc: 'Olof Nordling'; gnso-idn-wg@xxxxxxxxx
Subject: [gnso-idn-wg] Item 4.5.4
>
>
>- Item 4.5.4: I support the alternative view that phonetic confusing
>
>
Ram,
you asked this question below regarding 4.5.4.
Ram: I am in general support of this also. Are there dissenting views in
our
WG?
My response:
I must say that I am strongly against this. If we start straying too far
from the limited cases of visually confusing spoofing to blocking
"phonetically confusing" (i.e. sounding the same) we are going into run
into
a lot of problems. The next thing, after sound we will be blocking is any
gTLDs that smells the same, or elicit the same emotional response from
humans (like anger or laughter).
The sounds of one language are not owned by another. Moreover when a
person
sees another language and converses in that the speaker contextually
understands what is being said in that language - phonemes are processed
in
the context of the language being used. If that were not the case the
following situation would have merit.
First, the voice-box of a human is limited to only a small and finite set
of
phonetic sounds exist across all languages. Second, I also understand that
we wish to keep the number of syllables in a gTLD label short (typically
one
or two syllables - phonemes) - otherwise we could all be typing xn--abcgtf
for the gtld instead. Taking the two together will leave us with a small
set
of acceptable phoneme combinations for IDN gTLDs across all Unicode
langauges - probably around a 1000 or so. Now I can absolutely assure you
that most langauges have several short (for presumably efficency of use in
anger, usually one or two syllables) perjorative terms/sounds.
Thus its extremely likley that many reasonable candidates for a gTLD in
one
langauge will end up being completely unacceptable phonetically in another
langauge. To illustrate we can use Tamil and English with real life
examples
that are only mildly objectionable.
The Tamil word for flower (a 1 character word in Tamil) sounds like "poo"
(3
characters in English) while in English its baby-talk for "sh.t". Of
course
helpfully its English baby-talk 3-character cousin "pee" is, if not in
detail meaning the same, is at least categorically correct in Tamil as it
means "sh.t" (again single character in Tamil). As a native speaker of
both,
if for one moment I were to keep the concepts/phonemes of the first
langauge
in my head while i speak the second, I will start talking nonsense and end
up embarrasing myself, figuratively, not literally :-)
So the language context takes precedence over phoneme usage itself...
Thus if we place limits based on phonetic similarity we will find many
many
things to be disallowed and I am certain almost any one or two-syllable
string will be objectionable in at least one other langauge.
Therefore on the grounds of both logic and simplicity I strongly disagree
that the notion of "phonetically confusing" should be entertained as basis
of any IDN gTLD selection limiting criteria.
Subbiah
Ram Mohan wrote:
>Dear Charles and WG members,
>Please find below my responses to your proposals made yesterday to the WG
>list.
>
>
>
>>- Item 4.1.1: I support the "alternative view" that we should resolve
>>IDN policy issues before launch of application round.
>>
>>
>
>+ What is the WG view on this suggestion? So far, we have said that we
want
>to avoid "hostage situations" but we've also said that IDN issues need to
>stay a high priority.
>+ My personal view is that IDN policy issues should continue to get
strong
>attention from the GNSO Council.
>
>
>
>>- Item 4.1.5: I support the alternative to resolve policy before
>>developing priority criteria. I would be very cautious about "lower
>>entry barriers" as a way to address this problem, which barriers
>>would be lowered? those involving technical issues? security and
>>stability? More clarification to the lower entry barriers is needed.
>>
>>
>
>+ I agree that lowering entry barriers needs far more careful study than
has
>been done so far.
>
>
>
>>- Item 4.2.2: I agree that a country should be able to reserve IDN
>>
>>
>strings for the country name. Beyond that, I support the alternative
>that countries' rights are limited to their respective jurisdictions.
>I strongly agree, however, that the opposition of the established
>institutions of a particular language group to a proposed TLD
>(whether ASCII or IDN) targeted to that language group should provide
>a basis for ICANN to defer or deny the application (I understood that
>a similar rule is under study in the new TLDs committee to apply to
>economic or cultural sectors, e.g., .bank or .library).
>
>+ I agree regarding country name reservations. I advocate caution
towards
>making any statements regarding jurisdiction.
>+ I agree regarding ICANN using input from language institutions in its
>evaluation process.
>
>
>
>>- Item 4.5.4: I support the alternative view that phonetic confusing
>>
>>
>similarity should be a basis for refusing an application. There is
>plenty of experience under trademark law in resolving conflicts
>between words in different languages that sound similar.
>
>+ I am in general support of this also. Are there dissenting views in
our
>WG?
>
>--------------------------------------------------------------------------
>Ram Mohan
>e: rmohan@xxxxxxxxxxxx | m: +1.215.431.0958
>--------------------------------------------------------------------------
>
>
>
>
>
>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.413 / Virus Database: 268.18.13/726 - Release Date: 3/18/2007