Tables: BackwardCompatible Maintanence

[Erik van der Poel]

Martin and Ken,

I believe the point is that *if* a relevant Unicode property changes,
no matter how unlikely, then the IETF and other DNS stakeholders ought
to get a chance to consider whether or not to make the consequent
incompatible change to IDNA. After all, if the Unicode community
decided that the change was important enough to make, then the DNS
community may also decide that it is important enough to change on the
IDNA side.

So, we do not want automatic incorporation of changes initiated by the
Unicode community. Instead, we want the DNS community to make the
right decision for DNS, which is something the Unicode community is
not qualified to do.

Just look at what happens when IDNA blindly adopts Unicode specs: The
eszett/ss debacle. Now we have to make a painful change for that,
because the German registry insists that eszett be included. Of
course, the German registry should have voiced their opinion when
IDNA2003 was being drafted, but...

So, we need a group of experts to first try the automatic derivation,
and then see whether there are any PVALID->DISALLOWED or
DISALLOWED->PVALID changes. If there are, then the issue must be
discussed, probably via Internet Drafts, possibly without restarting
the WG. Then each character must be put into BackwardCompatible or
Exceptions, depending on the decision. (Or it might be simpler to
always put such characters into Exceptions, and just not have a
BackwardCompatible category.)

Erik

On Tue, Dec 9, 2008 at 5:52 PM, Martin Duerst <duerst at it.aoyama.ac.jp> wrote:
> But isn't this exactly what we do NOT want? If I understand
> correctly, BackwardCompatible is a purely administrative thing,
> ideally we give IANA an algorithm, and they execute it and
> put the result into the registry when there is an update
> to Unicode properties that requires a balancing entry in
> BackwardsCompatibile. Bothering the IETF at large with this
> is pretty useless; having an expert reviewer as a "goto guy"
> for IANA will probably help.
>
> On the other hand, for Context, changes are usuall something
> new and unexpected, and potentially even political. A somewhat
> more serious/heavy process seems appropriate.