tables document, IANA instructions

Patrik Fältström patrik at frobbit.se
Tue Jul 15 07:06:35 CEST 2008


On 15 jul 2008, at 04.11, Kenneth Whistler wrote:

> I agree with Mark that the language
> there is still vague and should be spelled out more
> exactly as to what the content of the IANA list should
> be and exactly how it is updated for each new Unicode version,
> so people aren't unclear about the intent or the process.

I guess it is the end of the paragraph that is unclear, i.e. this part:

    If needed, IANA should
    (with the help of an appointed expert) suggest updates of this RFC
    where BackwardCompatible (Section 2.2.3) is updated, a set that is  
at
    release of this document is empty.

What this paragraph try to say is that when a new version of Unicode  
is released, and IANA do calculate the new derived property value, it  
might happen that IANA discover a change that is not backward  
compatible. And that in this case IANA must make this known so that  
the process can start that answer the question "what to do now". There  
are three things that can happen:

1. No changes, and the non-backward compatible change is accepted.
2. The codepoint(s) are added to the backward compatible list.
3. Other changes are made to the tables document that remove the  
incompatibility.

My guess is that the core questions hidden in here is what is needed  
for the actual change to the backward compatible list (or any other  
part of the tables document) to change. Experience from the IETF say  
that increasing the requirements is not possible, but relaxing is very  
easy. Because we do not know what the requirements should be for  
selection of 1, 2 or 3 above, I am personally strongly in favor of a  
requirement for IESG decision for a change. The reason for this is  
that that forces the IETF to issue a last call, so noone is surprised  
over the change.

When we have gone through at least one release of Unicode and tested  
this process, we can also talk about relaxing the requirements.

For more details on the differences, see RFC 5226, http://www.ietf.org/rfc/rfc5226.txt 
.

Now when this RFC is published, I should have as editor been more  
clear in the wording. My suggestion has been to choose this  
alternative for the CHANGES:

IETF Review - (Formerly called "IETF Consensus" in
       [IANA-CONSIDERATIONS]) New values are assigned only through
       RFCs that have been shepherded through the IESG as AD-
       Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
       intention is that the document and proposed assignment will
       be reviewed by the IESG and appropriate IETF WGs (or
       experts, if suitable working groups no longer exist) to
       ensure that the proposed assignment will not negatively
       impact interoperability or otherwise extend IETF protocols
       in an inappropriate or damaging manner.

       To ensure adequate community review, such documents are
       shepherded through the IESG as AD-sponsored (or WG)
       documents with an IETF Last Call.

       Examples: IPSECKEY Algorithm Types [RFC4025],
       Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
       Handshake Hello Extensions [RFC4366].


But for creation of the derived property list, (as many people will  
copy it, as Ken says), I propose the following:

Expert Review (or Designated Expert) - approval by a Designated
       Expert is required.  The required documentation and review
       criteria for use by the Designated Expert should be provided
       when defining the registry.  For example, see Sections 6 and
       7.2 in [RFC3748].

       Examples: EAP Method Types [RFC3748], HTTP Digest AKA
       algorithm versions [RFC4169], URI schemes [RFC4395], GEOPRIV
       Location Types [RFC4589].

I.e. someone should be appointed to actually create the derived  
property list, ensure there are no "problems", and double.check that  
it is actually correct (no bugs) according to the specification.

     Patrik



More information about the Idna-update mailing list