Chairs,

Could you please choose and announce an appropriate time for
teleconferences? I think there is general agreement from those
participating that these are valuable. However, we have enjoyed
relatively low participation. It would be good to announce the time and
details in advance. I'm happy to continue providing access via our
teleconferencing service. Our last meeting (at 6 a.m. Pacific Daylight
Time on Thursday) was somewhat inconvenient and now time changes are
starting to occur between Summer and Standard time, rendering the call
more inconvenient for some.

Addison

--
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.


_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ltru

Rick McGowan wrote:
> The Unicode CLDR committee is planning to release a minor version, 1.5.1,
> by the end of November. There are a few changes in the specificiation
> associated with this change.
>
>       http://unicode.org/draft/reports/tr35/tr35.html
> Notable changes include:
> * Added C10. Likely Subtags for locale IDs or language tags.

One problem about a "private use" territory code currently used (QU):

[quote[TR35]]
   3. Identifiers
   (...)
   A locale ID is an extension of a language ID, and thus the structure and
   field values are based on [BCP47]. The registry of data for that
   successor is now being maintained by IANA. The canonical form of a locale
   ID uses "_" instead of the "-" used in [BCP47]; however, implementations
   providing APIs for CLDR locale IDs should treat "-" as equivalent to "_"
   on input.
   (...)
                    Locale Field Definitions
   --------------  ----------  ------------------------------------------
   Field           Allowable   Allowable values
                   Characters
   --------------  ----------  ------------------------------------------
   (...)
   territory_code  ASCII       [BCP47] subtag values marked as Type:
                   letters,    region, or any UN M.49 code that doesn't
                   numbers     correspond to a [BCP47] region subtag.
                               There are three private use codes defined
                               in LDML:
                                   QO Outlying Oceania
                                   QU European Union
                        &nbsp ;          ZZ Unknown or Invalid Territory
                               The private use codes from XA..XZ will
                               never be used by CLDR, and are thus safe
                               for use for other purposes by
                      &n bsp;        applications using CLDR data.
   --------------  ----------  -----------------------------------------
[/quote[TR35]]

Now let's look at the normative [BCP-47] reference:

[quote[BCP-47]]
2.2.4. Region Subtags
   (...)
   The following rules apply to the region subtags:
   (...)
   2.  All two-character subtags following the primary subtag were
       defined in the IANA registry according to the assignments found
       in [ISO3166-1] ("Codes for the representation of names of
       countries and their subdivisions -- Part 1: Country codes") using
       the list of alpha-2 country codes, or using assignments
       subsequently made by the ISO 3166 maintenance agency or governing
       standardization bodies.
[/quote]

Note that [BCP47] cites [ISO3166-1] as a source of codes, but it ***forgets
to list it in the list of normative references*** at end of the document.
It's not very precise about the list being effectively used; it just gives
the name of the whole document within the text itself: "Codes for the
representation of names of countries and their subdivisions -- Part 1:
Country codes", and refers to the "list of alpha-2 country codes"; it speaks
about "assignments", but does not indicate the normative status.

From there, I can find this official page:
http://www.iso.org/iso/iso-3166-1_decoding_table where the "EU" code is in
yellow background described as "exceptional reservations". This links to
this page:
http://www.iso.org/iso/customizing_iso_3166-1.htm , which says:

[quote]
To avoid transitional application problems and to aid users who require
specific additional code elements for the functioning of their coding
systems, the ISO 3166/MA may set aside code elements which it undertakes not
to use for other than specified purposes during a limited or indeterminate
period of time. These are called reserved code elements and their use is
normally restricted to the application they were reserved for.
(...)
Code elements not included in the current version of ISO 3166-1 may be
reserved by the ISO 3166/MA,
* (...)
* as "exceptional reservations", at the request of national ISO member
bodies, governments and international organizations. This applies to certain
code elements required in order to support a particular application, as
specified by the requesting body and limited to such use; any further use of
such code elements is subject to approval by the ISO 3166/MA.
[/quote]

So [BCP47] indicates that the [ISO3166-1] country code "EU", listed in the
list of alpha-2 country code for the European Union, should be used as it
was reserved for indeterminate time. BCP47 does not seem to restrict the use
of alpha-2 codes that were "exceptionally reserved".

For [ISO3166-1], the code "EU" is an exception reservation; its use in LDML
(if it has to become an international standard) would conform to the needed
"support for a particular application". All that is needed is that Unicode
requests approval by the ISO 3166/MA.

Why is LDML using the private use code "QU", apparently in contradiction
with BCP47? Shouldn't it be changed to use "EU" according to BCP47
recommandation and the other policy in LDML that warns against the use of
private use codes that can be changed at any time?

Does Unicode want to request approval by ISO 3166/MA for the use of the "EU"
code in LDML and CLDR (as indicated in ISO3166-1)? I think it would be in
the interest of many applications that already use "EU" in the localization
data, but NOT "QU" because it is a "user-assigned code element" not meant
for interchange.

Note that [ISO3166-1] also says:

[quote]
When exchanging data with users of ISO 3166-1 not connected to this
particular in-house application the definition of these user-assigned code
elements should be given.
[/quote]

This is what is performed in the LDML specification, but is it enough to
permit interchange of data?

Mark Davis wrote:
> This is a misreading of the text. One of the reasons for the last
> revision of BCP 47 was to make it absolutely clear when codes were
> valid or not. The valid codes are all and only those that are in
> http://www.iana.org/assignments/language-subtag-registry. EU is not
> there (as a region), thus it is not valid.

Note that your URL is NOT directly referenced by [BCP47], and the
terminology used cannot clearly state that fact. So it is not so clear in
the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA
website. Note that [BCP47] does not even list [ISO3166-1] as a normative
reference, and not even as an informative reference (most probably this was
forgotten)!

Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to
the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in
LDML and CLDR, even if there's still no agreement without BCP47 (what the
IETF wants to restrict for BCP47 would be immediately invalidated by any
authorization made by the ISO 3166-1/MA).

That's why I finished my message with this question: did you request such
authorization to the ISO 3166-1/MA?

Mark Davis wrote:
> This is a misreading of the text. One of the reasons for the last
> revision of BCP 47 was to make it absolutely clear when codes were
> valid or not. The valid codes are all and only those that are in
> http://www.iana.org/assignments/language-subtag-registry. EU is not
> there (as a region), thus it is not valid.

Note that your URL is NOT directly referenced by [BCP47], and the
terminology used cannot clearly state that fact. So it is not so clear in
the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA
website. Note that [BCP47] does not even list [ISO3166-1] as a normative
reference, and not even as an informative reference (most probably this was
forgotten)!

Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to
the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in
LDML and CLDR, even if there's still no agreement without BCP47 (what the
IETF wants to restrict for BCP47 would be immediately invalidated by any
authorization made by the ISO 3166-1/MA).

That's why I finished my message with this question: did you request such
authorization to the ISO 3166-1/MA?

Mark, others,

[removing the Unicode mailing list from the cc.]

The LTRU WG has agreed some years ago to not use
"exceptionally reserved" codes from 3166-1.
We clearly don't want to reopen every
single discussion that we had leading to RFC 4646, but
if necessary, we can reconsider some of thae decisions
for RFC 4646bis. As an example, would it make sense for
the LTRU WG to ask for permission from the ISO 3166-1/MA?

Regards,    Martin.

P.S.: When we finalized HTML4, the Euro character was still
      not officially and finally approved by the UTC and
      ISO/IEC JTC1/SC2/WG2. We nevertheless assessed the
      risks and took the chance and defined a &euro; entity,
      with mapping to the proposed codepoint.


At 11:30 07/11/08, Mark Davis wrote:


>On 11/7/07, Philippe Verdy <<mailto:verdy_p <at> wanadoo.fr> verdy_p <at> wanadoo.fr> wrote:
>>Mark Davis wrote:
>>> This is a misreading of the text. One of the reasons for the last
>>> revision of BCP 47 was to make it absolutely clear when codes were
>>> valid or not. The valid codes are all and only those that are in
>>> <http://www.iana.org/assignments/language-subtag-registry >http://www.iana.org/assignments/language-subtag-registry. EU is not
>>> there (as a region), thus it is not valid.
>>
>>Note that your URL is NOT directly referenced by [BCP47], and the
>>terminology used cannot clearly state that fact. So it is not so clear in
>>the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA
>>website. Note that [BCP47] does not even list [ISO3166-1] as a normative
>>reference, and not even as an informative reference (most probably this was
>>forgotten)!
>
>No.
>
>I agree that in an ideal world we'd just have the URL in BCP 47, but it clearly states that
>
>
>    The Language Subtag
>    Registry maintained by IANA is the source for valid subtags: other
>   standards referenced in this section provide the source material for
>   that registry.
>
>So IANA is the source. As far as an user of BCP 47 is concerned, 3166 is just a *source* for data, and not all codes defined in 3166 will be valid in BCP 47.
>>Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to
>>the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in
>>LDML and CLDR, even if there's still no agreement without BCP47 (what the
>>IETF wants to restrict for BCP47 would be immediately invalidated by any
>>authorization made by the ISO 3166-1/MA).
>
>The Unicode Consortium could clearly use EU. No problem there. However, a goal of the Unicode CLDR group was and is to be compatible with BCP 47, and EU cannot be used there, conformantly.
>
>>That's why I finished my message with this question: did you request such
>>authorization to the ISO 3166-1/MA?
>
>That is moot, since the goal is compatibility with BCP 47, not with 3166.
>
>There is some background on BCP 47 on Addison's site ( http://www.inter-locale.com/); that might be easier to understand than the spec.
>
>
>
>
>--
>Mark
>_______________________________________________
>Ltru mailing list
>Ltru <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto: duerst <at> it.aoyama.ac.jp