Stability of valid IDN labels

JFC Morfin jefsey at jefsey.com
Sun Apr 20 02:18:05 CEST 2008


At 01:17 20/04/2008, LB wrote:
>Dear Vint,
>As co-owners of the Multilingual Internet (that is the French
>translation for "at large"), our position is that we do not want to
>depend on the constraints, because it is not known if it will be
>accepted and how far they will go.
>
>For example, Harald "constrained" me not to be able to speak on his
>list. Russ told Jefsey that the list would follow the rules of the
>IETF WG. But it does not. "for the moment" is a bad thing in a
>network. Says who the moment is finished.
>
>John Klensin began studying why we could not do otherwise than IDNA.
>This is the first thing to do.

Louis,
Eric refers to a misuse of ISO 3166 by ICANN which lead to a deal. 
They have kept ".su" supposedly to support USSR Internet archives, 
instead of respecting ISO 3166-3 (historic names) and supporting it 
as a DNAME for its 4 letters historic code. This means that what Vint 
sees being used for the past (temporary place), Eric shows it can be 
for future eternity, as a "may also be". This relate to what you say. 
Users cannot accept that possible change due to external constraints. 
But what about internal constraints?

Let assume that Unicode has for a mandatory reasons to accept "@" as 
an alternative to "a". Making possible a conflict between "coca-cola" 
and "coc at -col@" in a domain name.

The solution found with ISO 3166/MA has been a 50 year delay. But 
what if all the US and Chinese States get one vote in UN to protect 
the world stability. We will need to recover "SU". Also, is the 
internet addressing to last less than 50 years?

IMHO ICANN had a very good position when UK and ccNSO wanted ISO 3166 
to be managed by Debbie Garside. They said "we will do what people 
do". In keeping in tune with people, they will they not keep 
permanently in time?
jfc

>2008/4/19, Vint Cerf <vint at google.com>:
> > Earlier versions of the draft documents had a "maybe" concept but during
> > detailed discussions it was not clear to me, at least, that there 
> was a very
> > operational way to treat anything in the "maybe" category other than to
> > reject its use until such time as it became valid or invalid. If you were
> > not supposed to register anything in Maybe but you could perhaps 
> allow it to
> > be looked up (ie used in a query) then in practical terms, Maybe behaves
> > like "invalid for the moment."
> >  On the other hand, once a character is valid, it would not be a good thing
> > to allow it to become invalid because some previous registrations 
> would then
> > no longer work. We may be faced with a one-time version of that problem
> > anyway, however, as we try to accommodate the need to make registration
> > rules more restrictive than those developed in the 2003 version of IDNA.
> >
> >  vint
> >
> >
> >  On Apr 18, 2008, at 8:03 PM, JFC Morfin wrote:
> >
> >
> > > At 21:55 18/04/2008, Mark Davis wrote:
> > >
> > > > One thing that I think has people a bit tied up in knots is 
> the way that
> > stability is being handled in the current drafts. In the drafts, 
> labels with
> > assigned characters will be either valid forever, invalid forever, or in
> > limbo (eg valid now but could change to invalid later). The limbo situation
> > arises when there is a CONTEXT character, because the rules could be
> > tightened in the future. Labels with UNASSIGNED characters can 
> move into one
> > of these three classes.
> > > >
> > >
> > > Dear Chair,
> > > There is a problem with limbo and invalid for ever. The current DNS works
> > well because there is no limbo. It can be extended with Unicode because
> > non-ASCII were not invalid forever. Before we discuss limbo/invalid for
> > ever, should we not review the mechanism in order to make the IDNA process
> > independent and permit further extensions and not blocking the 
> DNS for ever.
> > >
> > > I understood that the first task of the WG was to discuss if IDNA was
> > appropriate as a solution. This has two main point of interest :
> > >
> > > 1. to know if there is an IETF acceptable alternative or not. This is
> > important to us in order to know if we are free to investigate along other
> > lines.
> > > 2. to demonstrate there was no alternative as John Klensin started
> > documenting it.
> > > jfc
> > >
> > > >>> idn at mail.mltf.org
> > >
> > > Chers amis,
> > > Pour bien comprendre, le problème avant de commencer la discussion, et
> > donc pour nous de documenter les besoins du français et des langues de
> > France est de savoir si l'IETF veut rester sur la ligne actuelle de l'IDNA
> > que soutient a priori l'AFNIC ou si elle veut d'abord confirmer la validité
> > de ce choix. Ceci est conforme au Charter. Dans le cas où ils identifient
> > que l'IDNA est définitivement confirmé pour l'IETF, nous pouvons avancer
> > indépendament sans risque de confusion. Dans le cas où ils 
> identifient qu'il
> > faut revoir l'approche architecturale, il nous appartient de 
> participer à la
> > révision du Charter qui aura alors lieu.
> > >
> > > Voulant leur donner le plus de chances possible de réussir un IDNA qui
> > nous satisfasse, mais n'ayant pas de solution à ce problème, tout ce que
> > nous pouvons faire pour les aider à ce stade est de leur bien faire suivre
> > leur propre feuille de route.
> > > jfc
> > >
> > >
> >
> >  _______________________________________________
> >
> >  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