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.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.