Document: draft-phillips-langtags-06
Reviewer: Joel M. Halpern
Date: 22 september 2004 

This document is not ready for publication as a BCP.

This document does not appear to be a BCP.  It appears to be defining
a format, and a collection of registries for that format.  As such, it
is defining a set of bits on a wire.  It is defining the value of
certain tags.  It has significant interoperability implications.  If
it is good, it ought to be a PS.  If we don't know, I suppose it could
be experimental (but then the protocol tags it is defining ought to be
x-).

The other aspect, with all due apologies to the authors for what looks
to have been a lot of work, is that the quality of the document is
low.  It is just plain hard to read.  It has many subtle assumptions,
which are not clearly explained / motivated.

I am not a language / language tag expert.  I may be missing the
point.  Sorry if I am merely confused.

Yours, Joel M. Halpern

minor:
    The absence of spaces in the BNF had me looking for lines named
    "3ALPHA", and related confusions.  I had to actually go check 2234
    to make sure how to read this.

    I gather that the separation of types of subtags based on lengths
    is "necessary" due to external forces.  If so, some text that says
    ~we know this is generally a bad practice, and implementors need
    to ver VERY VERY careful because of taht~ would seem a good idea.

    The "singleton" has a restriction (not "x") that is not captured
    in the ABNF, but presumably would actually need to be captured for
    a parser to do its job right.

    The BNF for grandfathered and the later text for grandfathered do
    not match.  The later text seems to indicate that all
    grandfathered language tags will start with a primary subtag of
    the single character "i".  But the BNF does not say that.  It says
    that anything that starts with at least one ALPHAs
    (i.e. everything that complies with the BNF) might be a
    grandfathered tag.

   The structure of this document does not help readability.  There
   is, for example insufficient use of section boundaries.  All of the
   rules for all of the subtags are given in one section, with no
   sub-section separation.  The numbered list in section 2.4.1 (thank
   you for numbering the list) has the two interesting properites of
   firstly containing an example with numbered elements, placed to
   confuse the reader about numbering scope, and secondly a numbered
   list element that contains no base text but instead two notes,
   causing the reader to think there is text missing.  (I am guessing
   in fact that element 2 was supposed to be part of element 1, but
   that something trying to format in the figure got confused.)

    The IANA registration form description ought to include some
    explanation of the "redundant" type value.  I can guess what is
    meant, but I should not have to guess.  I presume the strange
    structure of the IANA registrations data file is a hold-over from
    earlier definitions?  Should it say that?

   The fact that the "Language Subtag Reviewer" is a person appointed
   by the IESG is called out (as far as I can tell) only in text
   buried in the middle of the application process description.  That
   does not seem the right place to say this.  I would think that
   there ought to be a short section, before the application process,
   that states that the registry is managed, by a person appointed by
   the IESG.  This can state concisely why there is such a person.  It
   can also capture the duties of that person relative to tracking
   changes in the external standards (which are buried in the text
   about the registry currently.)


Nit:
    Still uses 2026 boilerplate.  No Intellectual Property Disclaimer.