Subject: RE: [Ltru] Re: Moving Forward

From: "Peter Constable" <[email-masked]>
Date: Wed, 13 Apr 2005 13:39:57 -0700

> From: McDonald, Ira [mailto:[email-masked]]

> With no disrespect meant, I'll ignore those blithe responses from
> Mark and Peter who seem to think the problem (loss of region utility)
> will never happen or will always get quickly fixed by some vendor.

I'm sure Mark appreciates being ignored as much as I. Note that I did
not say I thought that the problem will never happen or always get
fixed. I said that your statement was too vague to evaluate. You simply
painted a grave picture with a blanket statement for which it was
impossible to tell what the real extent of the problem is. Just like the
earlier blanket statement "this breaks backward compatibility" -- that
simply was not a useful statement. In both cases, there really is a need
to identify what are the specific kinds of scenarios that are a concern.

> [The 'havoc' I meant was the complete loss of lookup capability for
> a deployed HTTP client application that has a configured 'en-GB' tag
> and tries to read Web content from an 'en-Latn-GB' tagged HTTP server.
> And the weeks of problems before "support" fudges some fix - since
> "support" didn't put the 'en-Latn-GB' tags there - the crummy content
> distribution application did.]

Now I'll be "blithe" (well, blithe really isn't the appropriate term).
If a software developer makes a bad choice because something is possible
and they didn't give adequate thought to it, I think that's their
problem, and that the issue really is the extent to which we are leading
reasonably intelligent software developers into likely pitfalls. 

Section 2.3 has the following statement:

<quote>
2. Avoid using subtags that are not important for distinguishing content
in an application. For example, including the script subtag in
"en-Latn-US" is generally unnecessary, since nearly all English texts
are written in the Latin script and it is generally not important to
filter out those few that are not.
</quote>

It might be in order in section 2.3 to draw greater attention to and
provide increased guidance on the matter of when to include or not
include a script subtag, perhaps making that a separate subsection
(2.3.1).

> To Addison's question I'll answer more seriously:
> 
> Make script _third_ and allow (as always) the omission of the _second_
> position region.  That format has the desirable property that
'en-Latn'
> means "English in Latin script, don't care about region" (because
> region was explicitly omitted).  That can never cause breakage in
> existing LDAP and other applications because of displacement of
> region and still gets you exactly what you want for script primacy.

Sure it can. As has been stated before, there are problem scenarios no
matter what order for subtags is used because of the limitations of
left-prefix matching. If an existing client requests zh-Hant and an
existing server has zh-HK-Hant, the match will fail. And note that your
problem scenario involved a tag the use of which would be *discouraged*
for general use, en-Latn-GB, this scenario would be involving the use of
*recommended* tags.

Again, you are making blanket statements -- "that wreaks havoc, this
never breaks" where what is needed is to examine which things do and
don't work, because no matter how we propose dealing with this, there
will be some scenarios in which some things don't work. Not because
there's a problem with the tags, but because there's a problem with
inadequate matching algorithms.

Peter Constable

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Apr 2005 15:00:51 -0700

Hi -

> From: "Peter Constable" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, April 13, 2005 1:39 PM
> Subject: RE: [Ltru] Re: Moving Forward
...
> include a script subtag, perhaps making that a separate subsection

I think part of the discomfort is that a statement like "generally unnecessary"
is not strong enough.  If it's easier for a programmer to write code that puts
a script tag on everything, "generally unnecessary" will be read as permission.
>From this discussion, it seems that putting a "-Latn" in the middle of en-US
is not merely unnecessary; it's downright harmful.

Could we make this strong enough to spell out conditions when script subtags
MUST NOT be used in tagging information, and to find a way to represent
these conditions in registry entries?  This could take the form of some
additional fine-tuning to the description of "Associated_Script", and might
need an additional field.

Examples of how it sounds like we want things to work:
    English & its varieties stay naked when latin, gets a -Brai when needed
    Vietnamese & its varieties stay naked when latin, marked when no^m,
    Mongolian and its varieties are always marked for script
    Gothic is naked when in latin transcription, marked when in its historic alphabet

...
> inadequate matching algorithms.
...

Agreed, but the extent to which these inadequate algorithms are implemented
in existing software, we as a WG need to be very conscious and conscientious
about which scenarios will and won't work in a net populated with new and old
applications, as well as new and old data.  In cases where we don't give
MUST/MUST not rules, we need to be sure that our guidance is very clear.
If not following a SHOULD causes things to *break*, then "SHOULD" isn't
strong enough.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 13 Apr 2005 15:41:37 -0700

> these conditions in registry entries?  This could take the form of some

The problem is that this is really the province of matching, which we were
constrained to move into a separate document. There are absolutely
circumstances, as I outlined early, where it is perfectly reasonable and
correct to use something like en-Latn. In the base document we can just
indicate that much; in the matching document we would set out when one would
use script in tags and when not.

I really do think this is making a mountain out of a molehill. As we've seen
from 3066, in practice people just don't use the tags that are unnecessary
or don't make sense. We only see a very small number of the possible
generative English tags in real life:

en-AF, en-AL, en-DZ, en-AS, en-AD, en-AO, en-AI, en-AQ, en-AG, en-AR, en-AM,
en-AW, en-AU, en-AT, en-AZ, en-BS, en-BH, en-BD, en-BB, en-BY, en-BE, en-BZ,
en-BJ, en-BM, en-BT, en-BO, en-BA, en-BW, en-BV, en-BR, en-IO, en-BN, en-BG,
en-BF, en-BI, en-KH, en-CM, en-CA, en-CV, en-KY, en-CF, en-TD, en-CL, en-CN,
en-CX, en-CC, en-CO, en-KM, en-CG, en-CD, en-CK, en-CR, en-CI, en-HR, en-CU,
en-CY, en-CZ, en-DK, en-DJ, en-DM, en-DO, en-EC, en-EG, en-SV, en-GQ, en-ER,
en-EE, en-ET, en-FK, en-FO, en-FJ, en-FI, en-FR, en-GF, en-PF, en-TF, en-GA,
en-GM, en-GE, en-DE, en-GH, en-GI, en-GR, en-GL, en-GD, en-GP, en-GU, en-GT,
en-GN, en-GW, en-GY, en-HT, en-HM, en-VA, en-HN, en-HK, en-HU, en-IS, en-IN,
en-ID, en-IR, en-IQ, en-IE, en-IL, en-IT, en-JM, en-JP, en-JO, en-KZ, en-KE,
en-KI, en-KP, en-KR, en-KW, en-KG, en-LA, en-LV, en-LB, en-LS, en-LR, en-LY,
en-LI, en-LT, en-LU, en-MO, en-MK, en-MG, en-MW, en-MY, en-MV, en-ML, en-MT,
en-MH, en-MQ, en-MR, en-MU, en-YT, en-MX, en-FM, en-MD, en-MC, en-MN, en-MS,
en-MA, en-MZ, en-MM, en-NA, en-NR, en-NP, en-NL, en-AN, en-NC, en-NZ, en-NI,
en-NE, en-NG, en-NU, en-NF, en-MP, en-NO, en-OM, en-PK, en-PW, en-PS, en-PA,
en-PG, en-PY, en-PE, en-PH, en-PN, en-PL, en-PT, en-PR, en-QA, en-RE, en-RO,
en-RU, en-RW, en-SH, en-KN, en-LC, en-PM, en-VC, en-WS, en-SM, en-ST, en-SA,
en-SN, en-SC, en-SL, en-SG, en-SK, en-SI, en-SB, en-SO, en-ZA, en-GS, en-ES,
en-LK, en-SD, en-SR, en-SJ, en-SZ, en-SE, en-CH, en-SY, en-TW, en-TJ, en-TZ,
en-TH, en-TL, en-TG, en-TK, en-TO, en-TT, en-TN, en-TR, en-TM, en-TC, en-TV,
en-UG, en-UA, en-AE, en-GB, en-US, en-UM, en-UY, en-UZ, en-VU, en-VE, en-VN,
en-VG, en-VI, en-WF, en-EH, en-YE, en-YU, en-ZM, en-ZW

‎Mark

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 23 Apr 2005 04:59:45 +0200

Mark Davis wrote:

> We only see a very small number of the possible generative
> English tags in real life:
 
> en-AF, en-AL, en-DZ, en-AS, en-AD, en-AO, en-AI, en-AQ
[...]

If that's supposed to be a complete list I would miss en-AX
and some odd 3066bis cases:

en-AA, en-AX, en-BU, en-CS, en-DD, en-FX, en-NT, en-SU, en-TP
en-YD, en-ZR, en-ZZ, en-001, en-002, en-003, en-005, en-009
en-011, en-013, en-014, en-015, en-017, en-018, en-019, en-021
en-029, en-030, en-035, en-039, en-053, en-054, en-057, en-061
en-062, en-142, en-145, en-150, en-151, en-154, en-155, en-200
en-419, en-830, en-833

Based on a lstreg.txt with 'File_Date: 2005-04-19' and a quick
and dirty script.  

BTW, what's the difference between the '003 North America' and
'021 Northern America' ?  The 200 should be deleted IIRC.  Bye.

---

From: John Cowan <[email-masked]>
Date: Fri, 22 Apr 2005 23:10:10 -0400

> '021 Northern America' ?  The 200 should be deleted IIRC.  Bye.

Northern America is an economic grouping, and refers to Canada and
the U.S.  North America is a geographical grouping, and includes
Northern America, Central America, and the Caribbean.

-- 
Yes, chili in the eye is bad, but so is your    John Cowan
ear.  However, I would suggest you wash your    [email-masked]
hands thoroughly before going to the toilet.    http://www.reutershealth.com
        --gadicath                              http://www.ccil.org/~cowan

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 23 Apr 2005 06:22:41 +0200

John Cowan wrote:
 
>> what's the difference between the '003 North America' and
>> '021 Northern America' ?  The 200 should be deleted IIRC. 
 
> Northern America is an economic grouping, and refers to
> Canada and the U.S.  North America is a geographical
> grouping, and includes Northern America, Central America,
> and the Caribbean.

I'm not sure, "economic groupings" shouldn't be registered:

| B. UN numeric codes for 'economic groupings' or 'other
|    groupings' are _not_ defined in the IANA registry and
|    MUST NOT be used to form language tags.

On the page http://unstats.un.org/unsd/methods/m49/m49regin.htm
003 apparently only exists in footnote "b" for 021:

| b/ The continent of North America (003) comprises Northern
|    America (021), Caribbean (029), and Central America (013).

Obscure region numbers existing only as footnotes should not
be registered, it's too confusing.

Another dubious region number is 062 "South-central Asia" vs.
"Southern Asia".  The  UN page first introduces 034 "Southern
Asia" and later uses 062 with the same name "Southern Asia".

                         Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 23 Apr 2005 13:27:18 +0200

What should be registered is what people identify themselves 
with.  Registrations should result from RFCs updating the BPC 047 by a 
WG-TAGS the strategy of which should be defined by the IESG under the 
review of the IAB. Each registration should be supported be three persons 
of reference authoritative in the area of the registration.
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 24 Apr 2005 04:01:48 +0200

JFC (Jefsey) Morfin wrote:

> with.

No, it should be as the registry draft says.  For the region
numbers it says (in other words) "anything not covered by a
registered 3166-1 alpha-2 CC, excl. the economic and other
groupings, as found in the list of valid UN region numbers."

My source has no valid 003 under these rules, maybe Doug has
a "better" source.  Splitting the same continent in different
overlapping ways is a fundamentally flawed idea, I certainly
hope that my source "wins".  North vs. Northern America is a
headache for language tags.  3066bis isn't about geography
or geology.  Show me one language where 003 is really useful,
and I shut up.
                         Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 24 Apr 2005 05:17:39 +0200

Frank Ellermann wrote:

> Show me one language where 003 is really useful, and I shut up.

apa-003.  Sigh.