Changing the values of domain names and the need for mapping

[Eric Brunner-Williams]

As I read this, Paul has made an assertion about the "real effects" of 
the set of domain names which contain Esszett and the COM/NET/ORG 
registries. I'm not going to bother greping the zonefiles for the data, 
but anyone who wants it can. Cary has pointed out that in our community 
(gTLD registries) the subject is well-known and the costing not 
sufficient to raise a policy concern by any current gTLD registry 
operator. Paul responds that "this group" has a "main concern" in 
knowing what "those actions are". This is an error. The ICANN GNSO 
Consensus Policy framework is something to which our community (gTLD 
registries) have agreed to be bound by (as a matter of contract), and 
ICANN entrusted the IDN problem to the IETF, to the antecedent of this 
working group, hence this working group. Subordinating this working 
group's policy and mechanism choices to the C/N/O operators is fine, but 
it means that the ball has been handed back to the C/N/O operators, and 
assuming contracts are what they appear to be, back to ICANN.

Now I can think of reasons to revisit, revise, even rescind the circa 
2002 decision by the then ICANN Board to place the locus for extending 
the text label character repertoire from LDH to one or more additional 
characters with the IETF, but for reasons larger in scope than a single 
character in a particular repertoire.

I disagree with Paul's assessment, first, for its lack of material 
specificity (the zonefiles _are_ out there), and second, for its 
implicit rejection of the role and responsibility of this working group, 
for the particular rational he advances, the esszett character.

Eric

Paul Hoffman wrote:
> At 8:02 AM +0100 2/20/09, Cary Karp wrote:
>   
>>> VeriSign has many domain names registered in .com that are encodings
>>> of strings that use Esszet. To the best of my knowledge, no one from
>>> VeriSign has said on this list or in any other forum that VeriSign is
>>> prepared to deal with the very real effects (not "side-effects") of
>>> current registrations under the IDNA2003 protocol (not "guidelines").
>>> The same is true for PIR and .org. Further, the one registry that has
>>> said it can deal with the effects of the Esszet change has not
>>> definitively said how they will do so.
>>>       
>> This topic has been discussed at length by the gTLD registries in
>> several forums. I partcipate in many of those discussions, as well as in
>> the present one. Although I am not prepared to make any assertions on
>> behalf of the gTLDs that you name, my sense is quite clearly that they
>> all understand the consequences of the action we are proposing, and are
>> prepared to undertake the resultant effort.
>>     
>
> That's good to hear. The main question for this group is what those actions are. Some actions would cause lack of interoperability with current names, others would cause new requirements on current domain name owners, and others would be just fine. Without knowing what these registries plan, this WG cannot decide the stability effects of our decisions here.
>
>   
>> Devising specific
>> implementation plans is a proprietary concern, and you cannot reasonably
>> expect details to appear on this list.
>>     
>
> Well, we can take this discussion to the DNSOP WG, but I think this list is certainly more appropriate. The operational affects of our decisions is indeed something we need to consider, so it is reasonable to expect details of operational plans to appear here.
>
>   
>> I agree that it would be useful for the gTLDs to chime into the
>> discussion here, directly, but the fact that they have not done so
>> hardly supports the assertion that they are opposed to a protocol
>> change that will ultimately increase the base of useful (and therefore
>> commercially interesting) domain names.
>>     
>
> Fully agree; we simply don't know.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
>