Tables: BackwardCompatible Maintanence
Patrik Fältström
patrik at frobbit.se
Wed Dec 10 12:09:55 CET 2008
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.
More information about the Idna-update
mailing list