[apps-discuss] Status of 5892bis and IANA (was: Re: BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF)

[John C Klensin <[e-mail]>]

--On Thursday, September 08, 2011 08:52 +0200 Frank Ellermann
<[e-mail]> wrote:

> On 8 September 2011 03:24, Barry Leiba wrote:
> 
>>> 5892bis has been stuck in IANA hold (i.e., not either the
>>> WG's or the RFC Editor's fault)... I believe there has been
>>> another, independent, effort lately to un-stick it, but that
>>> may deserve a nudge from the IETF side too.
> 
>> Thanks for pointing that out to me; I'll check with Michelle.
> 
> Hi, I tried to figure out what that is about.  Apparently
> 5892bis fixes three Unicode points in TUS 6.0 for the purposes
> of IDNA2008.
> 
> The datatracker notes that "IANA will, in collaboration with
> its internal IDN team and IETF IDNA experts, update the
> derived property value registry according to RFC 5892 and
> property values as defined in The Unicode Standard version 6.0"
> 
> <http://www.iana.org/assignments/idnabis-tables/idnabis-tables
> .xml> is the affected IDNA Derived Properties registry, and
> apparently 5892bis only states that the rows 0CF1..0CF2 and
> 19D0..19DA will stay as they are when this registry will be
> updated for TUS 6.0.
> 
> The relevant IETF IDNA expert is a coauthor of 5892bis.  What
> is this "internal IDN team" -- I don't see why not changing
> two lines in a registry requires a team, do I miss something
> obvious?

IANA is supposed to install and keep complete tables
--corresponding roughly to the Stringprep one-- for IDNA
character validity for each version of Unicode.  These tables
represent derived, precomputed, values, not the authoritative
ones obtained by making the calculations called for in RFC 5892
and many new code points were added in 6.0, so there is
considerably more than "not changing two lines in a registry

So, indeed, you missed something obvious this time.

best,
   john