RE: [gnso-idn-wg] One comment on techno-policy details
- To: gnso-idn-wg@xxxxxxxxx
- Subject: RE: [gnso-idn-wg] One comment on techno-policy details
- From: Mawaki Chango <ki_chango@xxxxxxxxx>
- Date: Tue, 6 Feb 2007 19:26:44 -0800 (PST)
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
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