Subject: Re: [Ltru] Editorial Comments Only--RFC4646bis-11

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 11:37:49 -0800

Hi -

As a technical contributor...

> From: "CE Whitehead" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Friday, February 15, 2008 10:55 AM
> Subject: Editorial Comments Only--RFC4646bis-11
...
> * * *p.3, Section 1, PAR 2COMMENT: You might want to add here a brief
> note saying that language tags do not facilitate/gurarantee proper
> document display;  you need to declare the character encoding if
> you want to insure correct display of the characters/text in a
> document. (Also pp. 10-11,  Section 2.2.3:COMMENT:  Again,
> perhaps it might be mentioned that the encoding is what needs to be
> declared to get text display right, not the script???) 

Actually, there are cases where knowing the language permits better
rendering of the data.  For example, there are a few ideographs
which one might  choose to render differently depending on
whether the language is Chinese or Japanese.  Opinions about
the significance of such cases vary.  In any case, knowing the
encoding is pretty obviously fundamental, at the level
of "it goes without saying."

> * * *p.10., Section 2.2.2:
> "2.2.2.  Extended Language Subtags   "Extended language subtags
> are permanently reserved.  They MUST NOT be   registered or used
> to form language tags (except in grandfathered   tags).  They were
> originally created to allow for certain kinds of   compatibility mappings
> which ultimately were not used." COMMENT:  Insert (for clarity) a
> reference to the other draft??
...

A reference to an i-d would not make sense here.  At best, it would be
a reference to RFC 4646, which would be rather self-evident.

Randy

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

---

From: CE Whitehead <[email-masked]>
Date: Mon, 18 Feb 2008 13:32:35 -0500

Hi, I have revised my comments on the first part of the draft. Hope you find these helpful! --C. E. [email-masked] From: [email-masked]: [email-masked]> General comment: at this point, if you want a 
> change you should indicate precisely the text that is > to be replaced and by precisely what text. So we 
> really can't take any action on most of these. Other > comments below.> Mark

Done!
 
On Fri, Feb 15, 2008 at 10:55 AM, CE Whitehead <[email-masked]> wrote:

Hi,  so far I've read through p. 32, section 3.4 in: http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-11.txt Following are some editorial comments (from my perspective, these would make the draft more readable to outsiders--people not completely familiar with all this yet; just some requests for clarifications and cross-references that would be nice, if you all agree).. . .Thanks!   --C. E. [email-masked]  * * *p.3, Section 1, PAR 5> If you are requesting a change, provide exactly the 

> change in the text that you propose. 

"Tags can also be used to indicate additional language attributes of content. For example, indicating specific information about the dialect, writing system, or orthography used in a document or resource may enable the user to obtain information in a form that they can understand, or it can be important in processing or rendering the given content into an appropriate form or style."
 
==> "For example, indicating specific information about 
the dialect, writing system, or orthography used in a document or resource may enable the user to obtain information in a form that they can understand, or it, together with the declaration of document encoding type, can be important in processing or rendering the given content into an appropriate form or style."

COMMENT/DISCUSSION:  It's nice to insert a short note here that it is not just the language declaration that is used for this; I think that makes the fifth paragraph of the first section "More Useful."
 
(ALSO, ONE MORE TRIVIAL COMMENT ON THIS SECTION:  "form or style?"  "processing or rendering??"  
Would not it be best to choose between processing or rendering?  I think it's first processed then rendered; that is the text is processed; then part of the processing involves rendering it for the user; I'd say
instead of 
"processing or rendering" 
=> "rendering" 
only but it's no big deal!)   * * *p.10, Section 2.2.2:

"2.2.2.  Extended Language Subtags   "Extended language subtags are permanently reserved.  They MUST NOT be registered or used to form language tags (except in grandfathered tags).  They were originally created to allow for certain kinds of compatibility mappings which ultimately were not used." INSERT  => "The grandfathered tags formed with extended language subtags, for example, zh-gan,  

> will be deprecated (most often with a preferred value).
 "
COMMENT:  Inserting this information makes it clear what is happening to the grandfathered tags!  Otherwise I was left wondering. 
* * *
 
p. 11, Section 2.2.4, item 3:"The following rules define which codes are entered       into the registry as valid subtags:" INSERT  =>
 
"The following rules define which codes are entered       into the registry as valid regional subtags:"
 
 (COMMENT:  Sorry, it's just not clear that you mean "regional" here; somehow without the word 'regional' spelled out it seems like you've jumped back to the general talk about language tags)

* * *

p. 11, Section 2.2.4, Item 3.C: "UN numeric codes for countries or areas which are assigned           ISO 3166 alpha2 codes already present in the registry, MUST           be defined according to the rules in Section 3.4 and MUST be           used to form language tags that represent the country or           region for which they are defined.  This happens when ISO           3166 reassigns a code formerly used for one country to           another."
 
CHANGE LAST SENTENCE,
"This happens when ISO 3166 reassigns a code formerly used for one country to another." 
=> "The numeric subtags for countries are used instead of the subtags for countries formed with letters only when ISO 3166 reassigns a letter code formerly used for one country to another country."

COMMENT:  That this was done to avoid collisions was not clear from the draft, although it's been amply addressed in the ltru discussion; however it needs to be clarifiied in the draft.  

Thanks.
 
* * *
 
I also support John Cowan's proprosed change (which is not strictly editorial):
 
> penultimate paragraph of 
> 4646bis,> Editor's Draft, Section 3.1.6:> Original text:> The field 'Preferred-Value' MUST NOT > be modified once created in the> registry. The field MAY be added to 
> records according to the rules in> Section 3.3 (Maintenance of the 
> Registry).> Proposed revised text:> The field 'Preferred-Value' MUST not > be removed from a record.  If the> subtag described by the record 
> becomes deprecated, this field MAY
> be added according to the rules in 
> Section 3.3.  In that case, any 
> records which refer to this one 
> through their own 'Preferred-Value' 
> fields are updated to refer to the new 
> preferred value, so that it is not
> necessary to navigate from a
>  deprecated subtag via another 
> deprecated subtag to> reach a preferred subtag.> Discussion:> This is a substantive change which 
> bites the bullet directly and allows> update of the 'Preferred-Value' field 
> so that it at all times refers to> the value which is in fact preferred.
* * *
p.3, Section 1, PAR 1: "Human beings on our planet have, past and present, used a number of languages."=> DELETE!
 
"There are many reasons why one would want to identify the   language used when presenting or requesting information."
 
=> "When presenting or requesting information, there are a number of reasons for identifying the human (as opposed to programming) languages used." 
 
COMMENT/DISCUSSION:  However, as Mark Davis pointed out,
> As I recall, that sentence has made its way through different versions. 
 
It's unlikely then that this part will be changed; and this change is not important to me.  So SKIP; the remaining changes are more important!
 
* * *

 Best wishes,
 
--C. E. Whitehead
[email-masked]

---

From: Addison Phillips <[email-masked]>
Date: Thu, 21 Feb 2008 19:15:09 -0800

Mark Davis wrote:
> General comment: at this point, if you want a change you should indicate 
> precisely the text that is to be replaced and by precisely what text. So 
> we really can't take any action on most of these. Other comments below.
> 

Editor hat on: My co-editor is correct. Some comments follow as appropriate.

> 
>     p.3, Section 1, PAR 1:
>      "Human beings on our planet have, past and present, used a number
>     of languages."
> 
>     COMMENT:  Seems you can just skip this sentence and start w. next
>     sentence.
> 
> 
> I think the reason for this is just to focus on human languages (rather 
> than programming languages). Perhaps we could change:
> 
>    Human beings on our planet have, past and present, used a number of
> 
>    languages.  There are many reasons why one would want to identify the
>    language used when presenting or requesting information.
> 
> =>
> 
>    Human languages may need to be clearly identified when presenting or requesting information.
> 
> 
> [the text then goes on to list reasons.]

As technical contributor:

The sentence being objected to appears in RFC 1766. As a sense of 
history, I think we ought to preserve at least ONE of Harald's original 
sentences. Certainly this innocuous one would be a good choice.

Note: I agree with all of Mark's other comments.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: Addison Phillips <[email-masked]>
Date: Thu, 21 Feb 2008 19:46:21 -0800

Comments as technical contributor (unless otherwise noted) follow.

CE Whitehead wrote:
>          
>         * * *
>         p.3, Section 1, PAR 5
> 
>          > If you are requesting a change, provide exactly the 
> 
>         "Tags can also be used to indicate additional language
>         attributes of content. For example, indicating specific
>         information about the dialect, writing system, or orthography
>         used in a document or resource may enable the user to obtain
>         information in a form that they can understand, or it can be
>         important in processing or rendering the given content into an
>         appropriate form or style."
>          
>         the dialect, writing system, or orthography used in a document
>         or resource may enable the user to obtain information in a form
>         that they can understand, or it, together with the declaration
>         of document encoding type, can be important in processing or
>         rendering the given content into an appropriate form or style."

I think this paragraph would be redundant with other information in the 
introduction and elsewhere.
>          
>          
>         COMMENT/DISCUSSION:  It's nice to insert a short note here that
>         it is not just the language declaration that is used for this; I
>         think that makes the fifth paragraph of the first section "More
>         Useful."
>          
>         Would not it be best to choose between processing or rendering? 

Not really. They are different things.

>         I think it's first processed then rendered; that is the text is
>         processed; then part of the processing involves rendering it for
>         the user; I'd say
>         instead of
>         only but it's no big deal!)  

Rendering isn't always done on text. I suppose processing could be 
considered inclusive of the rendering process, but the distinction here 
is between a text process (such as spell-checking a text, say) and 
rendering (causing the text to be displayed).

> 
>          
>         * * *
>         p.10, Section 2.2.2:
> 
>         "2.2.2.  Extended Language Subtags
> 
>            "Extended language subtags are permanently reserved.  They
>         MUST NOT be registered or used to form language tags (except in
>         grandfathered tags).  They were originally created to allow for
>         certain kinds of compatibility mappings which ultimately were
>         not used."
> 
>          
>         INSERT  =>
>          "The grandfathered tags formed with extended language subtags,
>         for example, zh-gan,  
> 

This is actually wrong. The grandfathered tags---all of them---are RFC 
3066 era tags. They don't actually have extlangs (although some were 
registered with extlangs in mind, others clearly were not).

> 
>          "
> 
>         COMMENT:  Inserting this information makes it clear what is
>         happening to the grandfathered tags!  Otherwise I was left
>         wondering.

Nothing, actually, is happening to them that didn't already happen in 
RFC 4646. It *might* have happened that some became redundant, but this 
didn't turn out to be the case.

It might be useful, though, to indicate that grandfathered tags that 
match the extlang production don't change validity.

> 
> 
>         * * *
> 
>          
> 
>         p. 11, Section 2.2.4, item 3:
> 
>         "The following rules define which codes are entered
>                into the registry as valid subtags:"
>          
>         INSERT  =>
> 
>          
> 
>         "The following rules define which codes are entered
>                into the registry as valid regional subtags:"
> 
>          
> 
>          
>         (COMMENT:  Sorry, it's just not clear that you mean "regional"
>         here; somehow without the word 'regional' spelled out it seems
>         like you've jumped back to the general talk about language tags)

Section 2.2.4 is called "Region Subtag" and your proposed change occurs 
in a block headed by the phrase "The following rules apply to the region 
subtags:"

> 
>          
> 
>         * * *
> 
>         p. 11, Section 2.2.4, Item 3.C:
>          
>         "UN numeric codes for countries or areas which are assigned
>                    ISO 3166 alpha2 codes already present in the
>         registry, MUST
>                    be defined according to the rules in Section 3.4 and
>         MUST be
>                    used to form language tags that represent the country or
>                    region for which they are defined.  This happens when ISO
>                    3166 reassigns a code formerly used for one country to
>                    another."
> 
>          
> 
>         CHANGE LAST SENTENCE,
> 
> 
>         => "The numeric subtags for countries are used instead of the
>         subtags for countries formed with letters only when ISO 3166
>         reassigns a letter code formerly used for one country to another
>         country."

I was on my way to inserting an edit based on your suggestion, but think 
that maybe your request is already represented by the full paragraph:

<t>UN numeric codes for countries or areas which are assigned ISO 3166 
alpha2 codes already present in the registry, MUST be defined according 
to the rules in <xref target="ianastability"/> and MUST be used to form 
language tags that represent the country or region for which they are 
defined. This happens when ISO 3166 reassigns a code formerly used for 
one country to another.</t>

> 
>          
> 
>          
> 
>         COMMENT:  That this was done to avoid collisions was not clear
>         from the draft, although it's been amply addressed in the ltru
>         discussion; however it needs to be clarifiied in the draft. 

I edited the last sentence to try to clarify this thusly:

--
This happens when ISO 3166 reassigns a code already included in the 
registry and formerly used for one country to another.
--

Regards,

Addison

---

From: John Cowan <[email-masked]>
Date: Thu, 21 Feb 2008 23:21:23 -0500

> one country to another.</t>

What still remains open is what should happen when 3166/MA reassigns a
code formerly used for one country to that same country.

-- 
A rose by any other name                            John Cowan
may smell as sweet,                                 http://www.ccil.org/~cowan
but if you called it an onion                       [email-masked]
you'd get cooks very confused.          --RMS
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: Addison Phillips <[email-masked]>
Date: Thu, 21 Feb 2008 21:06:45 -0800

> code formerly used for one country to that same country.

Yes, the Burma->Myanmar->Burma conjecture. Care was used not to prohibit 
it here.

Addison

---

From: CE Whitehead <[email-masked]>
Date: Fri, 22 Feb 2008 13:23:33 -0500

Hi all,
Here are the strictly editorial edits I sent that I think really should go in> From: [email-masked]> > Hi,> > Do not send me private email asking for edits. Even my co-editor's > requests go to the list.> > Addison
 
Sorry, I know better.
Here the requests are again, on the list  (these are the most strictly important of the editorial changes I suggested).
 
--C. E. Whitehead
[email-masked]> > CE Whitehead wrote:> > Addison, thanks for going through these! The three changes I still want > > are at the top of this email, numbered 1, 2, 3.> > > > 1.

p.10, Section 2.2.2:
"2.2.2. Extended Language Subtags"Extended language subtags are permanently reserved. They MUST NOT be registered or used to form language tags (except in grandfathered tags). They were originally created to allow for certain kinds of compatibility mappings which ultimately were not used."

 > > >COMMENT: O.k., make it clear what ishappening to the grandfathered tags! Otherwise I'm leftwondering.> > >> > >> > > Nothing, actually, is happening to them that didn't already happen in> > > RFC 4646. It *might* have happened that some became redundant, but this> > > didn't turn out to be the case.> > >> > > It might be useful, though, to indicate that grandfathered tags that> > > match the extlang production don't change validity.> > >COMMENT:  O.k. thanks, that would be good if you could make it clear that they do not change validity; but what is this extlang stuff?  I thought we got rid of that; 
sorry to trouble you > > > >> > > > * * *
p. 11, Section 2.2.4, Item 3.C:> > 2.> > > <t>UN numeric codes for countries or areas which are assigned ISO 3166> > > alpha2 codes already present in the registry, MUST be defined according> > > to the rules in <xref target="ianastability"/> and MUST be used to form> > > language tags that represent the country or region for which they are> > > defined. This happens when ISO 3166 reassigns a code formerly used for> > > one country to another.</t>
Insert
>= "The numeric codes are thus used to avoid collisions."
> > >> > >> > > >> > > >> > > >> > > >> > > >> > > > COMMENT: That this was done to avoid collisions was not clear> > > > from the draft, although it's been amply addressed in the ltru> > > > discussion; however it needs to be clarifiied in the draft.> > >> > >> > > I edited the last sentence to try to clarify this thusly:> > >> > > --> > > This happens when ISO 3166 reassigns a code already included in the> > > registry and formerly used for one country to another.> >COMMENT:
Addison, thanks, it's clearer this way!But I still think you've got to say something about "avoiding collisions"> > > > * * *> > 3.> > Also one more minor change that to me seems important,> > > > {Page 35, Section 3.5, last paragraph; CORRECT GRAMMAR in the last > > paragraph }> > "Registrations initiated due to the provisions of Section 3.3 or> > Section 3.4 SHALL NOT be rejected altogether (since they have to> > ultimately appear in the registry) and SHOULD be completed as quickly> > as possible. The review process allows list members to comment on> > the specific information in the form and the record it contains and> > thus help ensure that it is correct and consistent."> > =>> > > > "Registrations initiated due to the provisions of Section 3.3 or> > Section 3.4 SHALL NOT be rejected altogether (since they have to> > ultimately appear in the registry) and SHOULD be completed as quickly> > as possible. The review process allows list members to comment on> > the specific information in the form and the record it contains and> > thus help ensure that this information is correct and consistent."> > > > { COMMENT change 'it,' as the antecedent is unclear }> > > > > > Thanks,> > > > --C. E. Whitehead> > [email-masked] <mailto:[email-masked]>           > >

---

From: Addison Phillips <[email-masked]>
Date: Fri, 22 Feb 2008 11:23:40 -0800

CE Whitehead wrote:
>    
> Hi all,
> Here are the strictly editorial edits I sent that I think really should 
> go in

Thanks.

>  > > 1.
> "Extended language subtags are permanently reserved. They MUST NOT be 
> registered or used to form language tags (except in grandfathered tags). 
> They were originally created to allow for certain kinds of compatibility 
> mappings which ultimately were not used."
> 
>  > > >
> COMMENT: O.k., make it clear what is
> happening to the grandfathered tags! Otherwise I'm left
> wondering.

I'm not sure that grandfathered tags belong here. Look: you only know 
that this affects (or, rather, fails to affect) certain grandfathered 
tags because you are participating here. Extended language subtags have 
nothing to do with grandfathering. Note that this paragraph has been 
edited and is in a different form in draft-12 (the editor's copy).

> COMMENT:  O.k. thanks, that would be good if you could make it clear 
> that they do not change validity; but what is this extlang stuff?  

Would this work:

<t>Note: a few grandfathered tags (<xref target="preexisreg"></xref>) 
matched the 'extlang' production in RFC 4646, and thus were not 
considered 'irregular'. These tags are still valid and were added to the 
'irregular' production in the ABNF.</t>

> I 
> thought we got rid of that;
> sorry to trouble you

We removed a production that appeared in RFC 4646 in drafting this 
document. Please read the full paragraph we have in draft-12 and see if 
it doesn't convey that.

> COMMENT:
> Addison, thanks, it's clearer this way!
> But I still think you've got to say something about "avoiding collisions"

We do, but adding lots and lots of text redundant with other text 
elsewhere in the document makes our overly-long draft even longer. The 
full paragraph has an explicit link to section 3.4 where this is 
explained in great detail.

>  > >
>  > > * * *
>  > > 3.
>  > > Also one more minor change that to me seems important,
>  > >
>  > > {Page 35, Section 3.5, last paragraph; CORRECT GRAMMAR in the last
>  > > paragraph }
>  > > "Registrations initiated due to the provisions of Section 3.3 or
>  > > Section 3.4 SHALL NOT be rejected altogether (since they have to
>  > > ultimately appear in the registry) and SHOULD be completed as quickly
>  > > as possible. The review process allows list members to comment on
>  > > the specific information in the form and the record it contains and
>  > > thus help ensure that it is correct and consistent."
>  > > =>
>  > >
>  > > "Registrations initiated due to the provisions of Section 3.3 or
>  > > Section 3.4 SHALL NOT be rejected altogether (since they have to
>  > > ultimately appear in the registry) and SHOULD be completed as quickly
>  > > as possible. The review process allows list members to comment on
>  > > the specific information in the form and the record it contains and
>  > > thus help ensure that this information is correct and consistent."
>  > >
> 
>  > > { COMMENT change 'it,' as the antecedent is unclear }

Really, it is clear enough.

Addison