BCP 47 Extension U
draft-davis-u-langtag-ext-04

[Ballot comment]
I suspect the RFC editor will complain about the compound reference for [UTS35].  Are references to the specific sections needed?  If you want to keep them, then in the past the way I've seen it done (see RFC 5751) is to renumber 6.1 and 6.2 to 6.2 and 6.3.  Add a new section 6.1 that addresses says [UTS35] refers to the three new reference tags.  In the new section 6.2, make up some reference tags like: [UTS35-All], [UTS-Sec3], [UTS-Sec5].  It might be easier to just remove them.

Is the [US-ASCII] reference the same as:

    American National Standards Institute,
    "Coded Character Sets - 7-Bit American
    Standard Code for Information
    Interchange (7-Bit ASCII), ANSI X3.4",
    1986.

I ask because this was the reference recently suggested to me for ASCII.

[Ballot comment]
This is a fine specification. Here are a few nits.

1. Section 2.1 has the text "(for details see Section 3)" but that is a reference to Section 3 of UTS35, not to Section 3 of the RFC-to-be. Please either remove the parenthetical clause or state clearly "(for details see Section 3 of [UTS35])".

2. There is a typo in "the first occurrence of an attributes or key conveys meaning"; it seems that "attributes" should be "attribute".

3. In the text "[w]ith successive versions of [UTS35], additional attributes, keys, and types MAY be defined", I think "might" is better than "MAY" since there is no normative force to those words and therefore conformance terms don't apply.

4. The information about accessing machine-readable files is helpful to developers, but might quickly become dated; I suggest providing a pointer to the CLDR project, such as "For information about retrieving machine-readable files listing the valid attributes, keys, and types associated with each successive version of [UTS35], visit ."

IANA comments:

IANA understands that, upon approval of this document, IANA must
complete a single action.

In the Language Subtag Extensions registry located at
http://www.iana.org/assignments/language-tag-extensions-registry
a single new entry should be added as follows:

%%
Identifier: u
Description: Unicode Locale
Comments: Subtags for the identification of language and cultural
variations. Used to set behavior in locale APIs. Data is
located in the "common/bcp47" directory inside the referenced
URL. Unicode Technical Standard #35 (LDML) provides additional
reference material defining the keys and values.
Added: 2010-mm-dd
RFC: [TBD]
Authority: Unicode Consortium
Contact_Email: cldr-contact@unicode.org
Mailing_List: cldr-users@unicode.org
URL: http://www.unicode.org/Public/cldr/latest/core.zip
%%

IANA understands that the rules for maintenance of this registration
will be consistent with the rules specified in RFC 5646.

AD review comments were addressed.

Original AD review:

I don't have problems sponsoring this document. I verified requirements specified in RFC 5646 and I believe your document satisfies them. However I don't think that the BCP type is the right label in this case, as the registry was designed by the Unicode Consortium and is entirely under control of the Unicode Consortium. I would be more comfortable with using AD-sponsored Informational RFC, which still fits the "IETF Review" requirement specified in RFC 5646. Please let me know if you agree/disagree with this.

Other comments are minor, so feel free to address them before IETF Last Call, or after it (but before I I bring this document to IESG for review):

2.1.  Summary

  o  An 'attribute' is a subtag with a length of three or more
    characters following the singleton and preceding any 'keyword'

I think it would be better to say "a length of three to eight characters".
While the limit of 8 characters can be discovered from ABNF in RFC 5646,
I think it is better to say everything in one place.

    sequences.  No attributes were defined at the time of this
    document's publication.

  o  A 'keyword' is a sequence of subtags consisting of a 'key' subtag,
    followed by zero or more 'type' subtags (so a 'key' might appear
    alone and not be accompanied by a 'type' subtag).  A 'key' MUST
    NOT appear more than once in a language tag's extension string.
    The order of the 'type' subtags within a 'keyword' is sometimes
    significant to their interpretation.

[...]

    B.  A 'type' is a subtag with a length of three or more characters
        following a key.

Same comment as above.

        'Type' subtags are specific to a particular
        'key' and the order of the 'type' subtags MAY be significant
        to the interpretation of the 'keyword'.


4.  IANA Considerations

  There might be occasional maintenance of this
  record.

Is this statement truly needed? You can always update the record by publishing another RFC.
If you meant some other kind of maintenance, then this phrase is not specific enough to be useful to IESG or IANA.

  This document does not require IANA to create or maintain a
  new registry or otherwise impact IANA.


In Section 6.1 you have both:

  [BCP47]    Davis, M., Ed., "Tags for the Identification of Language
            (BCP47)", September 2009.

  [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
            Languages", BCP 47, RFC 5646, September 2009.

As far as I understand they are pretty much the same. Can you please eliminate one of them to avoid confusion.

------------------

Additional comments sent later:

I found one more issue that needs discussing and fixing (I also have some concern, which might result in an additional comment. I will send it separately. For the moment I need to think more about it.):

RFC 5646, section 3.7 says:

  Single-character subtags are assigned by IANA using the "IETF Review"
  policy defined by [RFC5226].  This policy requires the development of
  an RFC, which SHALL define the name, purpose, processes, and

I think I found everything else, but where the process for maintaining the subtags is described?
If I missed that, please kind point me to the relevant text in the draft.

  procedures for maintaining the subtags.  The maintaining or
  registering authority, including name, contact email, discussion list
  email, and URL location of the registry, MUST be indicated clearly in
  the RFC.  The RFC MUST specify or include each of the following:

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd is Martin Dürst (duerst@it.aoyama.ac.jp), has reviewed draft-davis-u-langtag-ext-02 personally, and thinks it's ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

This is not a WG document. The document has received review from key members of the language tagging 'community' and from other experts in internationalization and localization.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

No.

                                            For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed?

No.

                    If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is no WG. But the document has the strong consensus of the companies and individuals behind the CLDR localization effort of the Unicode Consortium.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?

No.

                    If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough.

The tool complains about one instance of a non-RFC2606-compliant FQDN, but unfortunately does not say where that is. There are some comments/warnings about using normative references, but they are all okay/irrelevant. This is with respect to the intended status, BCP. However, my personal opinion is that Informational would be okay for this document. (many Mime Type registration documents are Informational)

                                                    Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes. No such reviews are needed in this case.

  (1.h) Has the document split its references into normative and
        informative?

Yes.

                    Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?

No.

              If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

Yes.

                        If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?

Yes.

                    Are the IANA registries clearly identified?

Yes.

                                                                If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The document defines how to include references to entries in an already existing third-party (Unicode Consortium, not IANA) registry in BCP47 language tags through the extension mechanism. The Unicode Consortium has over the year built up wide experience and a strong track record with registries of all kinds related to characters and localization, and is in an excellent position to maintain this registry.


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Not applicable.


  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.
    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?
    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?


Technical Summary

    The document specifies the 'u-' extension to BCP 47 language tags,
    which provides subtags that specify locale-oriented properties
    (such as calendar, collation, currency, time zone) according to
    work done by the Unicode Consortium in the context of CLDR (Common
    Language Data Repository) and LDML (Locale Data Markup Language).

Working Group Summary

    This document is not the product of any IETF working group.

Document Quality

    The document has been reviewed by various language tagging and
    localization experts. In the context of CLDR (Common Language Data
    Repository) and LDML (Locale Data Markup Language), the proposed
    extension will be used widely. Uses in other localization contexts
    are also possible, because this extension provides a very
    convenient way to extend IETF language tags (BCP47) with the
    usually small missing bits of information to designate a locale.