Subject: RE: [Ltru] comments on draft-10

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 1 Mar 2006 12:20:53 -0800

+1

And yes to the questions at item (6) below.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: Addison Phillips [mailto:[email-masked]]
> Sent: Wednesday, March 01, 2006 1:10 PM
> To: [email-masked]
> Subject: [Ltru] comments on draft-10
> 
> 
> I have just a few substantive observations:
> 
> 1. For some reason the formulation "applications, protocols, 
> and specifications" was rendered as "applications, protocols, 
> and implementations" in a few places. I fixed this.
> 
> 2. In the penultimate paragraph in Section 3.1 (choosing 
> types of matching), I think we should include this normative 
> text directly after stating that the schemes don't require 
> the registry or validation:
> 
> --
> An implementation MAY choose to check if either the language 
> ranges or language tags being matched are "well-formed" or 
> "valid" (see <xref target="RFC3066bis" />, Section 2.2.9) and 
> MAY choose not to process invalid ranges.
> --
> 
> This will make it clear that, while checking is not required, 
> it is permitted.
> 
> 3. I think we need to change one aspect of extended range 
> matching: I don't think the match should proceed past 
> singletons unless the singleton is "named" in the range. 
> Currently the range "de-DE" would match "de-x-DE", which I 
> find problematic. Thus I'd propose changing the third 
> paragraph in Section 3.2.2 from:
> 
> --
> Take each non-wildcard subtag in the language range and 
> compare it to the next subtag in the language tag in turn 
> until a matching subtag is found or the langauge tag is 
> exhausted. If the end of the language tag is found first, the 
> match fails. If a match is found, this step is repeated with 
> the next non-wildcard subtag in the language range (and 
> beginning with the next subtag in the language tag) until the 
> list of subtags in the language range is exhausted or the match fails.
> --
> 
> To read:
> 
> <t>Take each non-wildcard subtag in the language range and 
> compare it in a case-insensitive manner to the next subtag in 
> the language tag. If the range's subtag exactly matches the 
> tag's subtag, proceed to the next non-wildcard subtag in the 
> language range (and beginning with the next subtag in the 
> language tag) until the list of subtags in the language range 
> is exhausted or the match fails. If the tag's subtag is a 
> "singleton" (a single letter or digit, which, in this case, 
> includes the private-use subtag 'x') and the range's subtag 
> does not match or if the language tag's list of subtags is 
> exhausted, the match fails. If the language range's list of 
> subtags is exhausted, the match succeeds.</t>
> 
> 3a. I think we should include counter examples to the ones that match:
> 
> --
> <t>The same range does not match any of the following tags 
> for the reasons shown:<list>
>    <t>de (missing 'DE')</t>
>    <t>de-x-DE (singleton 'x' occurs before 'DE')</t>
>    <t>de-Deva ('Deva' not equal to 'DE')</t>
> 
> </list></t>
> --
> 
> 4. I think it would also be useful to point out in this same 
> section the fact that 3066bis tag structure makes ranges 
> quite specific:
> 
> <t>Note: The structure of language tags defined by <xref 
> target="RFC3066bis" /> defines each subtag according to 
> position, size, and content. This means that the subtags in a 
> language range can only match specific types of subtags in a 
> language tag. For example, a subtag such as 'Latn' is always 
> a script subtag (unless it follows a singleton) while a 
> subtag such as 'nedis' can only match the equivalent variant 
> subtag (unless it follows a singleton).</t>
> 
> 5. In Section 3.3 (lookup) we show but say nothing about 
> removing singletons along with their just-following subtag, 
> but we demonstrate it. I.e.:
> 
> Zh-Hant-CN-x-private
> Zh-Hant-CN
> 
> It doesn't actually matter whether one does this or not, but 
> should we say anything?
> 
> 6. Section 4.1 (Choosing language ranges). Should we mention 
> that users SHOULD choose well-formed, valid, canonicalized 
> ranges? Also, should we again mention the ability for 
> implementations to check for any of those three attributes?
> 
> Addison
> 
> Addison Phillips
> Internationalization Architect - Yahoo! Inc.
> 
> Internationalization is an architecture.
> It is not a feature. 
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
> 

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