IANA actions and tables document

[Martin Duerst]

At 16:18 08/12/11, Patrik F$BgM(Btstr$B‹N(B wrote:
>On 11 dec 2008, at 02.52, Kenneth Whistler wrote:
>
>> Adding something to the BackwardCompatibility list is *not*
>> something that needs explicit debate and review. In order
>> to preserve stability for IDNs, *if* it ever happens
>> (and we do hope it is an extremely rare case) that for a
>> new version of Unicode, the derivation in Section 3 ends
>> up turning a formerly PVALID character to DISALLOWED, then
>> you just automatically add it to the BackwardCompatibility
>> list to *force* it to stay PVALID, thereby keeping all your
>> implementations backward compatible, even during any
>> transition period when some might be upgrading and others not.
>
>Now I am more confused.
>
>This would imply that IFF Unicode include a from IDNA perspective  
>incompatible change, then we first get an automatic addition to  
>BackwardCompatibility, and then if IETF want to override this and  
>follow UTC, then IETF add the codepoint to Exceptions.

Yes. The chances that there will be an incompatible change
are slim, but the chances that the IETF will want to override
and follow the UTC are way, way slimmer. There are at least two
reasons for this: (1) backwards compatibilit (we don't suddenly
want to make illegal potentially existing domain names) and
(2) nobody cares, because the change made by the UTC was made
for reasons that don't affect the DNS (e.g. related to word
breaking or whatever else).

>My proposal is still to require IETF action to changes to the  
>BackwardCompatibility list UNTIL we have added the first codepoint to  
>that list.

With "UNTIL we have added the first codepoint to that list", do you
mean that that RFC would not only instruct IANA to add that codepoint,
but also contain the instruction for automatic updating in the future?
Why would we have to wait for the first actual case to do that?
(note that there are other IANA registries that are empty, e.g.
http://www.iana.org/assignments/language-tag-extensions-registry)

Regards,    Martin.

>The RFC that do that addition could be very very short, and  
>just update that entry. It is not a new version of the tables document  
>that is needed. IETF action implies the addition of the codepoint will  
>be flagged on for example the IETF Announce mailing list.
>
>    Patrik
>
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp