Tables: BackwardCompatible Maintanence

[Patrik Fältström]

On 10 dec 2008, at 01.37, Kenneth Whistler wrote:

>> The problem for me is that I have problems saying exactly to IANA  
>> what
>> they should do.
>
> 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."

The list of codepoints (5.1) is non-normative. So we should not mix  
these two up.

Regarding the contextual rules, we could discuss that as well. What is  
needed to change / create new contextual rules?

If it is "IETF Action" (which I want -- at least for now), then IANA  
does not need to have the table as it is by definition part of the RFC  
that is the result of that action.

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

Correct.

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

Thanks.

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

Agreed.

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

Here comes my point:

If IANA is to update the list automatically, then that list will be  
updated first, when a change is made. From version A to version B of  
the list. Now, that change was such that IETF wanted to update the  
RFC, so that the change should not be backward compatible but instead  
that change in Unicode SHOULD be reflected in the IDNA standard. Then  
the RFC is updated, the codepoint is removed from Category G, and in  
reality we have version C.

Because of this, we have version A, B and C of the rules, instead of A  
and C (only). This because IANA did create version B.

BUT, I will read your text before I draw too many conclusions of YOUR  
proposal. This above is my reasoning.

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

Agree.

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

Possibly.

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

    Patrik