Subject: RE: [Ltru] Re: Moving Forward

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 13 Apr 2005 12:50:28 -0700

Hi,

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.

[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.]

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.

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, April 13, 2005 1:54 PM
> To: McDonald, Ira; Peter Constable; [email-masked]
> Subject: RE: [Ltru] Re: Moving Forward
> 
> 
> So which of the alternate designs do you think is the right 
> one? (I'm not asking antagonistically, but because I want to 
> see this item, the last really major one, resolved in *some* way)
> 
> I note that every alternative has a downside too. IMO, script 
> is in the best (most logical) position between language and country. 
> 
> Moving it into the variant slot (by merging with variant or 
> between region and variant) produces content selection 
> problems (see Misha's message) and fallback problems. And you 
> still have the problem of omitted fields (my German examples, 
> examples with script but no region, etc.). 
> 
> Using an extension is appealing in some ways, but would 
> require many currently stupid processors (XML, CSS, etc.) to 
> become at least a little bit smarter about handling subtags 
> (something I'm not too keen on, but maybe it could work).
> 
> C'mon folks, we're offering different ways of addressing 
> objections to our design, but no one has offered a 
> contrasting position around which to build consensus. 
> 
> I'm open-minded enough to consider any solution and I will 
> abide by whatever consensus emerges which results in us 
> having the ability to distinguish script in a language tag. 
> But please don't just say "don't put it there". Tell us which 
> alternative and why you favor it. Or tell us exactly how our 
> design would have to be modified to be at least minimally 
> acceptable. Then Randy counts noses to see if one has reached 
> critical mass.
> 
> That is what we've tried to do with our script proposals: 
> work on overcoming specific individual's most pressing 
> objections in hopes of building (at worst) a grudging harmony.
> 
> Addison
> 
> Addison P. Phillips
> Globalization Architect, Quest Software
> Chair, W3C Internationalization Core Working Group
> 
> Internationalization is not a feature.
> It is an architecture. 
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On
> > Behalf Of McDonald, Ira
> > Sent: mercredi 13 avril 2005 10:39
> > To: 'Peter Constable'; [email-masked]
> > Subject: RE: [Ltru] Re: Moving Forward
> > 
> > Hi,
> > 
> > A good deal of digital ink is being expended on a problem
> > (Default/Associated/Expected Script) that _only_ occurs
> > because RFC3066bis is infixing script between language
> > and region.
> > 
> > And there remains every possibility that a software vendor
> > who sells a widely used application for mounting content
> > on Web servers will ignore that SHOULD NOT about using tags
> > like 'en-Latn-GB' and wreak a fair amount of havoc.
> > 
> > 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: [email-masked]
> > > [mailto:[email-masked]]On
> > > Behalf Of Peter Constable
> > > Sent: Wednesday, April 13, 2005 11:23 AM
> > > To: [email-masked]
> > > Subject: RE: [Ltru] Re: Moving Forward
> > >
> > >
> > > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > On
> > > > Behalf Of John Cowan
> > >
> > >
> > > > Note that the purpose of Associated_Script is
> > > > not to tell an implementer the usual script used with a
> > > language, but
> > > > simply to serve notice which script *subtags*, if any,
> > > should normally
> > > > be used with this language subtag.  This difference is 
> fundamental.
> > >
> > > We could make it more obvious, though. What about changing
> > > the label for
> > > the field to Expected_Script_Subtags? (I.e. 'it is expected
> > > that one of
> > > the following script subtags will also be used'.)
> > >
> > >
> > > > The specific answer is that for centuries Gothic has 
> been written
> > > solely
> > > > in the Latin script.  (This may start to change with 
> the presence of
> > > > Gothic in Unicode and the ready availability of Gothic 
> fonts, or it
> > > > may not.)  Therefore, no Associated_Script header 
> should be present,
> > > > and the tag got-Latn should be avoided (though got-Goth 
> would be in
> > > > order as an unusual script).
> > >
> > > The one concern for our plan would be what to do if some 
> apparently
> > > stable mono-script situation suddenly changes. If we tag 
> "got" today,
> > > with Latin script assumed, and "got-Goth" for the unusual
> > > scenario, and
> > > then next year a reform gets underway with the result that in
> > > five years
> > > the situation has reversed, then what do we do?
> > >
> > > Of course, I'm describing another scenario like Turkish, and those
> > > aren't all that likely. But a scenario such as going from
> > > only Cyrillic
> > > today to Cyrillic and Latin next year might not be so far fetched.
> > >
> > >
> > >
> > > Peter Constable
> > >
> > > _______________________________________________
> > > Ltru mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ltru
> > >
> > 
> > _______________________________________________
> > Ltru mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ltru
> 

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

---

From: John Cowan <[email-masked]>
Date: Wed, 13 Apr 2005 16:05:46 -0400

> region and still gets you exactly what you want for script primacy.

*sigh*

Not so.  An HTTP or LDAP request for "en-Latn" will not match existing
content or entries tagged "en-GB" or "en-US".

-- 
Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!
  -- Joyce, Ulysses, "Oxen of the Sun"       [email-masked]