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