Subject: Re: [apps-discuss] BCP 166, RFC 6365 on Terminology Used in Internationalization in the IETF

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Sep 2011 19:44:50 -0400

> A new Request for Comments is now available in online RFC libraries.
>
>        BCP 166
>        RFC 6365
>
>        Title:      Terminology Used in Internationalization in
>                    the IETF
>        Author:     P. Hoffman, J. Klensin
>        Status:     Best Current Practice

This is appsawg's first RFC (5892bis is still in the RFC Editor queue).  Boo-YA!

Barry, appsawg chair

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Sep 2011 21:07:53 -0400

--On Wednesday, September 07, 2011 19:44 -0400 Barry Leiba
<[email-masked]> wrote:

>>        Title:      Terminology Used in
>> Internationalization in                    the IETF

I'm happy to help with that distinction and am sure Paul is too
although a lot of the credit goes to the RFC Editor,
particularly Alice Hagens, for doing an outstanding job and
doing it very quickly.

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.

   john

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Sep 2011 21:24:55 -0400

> particularly Alice Hagens, for doing an outstanding job and

Indeed; as doc shepherd, I've been following the interaction.  John
and Paul were very responsive, and Alice has been her usual excellent,
professional self.  When it all works this way, it's a beautiful
thing.

> a nudge from the IETF side too.

Thanks for pointing that out to me; I'll check with Michelle.

Barry

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 8 Sep 2011 08:52:41 +0200

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

-Frank

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Sep 2011 05:59:45 -0400

--On Thursday, September 08, 2011 08:52 +0200 Frank Ellermann
<[email-masked]> 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.
> 
> 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

---

From: [email-masked]
Date: Wed, 7 Sep 2011 14:43:10 -0700 (PDT)

BCP 166        
        RFC 6365

        Title:      Terminology Used in Internationalization in 
                    the IETF 
        Author:     P. Hoffman, J. Klensin
        Status:     Best Current Practice
        Stream:     IETF
        Date:       September 2011
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      47
        Characters: 103155
        Obsoletes:  RFC3536
        See Also:   BCP0166

        I-D Tag:    draft-ietf-appsawg-rfc3536bis-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6365.txt

This document provides a list of terms used in the IETF when
discussing internationalization.  The purpose is to help frame
discussions of internationalization in the various areas of the IETF
and to help introduce the main concepts to IETF participants.  
This memo documents an Internet Best Current Practice.

This document is a product of the Applications Area Working Group Working Group of the IETF.

BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC