ICANN ICANN Email List Archives

[gnso-idng]


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

RE: [gnso-idng] rethinking IDN gTLDs

  • To: <gnso-idng@xxxxxxxxx>
  • Subject: RE: [gnso-idng] rethinking IDN gTLDs
  • From: "Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx>
  • Date: Tue, 1 Dec 2009 09:51:13 -0800

Chuck,

How do you mean "the chances of user confusion are null"?

Thanks,
Mike

Mike Rodenbaugh
RODENBAUGH LAW
548 Market Street
San Francisco, CA  94104
(415) 738-8087
http://rodenbaugh.com



-----Original Message-----
From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf
Of Gomes, Chuck
Sent: Tuesday, December 01, 2009 6:59 AM
To: Avri Doria; gnso-idng@xxxxxxxxx
Subject: RE: [gnso-idng] rethinking IDN gTLDs


Avri,

One of the main purposes of the restriction on confusingly similar
strings was to avoid user confusion.  We talked about that a lot.  If
the chances of user confusion are null, why would the strings be a
concern?

Chuck 

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> Sent: Monday, November 30, 2009 9:37 PM
> To: gnso-idng@xxxxxxxxx
> Subject: Re: [gnso-idng] rethinking IDN gTLDs
> 
> 
> Hi,
> 
> I do not remember any GNSO policy conversation that covered 
> this point and always assumed that this would be the 
> mechanism for rectifying such coincidences.  
> 
> Are there any of the discussions in the policy 
> recommendations that give this impression?
> 
> a.
> 
> On 30 Nov 2009, at 19:04, Gomes, Chuck wrote:
> 
> > An extended evaluation shouldn't even be needed in cases 
> like this.  
> > It was never intended that the confusingly similar 
> restriction would 
> > be used for variations of the same name by the same operator.
> > 
> > Chuck
> > 
> >> -----Original Message-----
> >> From: owner-gnso-idng@xxxxxxxxx
> >> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> >> Sent: Monday, November 30, 2009 9:45 AM
> >> To: gnso-idng@xxxxxxxxx
> >> Subject: Re: [gnso-idng] rethinking IDN gTLDs
> >> 
> >> 
> >> hi,
> >> 
> >> Would/could  this not be dealt in the extended evaluation 
> stage where 
> >> one requests an extended review of the rejection on the basis of 
> >> Confusing Similarity because there is no risk of adverse effect?
> >> 
> >> Or do you think it should be a complicating factor in the initial 
> >> evaluation?  Do we need a stmt somewhere in the doc 
> allowing for this 
> >> possiblity?
> >> 
> >> Personally I think that using standard process for the 80% 
> case and 
> >> the extended review and other review/appeals processes for the 
> >> complicated questions (20%) is one of the more clever 
> things in the 
> >> GNSO recommendations that has been adequately, I think, translated 
> >> into the DAG.  I think one of the places where we run into 
> problems 
> >> is where people with the 20% concerns don't want to have 
> to resort to 
> >> the review processes, be it confusingly similar or geo names.
> >> 
> >> a.
> >> 
> >> On 30 Nov 2009, at 08:57, Eric Brunner-Williams wrote:
> >> 
> >>> Gomes, Chuck wrote:
> >>>> Here's what I think is a simpler way to make my point: If the 
> >>>> problems anticipated by offering confusingly similar strings are 
> >>>> avoided, then the restriction of offering the strings is
> >> unneccessary.
> >>> 
> >>> 
> >>> Agree.
> >>> 
> >>> We're not doing string comparison for the mathematical
> >> pleasure of describing the algebraic structure of semi-groups and 
> >> their generators, but because some non-algebraic property exists 
> >> outside of the universe of character repertoires and the strings 
> >> generated over them, some property with a lawyer attached.
> >>> 
> >>> More broadly, some, if not all of the IRT issues are dealt
> >> with if the application is not considered in an artificial vacuum. 
> >> There's not a lot more gained by lawyering in the abstract 
> than from 
> >> string manipulation in the abstract.
> >>> 
> >>> 
> >>> So, restrictions are context dependent, not absolute.
> >>> 
> >>> Eric
> >> 
> >> 
> >> 
> 
> 
> 





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

Privacy Policy | Terms of Service | Cookies Policy