Tables: BackwardCompatible Maintanence

[Martin Duerst]

At 20:09 08/12/10, Patrik F$BgM(Btstr$B‹N(B 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