Stability of valid IDN labels

Eric Brunner-Williams ebw at abenaki.wabanaki.net
Mon Apr 21 22:46:26 CEST 2008


Stephane,

I'm glad you have a better example than the one I used, and I realize 
now that I was only looking at the validation problem from the point of 
octet sequences being transformed by some production rule(s) and 
inserted into zone(s), not from the point of octet sequences being 
transformed (possibly by the same production rule(s)) and resolution 
attempted.

I also appreciate your view concerning ICANN, however, if the 
requirement for IDN, using some particular repertiore, in applications, 
arose in whole or in part from that institution, and the Klensin, 
Faltstrom, Karp memo (rfc4690) suggests that, as does the presence of 
several of the initial draft authors and the WG chair in ICANN meetings, 
myself included over the past several years, than something may be lost 
by indifference to its statement of requirements.

There is nothing preventing this WG from inventing requirements on its 
own, or acquiring them from some external source, however, the temporal 
properties that ICANN can contractually require from an implementor is 
necessarily limited by ICANN's ability to enter into contracts -- I am 
not a lawyer, usually abbreviated in US English as IANAL, but I'm 
certain that that ability is not unlimited, and that the history of 
ICANN's contracts with implementors, in particular, gTLD registry 
operators, are for fixed periods of time.

It may be awkward to express, but suppose some policy "A" from some 
instance of the ICANN Board of Directors contained the requirement that 
no subsequent instance of the ICANN Board of Directors could alter 
policy "A". Ever. Perhaps it is not any other institution's duty to take 
the view that policy "A" is not well-formed, but in the absence of such 
a policy "A" from ICANN, it is inconsistent to take ICANN as both the 
author of the general requirements, here for IDN by some means, and then 
to assert that policy "A" exists and is controlling.

I'm sorry that asking about the temporal properties, which I see as 
temporally scoped, even if the definition is presently undefined, that 
is, the period of time for which repeated actions yield the same result, 
aka "consistency" and not "stability", is tedious, but requirements come 
from somewhere, even the thin air, but their author and importance must 
be knowable, not assumed to be absolute (both in time and importance, or 
any other property).

I take it as a given that ICANN's understanding of any issue, technical 
or non-technical, is imperfect. I also take it as a given that ICANN, 
and any other namespace operator, access provider, system vendor, etc., 
is free to change policy, practice, and implementations without 
necessarily constraining such change to be consistent with prior policy, 
practice and implementations. ISC is announced BIND 8 to be End of Life 
as of 27 August 2007. The EoL for BIND 4 has come and gone too. These 
are just examples, but the state of resolvers today is of limited, not 
unlimited interest.

Eric

Stephane Bortzmeyer wrote:
> On Fri, Apr 18, 2008 at 02:34:02PM -0700,
>  Eric Brunner-Williams <ebw at abenaki.wabanaki.net> wrote 
>  a message of 41 lines which said:
>
>   
>> The requirements for labels arises somewhere, and I suspect that for
>> the IETF's IDN activities, past and present, the author of that
>> requirement is, at in part, ICANN, [...] If that is the origin of
>> the requirement for stability
>>     
>
> I do not care about what ICANN says or does not say but let me say
> that stability is important for a lot of people, whatever such or such
> organization may think.
>
>   
>> Please consider the 3166 code points
>>     
>
> There is a huge difference: to know if a two-letter TLD is currently
> valid or not, you perform a DNS lookup. If a new two-letter TLD is
> added or deleted, all the resolvers on earth will see the change
> immediately (minus DNS TTL and various delays in propagation). So,
> changing the status of two-letter TLD raise no technical issues. (As
> mentioned by John Klensin, some software use a hardwired list of TLD,
> but they are so broken that they are probably not worth mentioning.)
>
> In IDNAbis, no lookup is done for a poor character which has been
> classified as invalid. So, an invalid character will never be able to
> become valid (without changing all the resolvers in usage). That's why
> stability is a different issue than it has always been with DNS. (The
> example of the language tag registry, given by Mark Davis, is a better
> one, since language tags processors are not supposed to do online
> validation, so, for language tags, stability is necessary.)
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
>   



More information about the Idna-update mailing list