Tables: BackwardCompatible Maintanence

[Vint Cerf]

I hope this is a useful suggestion:

  the proposal to generate an automatic update to the "backward  
compatibility" rule (which might be vacuous initially) seems harmless  
on its face if indeed it preserves the then current behavior of the  
then current IDNA rules.

Let us suppose that this automatic generator produces what in effect  
is a recommendation to be acted upon by (IANA, IETF, other)?

Let us suppose that it does not automatically go into effect but is  
examined by IANA (in consultation with IETF?) for its preservation  
properties and it is verified that it preserves what is then current  
behavior.

Let us suppose that someone thinks that preservation of backward  
compatibility is, in this instance, not appropriate.

One could then posit that a WG is proposed, and the usual IETF  
actions ensue.

In the mean time, however, the preservation of then current behavior  
has a stabilizing effect.

Unless I have misunderstood something terribly badly, the proposal  
seems sensible on its face as a stabilizing mechanism that can be  
checked by IANA (with advice and counsel?) before instantiation.

Vint


Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Dec 12, 2008, at 3:38 AM, Martin Duerst wrote:

> At 20:09 08/12/10, Patrik F舁tstr� wrote:
>> On 10 dec 2008, at 08.15, Mark Davis wrote:
>>
>>> Scenario A. BackwardCompatible *is not* automatically generated by
>>> IANA.
>>
>> FWIW, I do not agree this is the order of events. If what is  
>> listed at
>> [6] is happening as late as [6], then we have a serious
>> miscommunication between IETF and Unicode Consortium.
>
> Well, yes, but the situation isn't much better if we change this
> slightly to assume that at [0], the IETF gets aware of a potential
> change by the Unicode Consortium, and tries to find somebody who
> might volunteer to write an RFC on a single obscure codepoint and
> run that through the IETF process. If that turns out to take time,
> what should the Unicode consortium do? Wait with releasing a new
> version until the IETF has finished a boring job that nobody is
> really interested in and that could have been avoided in the first
> place?
>
> Regards,    Martin.
>
>>    Patrik
>>
>>>   1. The updated implementations dutifully run the algorithm in
>>> Tables, and
>>>   now consider X to be DISALLOWED, and  Y to be PVALID.
>>>   2. The unupdated implementations still consider X to be PVALID and
>>> Y to
>>>   be DISALLOWED
>>>   3. So updated registries now disallow their registrations with X
>>>   (refunding people's money?), and allow registrations with Y. And
>>> updated
>>>   lookup clients will refuse to lookup X, and will lookup Y.
>>>   4. Unupdated registries still allow registrations with X, and
>>> disallow
>>>   registrations with Y. And unupdated lookup clients will allow
>>> lookups with
>>>   X, and will refuse to lookup Y.
>>>   5. There will be obvious conflicts among mismatched
>>> implementations and
>>>   registries; and these conflicts are not the result of new
>>> characters; they
>>>   are among characters that all of the implementations are meant to
>>> handle.
>>>   6. Then the IETF decides this is a bad situation, starts the whole
>>>   process of doing a new RFC. Some time later, this adds X and Y to
>>>   BackwardCompatible to restore the previous situation.
>>>   7. Some subset of the updated implemenations now pull in the new
>>>   BackwardCompatible list, and now they revert to the 5.1 behavior
>>> for these.
>>>   Others don't update to that table immediately, and still conflict
>>> with
>>>   unupdated implemenations until they are updated.
>>>   8. This is a bit of a mess, and an avoidable one.
>>
>
>
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp        
> mailto:duerst at it.aoyama.ac.jp
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081212/bba7d66d/attachment-0001.htm