Tables: BackwardCompatible Maintanence

[Patrik Fältström]

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.

    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.