Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP)

From: "Addison Phillips" <[email-masked]>
Date: Fri, 8 Apr 2005 13:02:55 -0700

> Does your suggestion about "recommended prefix" include moving
> the country codes firmly back to second position?

Emphatically not. I think that is a poor choice for all the reasons previously enumerated. Putting script after region only solves identification of region codes for a certain subset of language tags and implementations and does so at great disadvantage to language tags and implementations that require script codes.

I disagree that my proposal accomplishes nothing substantive: you really should go read it first. 

What it does is help users avoid choosing ill-advised tags that include scripts for those languages where it is of little value and likewise include them consistently for languages where it is of importance.

There is NO requirement that software have a copy of the registry. 

Software that uses prefixes and remove-from-right (RFR) previously (which is many but not all of the current implementations) all work out-of-the-box with this solution, since the problem was having to "know something" about the tags in order to expand or ignore the script subtag when matching. This does away with the need to do that by making tag prefixes consistent for a given language range. 

Users are advised that their tags choices may cause selection problems if they choose to use script subtags with a prefix that normally would not take one or with content where script collections subtags were not previously used. (i.e. this doesn't solve all possible problems, but then no solution does)

Software such as Ned Freed has described, which depends on the country code being in the second position and may use an exception table to find it in a limited number of other cases, does exist. These implementations will not recognize the region subtag in tags that use script subtags. They wouldn't have recognized these tags anyway and treated them as unknown registered tags: essentially "I don't know what this is". Matching may or may not have proceeded on RFR (RFC 2616 matching) terms after that. We can debate whether an implementation that doesn't is "broken" or not. One that does would be in exactly the same position as the other RFR processors (see above). One that does not has a problem with that subset of tags.

What my proposal does is try to limit how often script subtags are used by advising tag consumers about when to use them, but this same information could easily be used to generate a new exception table for the "Freed-style" implementations.

Also: the nature of 3066bis tags, unlike 3066 tags, is that you NEVER need the registry to identify the region subtag (or any other subtag). The tag format is stricter and does it for you. You can write a "Freed-style" algorithm based on 3066bis and it will always work (to the extent that the subtag types can be identified), which is NOT something you can say about 3066 Freed-style algorithms (*and* that exception table is a copy of the registry!!)

Yes, existing processors may not recognize tags such as "sr-Cyrl-CS" as containing a region subtag. 

But with the recommended prefix on Cyrl one could update such an implementation, which, in fact, is already necessary, even if IANA hasn't gotten around to noticing just yet.

So it is a compromise that tries to address some of the problems of compatibility without changing the design.

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: McDonald, Ira [mailto:[email-masked]]
> Sent: vendredi 8 avril 2005 12:36
> To: Addison Phillips; John Cowan; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP)
> 
> Hi Addison,
> 
> I'm lost (hundreds of LTRU messages polluted my inbox today).
> 
> Does your suggestion about "recommended prefix" include moving
> the country codes firmly back to second position?
> 
> If yes, then I agree.  If no, then nothing substantive is
> accomplished.
> 
> The idea that compatible software that supports comparison of
> language tags in the RFC3066bis era MUST have a copy of the
> registry is a lousy idea.
> 
> 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 Addison Phillips
> > Sent: Friday, April 08, 2005 1:31 PM
> > To: John Cowan; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP)
> >
> >
> > To back up for a second: does my proposal about recommended
> > prefix (I think you indicated initial enthusiasm, Ned) solve
> > this problem sufficiently to move forward with this design?
> >
> > 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 John Cowan
> > > Sent: vendredi 8 avril 2005 10:18
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP)
> > >
> > > [email-masked] scripsit:
> > >
> > > > A compliant RFC 3066 implementation can (and I know for a
> > fact has) been
> > > > written that handles these exceptions through an
> > exception table, but
> > > still
> > > > operates under the assumption that a two letter code in the second
> > > position is
> > > > a country code but a two letter code elsewhere is not.
> > >
> > > An assumption quite without warrant in the text of RFC 3066.
> > >
> > > > Like it or not, there are lots of application domains where script
> > > information
> > > > is much less readily available than country information.
> > >
> > > The intention (as Addison has developed in his messages on
> > the subject) is
> > > to use script information only for those languages where it
> > is commonly
> > > required.
> > >
> > > > Not true. The question is what was or was not
> > standardized in the past.
> > > The
> > > > rules for country code positioning were clearly written
> > and clearly
> > > normative.
> > >
> > > RFC 3066 states that a 2-letter subtag in the second position is
> > > normatively
> > > a country code.  It nowhere states the converse, and goes
> > out of its way
> > > to say that there are no rules for positions past the second.
> > >
> > > --
> > > De plichten van een docent zijn divers,         John Cowan
> > > die van het gehoor ook.
> > [email-masked]
> > >       --Edsger Dijkstra
> http://www.ccil.org/~cowan
> >
> > _______________________________________________
> > 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: Frank Ellermann <[email-masked]>
Date: Sat, 09 Apr 2005 02:17:32 +0200

Addison Phillips wrote:

> great disadvantage to language tags and implementations that
> require script codes.

This "disadvantage" is impossible:

1 - At the moment no RfC 3066bis implementation exists.  Proof:
    3066bis isn't an RfC at the moment.

2 - Future implementations of the future RfC can get it right.
    Otherwise the RfC is so broken that it should be no RfC.

3 - The future RfC can say lang-extlang-region-script-variant.
    Implementations can match tags in any allowed way.  Maybe
    using "Accept-Script" as in draft-lilly-content-script-01

It's good to break a bad idea completely, and the idea of RTL
matching in four dimensions was never convincing.  We'd need a
math. expert, it's not trivial, John's 8-2-4-1 could work.

> I disagree that my proposal accomplishes nothing substantive

ACK, instead of specifying an optional default script for the
language plus a rule that it SHOULD NOT be used explicitly, you
have some languages for each script plus a rule that it SHOULD
be used explicitly.
                    Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Fri, 8 Apr 2005 21:26:53 -0400

> have some languages for each script plus a rule that it SHOULD

Yup.  They're mathematically equivalent.

-- 
Business before pleasure, if not too bloomering long before.
        --Nicholas van Rijn
                John Cowan <[email-masked]>
                        http://www.ccil.org/~cowan  http://www.reutershealth.com

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 09 Apr 2005 03:48:50 +0200

John Cowan wrote:
 
>> instead of specifying an optional default script for the
>> language plus a rule that it SHOULD NOT be used explicitly,
>> you have some languages for each script plus a rule that it
>> SHOULD be used explicitly.
 
> Yup.  They're mathematically equivalent.

SHOULD NOT and SHOULD are fuzzy logic, I missed this lecture,
but it MAY be good enough. ;-)  For which language can we use
it as an example in the text and in the registry ?  Debbie said
ess, but that's not yet registered.
                                    Bye, Frank