Alexey Melnikov wrote:

> This is the first batch. I received a fairly long list of comments and 
> still deciding what to do with the rest.

Sorry for the delay. This is the second batch. There would also be a
third (and the last) batch, with about 6 issues.

8). Section 1 currently says:

   This document replaces [RFC4646], which replaced [RFC3066] and its
   predecessor [RFC1766].  For a list of changes in this document, see
   Section 8.

RFC 4646 used to say:

   This document, in combination with [RFC4647], replaces [RFC3066],
   which replaced  [RFC1766].  For a list of changes in this document,
   see Section 8.

I think it would be more correct for 4646bis to say:

   This document replaces [RFC4646]. This document, in combination
   with [RFC4647] replaces [RFC3066] and its predecessor [RFC1766].
   For a list of changes in this document, see Section 8.

9). Several elements of the syntax in Section 2.1 are not complete
because there are extensive discussions elsewhere in the document that
describe the actual, and considerably restrictive, rules for valid
elements.  The relevant productions would be much more useful to the
reader if they cross-referenced the defining sections (e.g. in ABNF
comments).  Specific and important examples are that the "extlang"
production should point to Section 2.2.2 and the "irregular" and
"regular" ones should explicitly indicate that the preferred forms are
found in the registry in the "Preferred-value" entry for the relevant tag.

10). In Section 2.2

>    o  "Subtag" refers to a specific section of a tag, delimited by
>       hyphen, such as the subtags 'zh', 'Hant', and 'CN' in the tag "zh-
>       Hant-CN".  Examples of subtags in this document are enclosed in
>       single quotes ('Hant').
>
>    o  "Code" refers to values defined in external standards (and which
>       are used as subtags in this document).  For example, 'Hant' is an
>       [ISO15924] script code that was used to define the 'Hant' script
>       subtag for use in a language tag.  Examples of codes in this
>       document are enclosed in single quotes ('en', 'Hant').

These definitions make it sound that "code" and "subtag" are separate
categories. But "code" is a subset of "subtag".
Is there a need to have both "codes" and "subtags" in this document?

11). Paragraph 3 of Section 2.2 asserts that "...identification of the
subtag's type [is] possible, even if the content of the subtag itself is
unrecognized".

Without a table summarizing the rules a reader needs to infer them from
ABNF in Section 2.1 and possibly by reading the rest of the document. A
compact text or table summarizing the rules would improve the document.

12). In Section 2.2.1:

>    5.  Any language subtags of 5 to 8 characters in length in the IANA
>        registry were defined via the registration process in Section 3.5
>        and MAY be used to form the primary language subtag. An example
>        of what such a registration might include: one of the
>        grandfathered IANA registrations is "i-enochian".  The subtag
>        'enochian' could be registered in the IANA registry as a primary
>        language subtag (assuming that ISO 639 does not register this
>        language first), making tags such as "enochian-AQ" and "enochian-
>        Latn" valid.
>
>        At the time this document was created, there were no examples of
>        this kind of subtag and future registrations of this type are
>        discouraged: primary languages are strongly RECOMMENDED for
>        registration with ISO 639,

I suggest that the RECOMMENDED is changed to a MUST, i.e. an attempt to
register it with ISO 639 must be made. Even if the outcome might be
known, arguments given by ISO 639 might provide useful input to the
Language Subtag Expert.

>       and proposals rejected by ISO 639/ RA-
>        JAC will be closely scrutinized by the Language Subtag Reviewer
>        before they are registered with IANA.

This might be a big deal, so this might actually require wider review,
such as IETF LC.

13). In Section 3.5:

>    While the 'Description' field itself is not guaranteed to be stable
>    and errata corrections MAY be undertaken from time to time, attempts
>    to provide translations or transcriptions of entries in the registry
>    itself will probably be frowned upon by the community or rejected
>    outright, as changes of this nature have an impact on the provisions
>    in Section 3.4.

Suggested replacement for the paragraph:

   The 'Description' field itself is not guaranteed to be
   stable.  Corrections (possibly as errata) and updates are
   permitted with adequate justification.   However, addition
   of translations or transliterations are not considered
   sufficient justification for corrections or updates.

Reason: use of MAY is not an appropriate use of RFC 2119, as it is
trying to forecast the future and doesn't specify a protocol option.