ICANN ICANN Email List Archives

[gnso-idn-wg]


<<< Chronological Index >>>    <<< Thread Index >>>

Homograph and terminology in generel --- was: [gnso-idn-wg] One comment on techno-policy details

  • To: <gnso-idn-wg@xxxxxxxxx>
  • Subject: Homograph and terminology in generel --- was: [gnso-idn-wg] One comment on techno-policy details
  • From: "Tina Dam" <tina.dam@xxxxxxxxx>
  • Date: Wed, 7 Feb 2007 12:45:49 +0100

Just a reminder to everyone. We need to be careful about use and choice of
terminology.
 
For example, homograph is defined as 

"A word with the same spelling as another or others, but with a different
meaning and origin and sometimes a different pronunciation." 

A quick Google search gives the following examples: 

1) the noun conduct and the verb conduct are homographs

2) Many people have difficulty when trying to parallel park. It was a
beautiful day for a walk in the park. "park" being homographs.


Note, this is not the same as typographic similarities.
 
Lets make sure we use the wiki so that we are all on the same page and know
what we talk about.


Tina





________________________________

        From: Chun Eung Hwi [mailto:ehchun@xxxxxxxxx] 
        Sent: Tuesday, February 06, 2007 11:46 PM
        To: Tina Dam
        Subject: Re: [gnso-idn-wg] One comment on techno-policy details
        
        
        Dear Tina Dam,
         
        You are right in some senses.
        As my own argument that in the same language family, there could be
many confusingly similar variants, and this should be carefully avoided. I
agree.
        But as you talk about Unicode scripts, I admit only one pattern of
problem - typographic similarity - in fact, this is what we call homographic
problem. Definitely, this typographic similarity should be also avoided. 
         
        However, if we use the term of variant - it is very comprehensive
and truly make serious confusion in cross-scripts situation. So, I suggest,
typographic similarity should be carefully avoided because of possible
confusion and collision, but semantical or phonetical similarity among
different script labels does not make any problem of "confusingly similar"
because different script labels itself ensure their distinctiveness. 
         
         
        regards,
         
        Chun
        
         
        2007/2/7, Tina Dam <tina.dam@xxxxxxxxx>: 

                Maybe this helps:
                
                .com in Latin looks awfully like .com (with Greek o) and
there are tons of
                examples like that. Take a look in Unicode. 
                
                The root server will see the difference because the punycode
version is
                different because the Latin o and Greek o has different code
points. For the
                user though it looks similar.
                
                > -----Original Message----- 
                > From: owner-gnso-idn-wg@xxxxxxxxx
                > [mailto:owner-gnso-idn-wg@xxxxxxxxx] On Behalf Of Mawaki
Chango
                > Sent: Tuesday, February 06, 2007 10:59 PM 
                > To: olof nordling; chun@xxxxxxxxxxxxxx;
gnso-idn-wg@xxxxxxxxx
                > Subject: RE: [gnso-idn-wg] One comment on techno-policy
details 
                >
                > Hi Olof,
                >
                > Basically, it looks to me as either you are in violent
                > agreement with Chun (then there might be some changes to
the
                > para./statement he's referring to,) or you're missing the 
                > point, (or again, I'm lost.) Your example refers to the
"same
                > script" (wether it's ASCII based or
                > else) whereby "confusingly similar" makes some sense. The
                > point Chun was making, as I've understood it, was that
there 
                > is a problem applying the notion "confusingly similar" in
                > cross-script situation ("different languages", "different
                > language script labels," etc.)
                >
                > In other words, does it make any sense to assume that a
new 
                > non-ASCII, IDN gTLD might be "confusingly similar" to an
                > existing ASCII gTLD. If you (anyone) think so, then how
and
                > to whom? To the DNS server? to some users? If not, then
are
                > we talking about an IDN gTLD (string) in one script being 
                > possibly "confusingly similar" to another IDN gTLD
(string)
                > in another script? And then again, at what
                > level: root server? user visual experience? and in the
                > latter, to what extent do we expect the users of different

                > languages and scripts to be the same, etc.? Ultimately,
the
                > rationale and relevance of this notion may need to be
                > reconsidered and clarified in the IDN context, and if
                > relevant, grounded in the IDN space as well as it may be
the 
                > case in the traditional TLD space.
                >
                > Or have I wholly missed the point?
                >
                > Thanks,
                >
                > Mawaki
                >
                > --- olof nordling < olof.nordling@xxxxxxxxx
<mailto:olof.nordling@xxxxxxxxx> > wrote:
                >
                > > Dear Chun,
                > >
                > > Thanks for your comments! One clarifying point,
hopefully, would be
                > > that the "confusingly similar" test (as conceived in the
new gTLD 
                > > recommendations)
                > > would be applicable to concurrent applications for gTLD
strings.
                > > Accordingly
                > > (by way of example in ASCII), if an application for a
                > string ".tuvw" 
                > > is received and another application (in the same script)
is
                > received
                > > for ".tuVw", where v and V symbolize variants (again for
                > the sake of
                > > example only), they would be considered "confusingly 
                > similar" in the
                > > string tests and be handled in accordance with a
specific procedure
                > > foreseen.
                > > Hence the
                > > statement you refer to.
                > >
                > > Very best regards 
                > >
                > > Olof
                > >
                > >
                > >
                > >   _____
                > >
                > > From: owner-gnso-idn-wg@xxxxxxxxx
                > > [mailto: owner-gnso-idn-wg@xxxxxxxxx] On Behalf Of Chun
Eung Hwi
                > > Sent: den 6 februari 2007 19:59
                > > To: gnso-idn-wg@xxxxxxxxx <mailto:gnso-idn-wg@xxxxxxxxx>

                > > Subject: [gnso-idn-wg] One comment on techno-policy
details
                > >
                > >
                > >
                > > Dear all,
                > >
                > >
                > >
                > > I couldn't catch up the recent debates, but I want to
make quick 
                > > comment on one issue of "limit confusion caused by
                > variants", which I
                > > could read from conference call 23 January overview -
2.2
                > as follows;
                > >
                > >
                > >
                > > 2.2 Agreement to limit confusion and collisions due to
variants.
                > > Agreement
                > > that this may be a stability and security issue and part
of the
                > > reserved name process. Agreement that variants of an IDN

                > gTLD string
                > > be treated in analogy with current practice for IDN SLD
                > labels, i.e.
                > > variants are not available for registration by others.
                > Agreement that
                > > this approach implies certain "ex ante rights" with
similarities to 
                > > the "confusingly similar" test foreseen in the New gTLD
                > > recommendations. Agreement that such "rights" must not
be
                > confounded
                > > with IPR rights as such. Some support for enabling a
choice 
                > for an IDN
                > > gTLD strings with variants to only block variants or to
use
                > variants
                > > as aliasing.
                > >
                > >
                > >
                > > What I want to clarify here is the fact that variants
come from the 
                > > same language or the same language family. Therefore,
the
                > confusion or
                > > collision happen in the same language or within the same
language
                > > family as well. We cannot use the term of variant in
case when some 
                > > translated or transliterated or phonetically same or
similar words
                > > (language script
                > > labels) are to be taken into account. And obviously, in
different
                > > languages or in different language families, there is no
longer 
                > > confusion or collision even when those  in respective
language are
                > > similar or the same in graphics, semantics and sound
                > because different
                > > language scripts must be distinctive itself. So, in this
case, 
                > > "confusingly similar" test cannot be applied.
                > > Accordingly, across different language script labels,
there
                > should not
                > > be any "ex ante rights" of the existing TLD label, and
so 
                > any reserved
                > > name policy would not necessarily be designed.
                > >
                > >
                > >
                > >
                > >
                > > regards,
                > >
                > >
                > >
                > > Chun 
                > >
                > > --
                > > ---------------------
                > > Chun Eung Hwi
                > > General Secretary, PeaceNet Korea
                > > chun@xxxxxxxxxxxxxx
                > > pcs (+82) 19-259-2667 
                > > fax (+82)  2-2649-2624
                > >
                > >
                >
                
                




        -- 
        ---------------------
        Chun Eung Hwi
        General Secretary, PeaceNet Korea
        chun@xxxxxxxxxxxxxx
        pcs (+82) 19-259-2667
        fax (+82)  2-2649-2624 





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy