[Ltru] Editorial commenets on draft-4646bis-12

["Doug Ewell" <dewell at roadrunner.com>]

As far as I can tell, all of the following comments are editorial, 
except perhaps the comment that an expected technical change was not 
made.  If anyone spots a technical comment, please accept my apologies 
and move it to a separate Subject line.  None of these should be 
showstoppers; a few date back before the present draft, for which I 
apologize.


    Section 2, introduction:

The space after the comma in the passage "primary for human 
communication,such as" has been deleted.  Please add it back.


    Section 2.1, 2nd paragraph:

The last sentence mentions "the subtag registry" before it has actually 
been defined or described anywhere.  I suggest adding a reference to 
Section 3, or at the very least making the reference a bit more formal:

"Thus, a parser need not have an up-to-date copy (or any copy at all) of 
the IANA Language Subtag Registry to perform most searching and matching 
operations."


    Section 2.2.4:

This section should have all remaining references to "ISO 3166" changed 
to "ISO 3166-1", in keeping with the recent change made in the ABNF. 
For example, the passages in Section 2.2.4, item 3 about "ISO 3166 
alpha-2 codes" could be misinterpreted or deliberately twisted to refer 
to ISO 3166-2 alpha-2 code elements such as "OR".  I would actually 
recommend searching the entire document for "ISO 3166" and changing each 
instance to "ISO 3166-1" unless the result would be simply wrong.


    Section 3.1.6, 2nd paragraph from the end:

This section continues to state: "The field 'Preferred-Value' MUST NOT 
be modified once created in the registry."  While AFAIK there was no 
declared consensus to change this, I was quite sure there was popular 
support for making this field mutable, so that users of the Registry 
would not have to follow a sequence of P-V's, say from "i-hak" to 
"zh-hakka" to "hak".  I had been delaying the release of 
draft-4645bis-05 in anticipation of this change, but seeing none, I will 
go ahead and release the draft with the same P-V's as before.  (Q: Why a 
new draft-4645bis?  A: Because the ISO 639-3 code lists have changed.)


    Section 4.2, 3rd paragraph, just before bullet points:

Change spelling of "very" to "vary".


    Section 8, 29th bullet point (6th from the end):

The reference to RFC 4324 looks erroneous, and probably should be RFC 
5234.


    Section 9 generally:

I was surprised to see RFC 4645, which pertained to RFC 4646, listed as 
a normative reference while draft-4645bis, which pertains to the present 
draft, is only listed as informative.  I think this is because Section 
2.2.4, item 3 (E) makes reference to RFC 4645, and that item has not 
been changed since it appeared in RFC 4646.

Regarding the list in question, only 830 "Channel Islands" remains, and 
IMHO the 3166/MA would be crazy to assign this code now that GG and JE 
have been individually assigned.  However, it is possible, and this 
situation does justify a reference to RFC 4645.  But I still need a 
normative/informative lawyer to explain to me why that reference is 
normative while the reference to draft-4645bis is not.


    Section 9.1, 17th item (2nd from the end):

Change spelling of "Freitag" to "Freytag".  If Asmus were on the list, I 
would leave it up to him to correct the spelling or form of his name, 
but I don't think he is.


    Section 9.2, 9th item (5th from the end):

Change month "12" to "December".  Perhaps surprisingly, the rfc2xml tool 
doesn't automatically substitute month names when a numeric month and no 
day are given.  Perhaps one day...

--
Doug Ewell  *  Fullerton, California, 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
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru