Subject: [Ltru] Last Call comments for draft-4646bis-17

From: "Doug Ewell" <[email-masked]>
Date: Sun, 28 Sep 2008 22:53:55 -0600

Here are my last-minute comments on draft-4646bis-17.  For convenience, 
I've marked these (T) for technical or (E) for editorial, though the 
line between the two is sometimes blurry.

As always, this is not guaranteed to be a comprehensive review; there 
may or may not be other errors or "opportunities for improvement" that I 
might have caught if I had read more carefully.

Section 2.2.6, last paragraph:

--> (E) Replace "extention" with "extension".  Also, this sentence needs 
a terminating period.

Section 2.2.8, end of second paragraph:

--> (E) Replace "curiousity" with "curiosity".

Section 2.2.9, second-to-last paragraph:

--> (T) The passage beginning with "Users" and continuing to the end of 
the paragraph is not as clear as it should (IMHO) be.  The example of 
"en-x-personal" shows when privately-assigned subtags are acceptable, 
when the emphasis should be on showing when they are not acceptable. 
There are also unnecessary quotes around the freshly defined term 
"valid" and a dangling modifier ("Besides not being 'valid', the 
user...").  I suggest the following replacement text:

"Users MUST NOT assign language tags that use subtags that do not appear 
in the registry, other than in private-use sequences.  For example, at 
the time this memo was written, the region subtag 'AB' was not assigned 
in the registry.  A user MUST NOT assume that 'AB' is available for 
private use, and MUST NOT assign a language tag such as "en-AB" that 
reflects this assumption.  Besides not being valid, such a subtag also 
risks collision with a future possible assignment or registration."

Section 3.1.2, bullet point on "Preferred-Value":

--> (E) The sub-bullet point on "language" covers the exact same 
scenario as the following sub-bullet point on "script", "region", and 
"variant", but worded slightly differently.  These could be combined 
into one bullet point to reduce confusion.

Section 3.1.2, bullet point on "Prefix":

--> (E) Replace "entended" with "extended".

Section 3.1.5, end of second paragraph:

--> (T?) The following passage has always bugged me:

"... nor are any of the descriptions guaranteed to be in any particular 
language (such as English or French, for example)."

We have an entire 88-page document devoted to tagging language content, 
and we have to insert this parenthesized phrase explaining what we mean 
by a language?  Does this sentence lose any clarity if we drop it?

Section 3.1.5. end of fourth paragraph:

--> (E) Replace "and and" with "and".

Section 3.1.5. sixth paragraph:

--> (T) This example is no longer valid because ISO 639-3 made the 
necessary changes to their code lists to eliminate duplicates.  Joan 
Spanne has said they plan to continue checking for this in the future, 
so there may not be any situations like this in the future.  It may be 
best to invent a hypothetical example here.

Section 4.1, fourth paragraph:

--> (T) The passage reads: "... no valid language tag can become 
invalid, nor will a language tag have a narrower scope in the future (it 
may have a broader scope)."  I know this is our intent, and in most 
cases it will be true, but we have seen edge cases such as 
Khasi/Lyngngam where ISO 639 has chosen to split off one language from 
another, and in that case we did carry over the slight narrowing of 
scope.  Rather than commit to an absolute, I wonder if it would be 
better to hedge slightly: "... nor will a language tag have a 
substantially narrower scope..."

Section 4.1, item 4 (1):

--> (E) Replace "Germanic langauges" with "Germanic languages".

Section 4.1.2, end of third-to-last paragraph:

--> (E) In the sentence "... which could be more precisely be tagged 
with 'arb' (Standard Arabic).", remove the second "be".  (You could 
remove the first "be" instead, but the other way keeps this sentence 
consistent with the one before.)

Section 4.2, second paragraph:

--> (T) "'tlh-Kore-AQ-fonipa' (Klingon, Korean script, as used in 
Antarctica, IPA phonetic transcription)"

I'm not sure this is the best example of a tag that is valid but 
unlikely to be useful, since 'Kore' and 'fonipa' could not logically 
occur together.  The other example, "ar-Cyrl-CO", is at least 
theoretically possible.  I'd suggest deleting either 'Kore' or 'fonipa' 
to keep the focus on "valid but unlikely" instead of shifting the focus 
to "logically impossible."

Section 4.3, sub-bullet points under "Content items":

--> (E) The second and third sub-bullet point items should end in a 
period, as does the first, since they are all complete sentences.

Section 4.4, first paragraph:

--> (E) The passage "... larger tags have always been both possible and 
have actually appeared in use" is not parallel in its construction.  As 
a slight improvement, I suggest "... larger tags have always both been 
possible and actually appeared in use."  (Imagine a (1) before "been" 
and a (2) before "actually".)

Section 4.4.2, first paragraph:

--> (E) The passage "... MUST NOT permit a subtag to be chopped off in 
the middle or the formation of invalid tags..." is not parallel.  Try 
"... or an invalid tag to be formed..."

Section 4.5, fourth-to-last paragraph:

--> (T) "... processors MAY regularize the case of the subtags (that is, 
this process is OPTIONAL)..."  What is the purpose of the parenthetical 
clause?  RFC 2119 promises us that is what "MAY" means.  Delete it.

Section 5.1, several places:

--> (E) Please put e-mail addresses and URLs in angle brackets 
consistently, instead of double quotes:  <[email-masked]>, not 
"[email-masked]".   Check the rest of the document for this, by searching 
on "http" and "@".

Section 9.1, Normative References:

--> (T) Now that draft-4646bis is in WG Last Call, please update the 
reference to [registry-update].  I know I've been a bit slow to post 
updates to draft-4645bis, but I have updated it more recently than 
September 2006.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru