IANA actions and tables document

[John C Klensin]

--On Thursday, 11 December, 2008 08:18 +0100 Patrik Fältström
<patrik at frobbit.se> 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.
> 
> My proposal is still to require IETF action to changes to the
> BackwardCompatibility list UNTIL we have added the first
> codepoint to that list. 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.

This seems right to me, both because moving things around (from
one list to another) is a bad idea if only because it might
leave windows and because forcing an explicit review of new
Unicode versions within the IETF seems like a good idea.  

Of course, if such code point derivation issues never occur,
then this situation will never arise and there is no practical
difference between the two procedural models.  I believe we have
fairly consistently taken the position that things that are so
unlikely that reasonable people believe they will never arise
should require IETF action until (and unless) actual experience
is accumulated with them.  The approach Tables now includes is
also consistent with that principle.

     john