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

Sat Aug 28 18:48:17 CEST 2004

Thanks for your comments, which are as always very insightful.

Comments below.

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

  -----Original Message-----
  From: ietf-languages-bounces at alvestrand.no
[mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Peter Constable
  Sent: Saturday, August 28, 2004 3:26 AM
  To: ietf-languages at alvestrand.no
  Subject: draft-05: (mostly) editorial comments (3)

  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

  AP> Because four character variants are illegal. The year numbered things
haven't been legal subtags since Mark and I removed the Gregorian calendar
based feature back in draft-01.

  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.

  AP> More confusingly 'es-americas' was "not approved" before it was
approved.  Don't get me started on discussing this!

  AP> I think this is a reasonable addition.

  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.

   AP> That would be the last sentence. Grandfathered tags (like "i-navaho")
become deprecated due to registration of subtags (like 'nv'). I'll add an
example.

  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.

  AP> Do we need text to that effect? The documentation is just a comment in
the file. In fact, an extensive header could be added to the file by way of
documentation. But it isn't necessarily relevant to the draft.

  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."

  AP> Yep.

  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.)

  AP> Okay.

  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".

  AP> Yes.

  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".

  AP> Per the discussion on the list this past week or two, I think that's
appropriate. I replaced the example in section 2 yesterday and will replace
this one.

  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.

  AP> We can make this clearer, I suppose. You comment above is, of course,
our intent.

  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:

  AP> We could just remove the word "registered". The comment is not limited
to variants, even though those are the subtags that have recommended
prefixes.

  AP> Basically what this says is: you can use any subtag in combination
with any other subtag (i.e. the generative mechanism still holds).
Recommended prefixes are informative. Thus "fr-Hant-boont" is a valid
language tag, even though it is also a stupid language tag to choose and
boont has a prefix of en-.

  AP> I'll go through and tighten the text.

  "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)."

  AP> Yep.

  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.

  AP> Okay.

  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.

  AP> Is it really necessary? Endorsing particular references invites
unnecessary criticism of the draft. Getting the references has never posed a
problem in the past.

  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/27e221a3/attachment-0001.htm