Tables: BackwardCompatible Maintanence

[Kenneth Whistler]

Patrik continued on this thread:

> I am still missing input from wg participants on this very large change.

I will separately post a note detailing exactly what I think
the appropriate text change would be for this, which I hope
can satisfy the concerns of all on this topic. By the way,
as for Mark, I don't think what is needed here is a "very large
change", either in the text itself or the intent.

But first, to respond specifically to your concerns addressed
in this note.


> The problem for me is that I have problems saying exactly to IANA what  
> they should do.

The issue here isn't a matter of dictating to someone, requiring
them that they do something they don't *want* to do. But rather
making sure that the specification in question is precise
about what IANA should be listing in its tables for the IDNA
registry, for each version of Unicode. It is in everyone's interest,
I think, including whoever at IANA draws the short straw for
deriving the IDNA table for Unicode 5.2, Unicode 6.0, ...,
that the specification be clear as to *exactly* what should
be in that derivation, so that everyone who needs to refer to
it gets good data, and people implementing the protocol end
up with the expected behavior (including, of course, backward
compatibility between versions).

Also note that idnabis-tables-04.txt currently *does* tell
IANA what they should do:

5.1: "IANA is to keep a list of the derived property for the
      versions of Unicode..."
      
5.2: "IANA will create and maintain a list of approved
      contextual rules."
      
Specifying in this document that IANA keeps a list of
the BackwardsCompatible characters per version of Unicode
along with the derived property is *not* a requirement that
differs in kind from those two, already specified.

> I do, as I said last time in Minneapolis, that I am  
> extremely nervous over changes like these. When is IANA to add things,  
> and how? 

See my proposed text in the next note. This is actually quite
easy and exact to specify.

> Do we really know IANA should add every difference to the  
> backward compatibility list?

Every change which results in a backwards *in*compatibility
should be added to the BackwardsCompatible list, as a matter
of course. That is simply good design.

Now we all hope that that list, which starts as a null list,
*stays* a null list forever. But the whole point of having
Category G in the document at all is that *if* it is needed,
it would be used. Otherwise, we might as well just yank it
out of idnabis-tables-04.txt right now.

> I have seen enough discussions that say  
> "some changes should be possible to make".

If there is a matter of argument and decision to make, then *that*
would be the time to update the RFC itself, under IETF review,
to reexamine the explicit exceptions list.

Failing that, what IANA should have is very simple, clear, and
concise instructions that allow the reproducible and clear
derivation of the property, given a set of property data files
for a new version of Unicode.

> 
> Overall, there is a reason Unicode Consortium is making a very very  
> rare change that create a non-backward compatible change for IDNA.

Of course, *if* such an identifier-related change in properties
occurred, there would likely be a good reason for it. After all,
it would also impact the need for the Unicode Consortium to
engage backwards-compatible mechanisms for *other* types of
identifiers, and not merely IDN's.

> I am personally very nervous telling IANA that the backward compatible  
> list is absolute.

It isn't "absolute" -- it is simply a part of the automatic
derivation, to preserve backwards compatibility between versions
of Unicode, so people can rely on IDNA moving forward.

> I really want IETF process to have a look at that  
> very rare change and decide what should be done. Either add to  
> backward compatibility list, or do something else. Maybe change from  
> PVALID to CONTEXT.

Which is fine. If somebody thinks a problem in a property change
is serious enough that it warrants opening up the IETF review
process to reconsider the exceptions list, then that option
is always open to the IETF. But that is materially different
from the way the specification should mandate the simple
derivation, from version to version, to maintain compatibility
between versions.

> 
> But, as editor, the problem I have is that I see Mark's suggestion,  
> and I hear my own personal argument against Marks suggestion. Then  
> support from Ken saying he does not see any problem with Mark's  
> suggestion.
> 
> As Editor, I would like to get more input.

O.k. That is coming next.

> And as individual, I once again say that the rules are very easy to  
> relax later on, but not the other way around.

This is not a matter of either relaxing rules or making them
more strict, but in doing the bookkeeping to keep a derived
list stable from version to version.

--Ken