[co-chair hat on]This is the last comment on issue #45 (http://trac.tools.ietf.org/wg/ltru/trac/ticket/45) that I have found.
Although further suggestions for minor "improvements" have been made, nobody has expressed strong disagreement for the current text on this issue in draft-22 (http://tools.ietf.org/html/draft-ietf-ltru-4646bis-22#section-4.5).
I therefore conclude that the text in draft-22 represents WG consensus on this issue.
With this, I think I have declared consensus on all the open issues, and these issues all can be closed. Two of them, if I count correctly, require editorial action. I would like to ask the editors to prepare an updated copy, ready for submission at my instruction.
Regards, Martin. On 2009/05/21 0:40, CE Whitehead wrote:
Hi. Since Mark is still arguing about this draft, I guess it's o.k. to insert my two cents again. From: Mark Davis<mark at macchiato.com> Date: Tue, 19 May 2009 10:45:40 -0700I should quickly add that I'm also ok with leaving the examples where they are in http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-22.html, just in the interests of timeliness. MarkI like Mark's suggested change for 4.5 item 3 -- but would like one more change (although there seems to be no reason to push for either change at this point): the one I suggested, the moving of the second sentence, first paragraph: { "For extlangs, the original primary language subtag is also replaced if there is a primary language subtag in the Preferred- Phillips& Davis Expires November 19, 2009 [Page 67] Internet-Draft language-tags May 2009 Value." } to the end of what's currently the first (Addison's text) bullet but is the second bullet in Mark's suggested text: Also Mark's new bullet at the top is a nice, an example: {'For example, although the tag "en-BU" (English as used in Burma) is valid, it is not in canonical form because the 'BU' subtag has a canonical mapping to 'MM' (Myanmar).'}; but I'm not sure it needs to be bulleted at all--this text just goes with the introductory sentence, maybe, at the top of item 3, not in a bullet Thanks. C. E. Whitehead cewcathar at hotmail.com "3. Subtags are replaced by their Preferred-Value, if there is one. For extlangs, the original primary language subtag is also replaced if there is a primary language subtag in the Preferred-Value. For example, although the tag "en-BU" (English as used in Burma) is valid, it is not in canonical form because the 'BU' subtag has a canonical mapping to 'MM' (Myanmar). The field-body of the Preferred-Value for extlangs is an "extended language range" and typically maps to a primary language subtag. For example, the subtag sequence "zh-hak" (Chinese, Hakka) is replaced with the subtag 'hak' (Hakka). { For extlangs, the original primary language subtag is also replaced if there is a primary language subtag in the Preferred-Value.} Most of the non-extlang subtags are either Region subtags where the country name or designation has changed or clerical corrections to ISO 639-1."On Tue, May 19, 2009 at 10:43, Mark Davis<mark at macchiato.com> wrote:Very good. Now that I see the result, I think you are right about moving the examples. I'd suggest the following locations (yellow for those who can see it), and a slight shortening. 4.5. Canonicalization of Language Tags Since a particular language tag can be used by many processes, language tags SHOULD always be created or generated in canonical form. A language tag is in 'canonical form' when the tag is well-formed according to the rules in Section 2.1 (Syntax) and Section 2.2 (Language Subtag Sources and Interpretation) and it has been canonicalized by applying each of the following steps in order, using data from the IANA registry (see Section 3.1 (Format of the IANA Language Subtag Registry)): Extension sequences are ordered into case-insensitive ASCII order by singleton subtag. For example, the subtag sequence '-a-babble' comes before '-b-warble'. For example, the language tag "en-b-ccc-bbb-a-aaa-X-xyz" is well-formed and potentially valid (extensions 'a' and 'b' are not defined as of the publication of this document) but not in a canonical form because the extensions are not in alphabetical order; the canonical form would be "en-a-aaa-b-ccc-bbb-X-xyz". Redundant or grandfathered tags are replaced by their Preferred-Value, if there is one. The field-body of the Preferred-Value for grandfathered and redundant tags is an "extended language range" ([RFC4647] (Phillips, A. and M. Davis, “Matching of Language Tags,” September 2006.)) and might consist of more than one subtag. Preferred-Value fields in the registry provide mappings from deprecated tags to modern equivalents. Many of these were created before the adoption of this document (such as the mapping of "no-nyn" to "nn" or "i-klingon" to "tlh"). Others are the result of later registrations or additions to the registry as permitted or required by this document (for example, "zh-hakka" was deprecated in favor of the ISO 639-3 code 'hak' when this document was adopted). Subtags are replaced by their Preferred-Value, if there is one. For extlangs, the original primary language subtag is also replaced if there is a primary language subtag in the Preferred-Value. For example, although the tag "en-BU" (English as used in Burma) is valid, it is not in canonical form because the 'BU' subtag has a canonical mapping to 'MM' (Myanmar). The field-body of the Preferred-Value for extlangs is an "extended language range" and typically maps to a primary language subtag. For example, the subtag sequence "zh-hak" (Chinese, Hakka) is replaced with the subtag 'hak' (Hakka). Most of the non-extlang subtags are either Region subtags where the country name or designation has changed or clerical corrections to ISO 639-1. ------------------------------------------------------------------------ _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
-- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.