draft-05: (mostly) editorial comments (3)

Sat Aug 28 12:25:47 CEST 2004

Remaining comments - three that are substantive in nature rather than
editorial:

Substantive comments:

Section 3.1, example of registry: It's not clear to me why de-1996 etc.
are being treated as grandfathered rather than having 1996 and 1901
added to the registry as variant subtags. Suggestion:

variant; 1901; orthographic conventions established circa 1901;
2004-08-27; ; de ; # introduced for German traditional orthography

variant; 1996; orthographic conventions established circa 1996;
2004-08-27; ; de ; # introduced for German revised orthography of 1996

Section 3.3: 

<quote>

When the two week period has passed, the subtag reviewer, who is
appointed by the IESG, either forwards the request to IANA at IANA.ORG, or
rejects it because of significant objections raised on the list or due
to problems with constraints in this document (which should be
explicitly cited). Note that the reviewer can raise objections on the
list if he or she so desires. The important thing is that the objection
must be made publicly.

</quote>

OK, here's something that's more than editorial. I'd like to see a
requirement that the subtag reviewer must report the status of a request
to the list at the end of the two week period. One of the administrative
problems that has occurred in a few cases has been that two weeks and
more have gone by, and the reviewer has not declared any action, at
which point the whole thing has been in a nebulous state of limbo, which
has been frustrating. If discussion isn't over after two weeks, then I
would allow the reviewer to extend the discussion period by an
additional two weeks. But these time periods need to be formally
defined. I want to avoid an experience like "es-americas", in which
after two weeks there was no action, but then out of the blue many
months later the item was approved.

Section 3.3:

<quote>

Registrations are permanent and stable. Once registered, subtags will
not be removed from the registry and will remain the canonical method of
referring to a specific language or variant. This provision does not
apply to grandfathered tags, which may become deprecated due to
registration of subtags.

</quote>

What happens if an ID is added to ISO 639? E.g. "i-navaho" was
registered, but later obsoleted by addition of a code in ISO 639. Will
that continue to be the case or not? If not, then I would state that
explicitly.

Editorial comments:

Section 3.1: The structure of records isn't documented within the most
recent version of the draft registry Doug Ewell has done. I think it
should be included there as well as here.

Section 3.1: "The field 'date' contains the date the record was added to
the registry in ISO 8601 format." As opposed to when the record was
added in a different format? Add a comma: "...registry, in ISO 8601
format."

Section 3.1: "Note that this field MUST NOT be modified..." Surely SHALL
NOT is the appropriate wording. MUST NOT suggests that users of the spec
have an ability to make such modification. (This applies to other places
later in section 3 as well.)

Section 3.2: "and 'IM' would be assigned '833' as an alias" - the term
"alias" isn't defined; elsewhere this field is called "canonical value".

Section 3.2: The example with "zh-min-nan" is less than ideal since we
don't expect "min" could ever become a valid subtag with a semantic
consistent with zh. Perhaps just use "zh-gan".

Section 3.3: "Only primary language and variant subtags will be
considered for registration." This relates to the issue I mentioned from
section to regarding the definition of "registered". Perhaps the way to
handle this terminologically is to refer to "internal registration"
versus "external registration", where the latter is the process
specified in section 3.3 for requests that come from outside the RFC,
and the former refers to registrations that are given by specifications
internal to the RFC.

Section 3.3: "Any registered subtag MAY be incorporated into a variety
of language tags, according to the rules of Section 2.1, including tags
that do not match any of the intended language ranges of the registered
subtag..." - Is this still talking about variant subtags, or about all
subtags? If the former, then that's not clear; if the latter, then the
relationship between arbitrary subtags and language ranges isn't clear.
Same issue with the following paragraphs: 

"The intended language ranges for a given registered subtag..."

"Requests to add a language range to a subtag..."

Section 3.3: "...the registered subtag (Note that this is probably a
poor choice)." - The punctuation and capitalization are not consistent.
Either 

"...subtag. (Note... choice.)"

or

"...subtag (note... choice)."

Section 3.3:

<quote>

Decisions made by the reviewer may be appealed to the IESG [RFC 2028][9]
under the same rules as other IETF decisions [RFC 2026]. All registered
forms are available online in the directory
http://www.iana.org/numbers.html under "languages".

</quote>

These two sentences appear to be unrelated; use separate paragraphs.

Section 3.3: 

<quote>

In most cases, reference to an authoritative grammar or dictionary of
that language will be useful; in cases where no such work exists, other
well known works describing that language or in that language may be
appropriate.

</quote>

I had suggested when RFC 3066 was being drafted that reference to
entries in Ethnologue should be suggested. With ISO 639-3 moving closer
to IS, perhaps it's appropriate for me to suggest this again. You could
also suggest reference to the Linguist List codes, one for ancient and
extinct languages and one for constructed languages, as these are also
being used as sources for ISO 639-3 (for entries, not for identifiers):

http://linguistlist.org/ancientlgs.html

http://linguistlist.org/constructedlgs.html

You could also mention Linguasphere as a possible cross-reference,
particularly for variant subtag registrations.

That's all my comments on draft 5.

Peter Constable

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-languages/attachments/20040828/38356261/attachment.htm