IANA actions and tables document

[Martin Duerst]

I have real difficulties to understand why what Ken has explained
in great detail continues to be ignored. More below.

At 23:19 08/12/11, John C Klensin wrote:
> >--On Thursday, 11 December, 2008 08:18 +0100 Patrik 
>F$B%F!"(Bltstr$B%F%+(Bm ><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.

This is weird. Do you in earnest propose that we create a registry
(backwards compatibility) for which we plan to change the procedures
on the first entry? If we think we don't need that registry, why don't
we just forget about it? If we ever need it, and we need to write
an RFC even just for a single codepoint, why not just describe that
registry, and what has to happen from thereon, in that RFC?

>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.

Fine in terms of length, but somebody has to write that RFC, and
somebody has to approve it, and then it has to be published, and
so on.

Please remember that one of the goals (in my view still the most
important goal) of the present revision is to get rid of the
tie between IDNA and Unicode Versions. Now let's immagine what
implementer A does when there is a change e.g. in the classification
of vertical tilde as described by Ken.

Implementer A wants to upgrade the implementation so that it also
works with the new Unicode version (say 6.2). If the codepoint is added
to the backwards compatibility list automatically by IANA,
implemeter A will go to IANA and check. If everything works
well, IANA has been informed by the Unicode consortium well in
advance, and on the day Unicode 6.2 is out, IANA publishes the
new (first) entry in the backwards compatibility registry.
Everything goes smoothly. Even thinking about the case that
IANA doesn't get informed, implementer A can deduce what the
registry should be based on the explicit instructions to IANA
in the IDNA 2008 RFC.

But this all changes if the update is not automatic and done
by IANA. If implementer A notices that there is a problem, he'll
try to figure out how many months it may take for the new RFC
(well, difficult to answer, RFC Editor speed varies,...).
In the meantime, implementer A will do other stuff, and
maybe forget about the upgrade, or complain about the IETF
or the Unicode consortium or both. Maybe implementer A might
even start to write the RFC. Or implemeter A might just
go ahead and implement the new version from Unicode based
on the changed properties, and the there will be incompatibilities
between versions.

All this only seems to cause additional delays, with absolutely
no benefit to anybody.

>IETF action >> implies the addition of the codepoint will be 
>flagged on for >> example the IETF Announce mailing list.

If we think this is necessary, it's very easy. Just instruct
IANA to send a message to the IETF Announce mailing list
whenever that happens. (in my view, the specific cases where
this potentially will happen will be of interest to just
about 0.1% or so of the people on that list,...)


> >This seems right 
>to me, both because moving things around (from >one list to another) is a 
>bad idea

What backwards compatibility does is to keep things in the same list
(PVALID), not to move them around.

>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.

As far as I understand, there is already an official liaeson between
the Unicode Consortium and the IETF. If that's not working, then
please fix it. It's perfectly fine for the IETF to review new and
upcomming versions of Unicode, and similar to any other standards
body, the Unicode Consortium appreciates any reviews they can get.
But depending on occasional and probably rare property changes
to trigger IETF review of new Unicode versions is really backwards.

> >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. > >     

As said already above, if we think such changes (almost) never
appear, then the way the IETF would really do things is to just not
talk about that case.

Regards,    Martin.



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