RE: [gnso-idn-wg] One comment on techno-policy details

["Olof Nordling" <olof.nordling@xxxxxxxxx>]

Dear Chun,

I think we?re in agreement, really: ?variant?, in the sense I have used it,
relates to a character/symbol/code point and its substitutable character(s)
(etc) WITHIN a particular language/script. Thus, a ?variant? would not be a
relevant notion across scripts.

Very best regards

Olof

 

 

  _____  

From: Chun Eung Hwi [mailto:ehchun@xxxxxxxxx] 
Sent: Wednesday, February 07, 2007 10:13 AM
To: Olof Nordling
Cc: Mawaki Chango; gnso-idn-wg@xxxxxxxxx
Subject: Re: [gnso-idn-wg] One comment on techno-policy details

 

Dear Olof Nordling and all,

2007/2/7, Olof Nordling olof.nordling@xxxxxxxxx:

-Given that a particular source script TLD string has been accepted for
insertion into the root, any subsequent application (typically at a 
following round) for a source script TLD string that is nearly identical,
just differing from the already accepted string by featuring a variant
character/symbol in some place, would be considered "confusingly similar" 
and hence not accepted.
Now, is this an approach that enjoys support/agreement?
(Maybe this could rather be described as "ex ante blocking" of variant
strings or something similar, but I sincerely think it needs spelling out in

some detail in the draft report.)

 

The problem is the question of what is "nearly identical" in cross-scripts
situation. 

As I reiterated in this thread debate, I think it should be limited in
"typographical similarity" cases. In fact, what constitutes "typographical
similarity" is neither an easy question. In that respect, what "variant"
means in cross-scripts situation should be more clarified before the term
such as "ex ante blocking" is to be used although in my feeling, it seems to
be inappropriate. 

 

 

regards,

 

Chun

 

Very best regards
Olof

PS. As to the comments in the mail thread regarding other aspects of
vocabulary for the various levels of strings/labels, there are now 
suggestions to consider in the Wiki.

-----Original Message-----
From: owner-gnso-idn-wg@xxxxxxxxx [mailto:owner-gnso-idn-wg@xxxxxxxxx ] On
Behalf Of Mawaki Chango
Sent: Wednesday, February 07, 2007 4:27 AM
To: gnso-idn-wg@xxxxxxxxx
Subject: RE: [gnso-idn-wg] One comment on techno-policy details

Hello Bruce, Tina, et al.

Thanks to Cary, I have understood that the "root" only speaks ascii,
and any "alien" script is in the root encoded in ascii (so I guess my
question about whether the confusion was at the DNS level was rather 
rethorical.) So  on the infrastructure side, there is no threat to
the security and the stability of the Net, so far, and that, I
beleive was the main idea behind the "confusingly similar" in the
first place. So what about the user experience, now that it is clair 
that's what we are talking about?

First of all, I don't see how we can expect to avoid confusion at one
level (domain names) by sticking to a confusing notion  (the language
of our policy discussion)? We had that debate about new gTLDs in, and 
after, Amsterdam, and I thought we made some progress. I remember
there was a discussion with, among others, Ross who suggested better
alternate language (I'll look up that email and forward it to your
information and consideration.) There seemed to be a consensus, if 
not on the language suggested by Ross, at least on the fact that
"confusingly similar" needed to be changed. Now I see that not only
we're back to it, we go even worse talking about "ex ante rights" -- 
not to be confused with IPRs [sic], so what "rights" are we talking
about??!?? What I've retained from "confusingly similar" is to ensure
a secure and stable functioning of the Net, not to get entangled in 
some entrenched "rights" derived from being an earlier player in the
market, via some opportunistic and fuzzy adventures in semantics! Is
there any reason why using here the expression "typographic 
similarity" or confusion, as suggested by Chun Eung Hwi, fails to
address this?

Regards,

Mawaki

P.S. By the way, I'm sorry to say the para. in question (below) is
convoluted, there is definitely a need to clarify this and call a 
spoon a spoon.

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.

--- Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx> wrote: 

>
> Hello Mawaki,
>
> It would be useful to give some practical examples here.  Ie
> strings that you would or would not consider confusingly similar
> across different scripts.
>
> Part of the issue here is that it depends to some degree on how the
> ASCII domain name string is displayed in an application.  At the
> DNS level it is all just ascii.
>
> For example is: 
>
>  xn--bruce.example confusingly similar to bruce.example
>
> At the raw ascii level I would probably say no - ie the "xn--"
> provides sufficient differentiation, others may say that they are 
> too similar.
>
> When you then render "xn--bruce" in an application you might get:
>
> 'a'`¾ñ.example which looks nothing like bruce.example
>
> Applications may or may not limit the set of scripts that can be 
> used.  So for example this email application I am using allows me
> to mix scripts.
>
> I think the assumption so far is that where two scripts that can
> appear together in the same application at the 1st level would look 
> the same then they could fall into the confusingly similar
> category.
>
> Regards,
> Bruce
>
>







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