Stability of valid IDN labels

[Vint Cerf]

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
>