Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support ed

From: "McDonald, Ira" <[email-masked]>
Date: Sat, 21 May 2005 11:23:45 -0700

Hi Addison,

Please keep a Canonicalization section in ltru-registry draft.
I will urge that we say something like:

"Content authors and content authoring tools that create language
tags MUST create well-formed tags and SHOULD create Canonical tags, 
for near-term interoperability and long-term accessibility of the 
content."

I'm writing some text for addition to section 1 (a section 1.1
'Conformance Terminology' and section 1.2 'Language Tag Terminology')
that attempts to define the subjects of imperative verbs as they
occur in later sections - I'll send a draft in a day or two.

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: Saturday, May 21, 2005 1:47 PM
> To: Frank Ellermann; [email-masked]
> Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally
> support ed
> 
> 
> That turns out not to be quite true. Mark and I had a chat 
> last night about this issue, which, it turns out, hinges on 
> what canonicalization of a language tag means.
> 
> What we discussed was basically that the region subtag one 
> chooses ("Choice of Language Tag") does evolve along the 
> lines of the "Use" concept. It makes eminent sense and the 
> compromise I suggested earlier in the week is that way to 
> embody that in the draft.
> 
> Then there is the question of canonicalization. 
> Canonicalization for what? For comparison and matching, of 
> course. If you look at the way the Use or Canonical-Value 
> concept is set up, there is a date (in the Deprecated field) 
> associated with each mapping. This means that:
> 
> 1. For any given tag, you can construct what the comparable 
> tag would have been for any given earlier date.
> 
> 2. For any given tag, you can construct the set of comparable 
> tags that are valid at any given date (up to the date of the 
> registry).
> 
> 3. The purpose for doing this is to compare tags with ranges. 
> In other words, this text should appear in the matching 
> draft. (Whether it appears in the registry draft is a 
> separate matter, please note).
> 
> This means that the Use/Canonical-Value setup as described in 
> the email thread during this past week *does* meet Mark's 
> requirements for "canonicalization" because the data for 
> supporting the relationships he cares about is in the 
> registry. The next step is to incorporate the text into the 
> draft, which I will set about doing over this weekend, so we 
> can see what it looks like.
> 
> Any thoughts on whether to keep the canonicalization section 
> in the registry draft or just have it in matching?
> 
> 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 Frank Ellermann
> Sent: 2005?5?21? 0:23
> To: [email-masked]
> Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support ed
> 
> McDonald, Ira wrote:
> 
> > The problem we're wrestling with is that our ISO/UN sources
> > are _not_ entirely stable and we intuitively think we should
> > try to achieve better stability in the IANA Language Subtag
> > Registry.
> 
> My intuition was and is "mirror the sources as long as possible
> under the rule of stability".  Plus an emergency exit for cases
> like CS etc.
> 
> > We're probably catching at moonbeams...
> 
> ...some cosmic event like the CS disaster, yes.  It's rare.
> The "Use:" concept is IMHO a pretty simple way to survive it.
> But "Use:" is dynamic, not static, and Mark hates it.  Bye.
> 
> 
> 
> _______________________________________________
> 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: "Mark Davis" <[email-masked]>
Date: Sat, 21 May 2005 11:50:28 -0700

The problem is that there are two communities of users. For Frank (and
Ira?), not having the latest codes be in the canonical form is (I guess) not
fashionable (ok, I'm being a bit flip, but I really don't know what their
rationale is).

For us, having unstable canonical tags is useless. We (and the vast majority
of the world's infrastructure) can't canonicalize to the latest codes
because that would invalidate all the databases that use the
previously-canonical codes as keys.

What Addison and I realized is that the registry already has the information
to support both types of canonicalization. I think we have two choices:
A. define two specifications of the two types of canonicalization for the
different communities of interest in this document, or
B. what may be more practical and useful -- since canonicalization is
intimately associated with matching -- push the two specifications into the
matching document.

‎Mark

----- Original Message ----- 
From: "McDonald, Ira" <[email-masked]>
To: "'Addison Phillips'" <[email-masked]>; "Frank Ellermann"
<[email-masked]>; <[email-masked]>
Sent: Saturday, May 21, 2005 11:23
Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support
ed

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 May 2005 22:06:05 +0200

Mark Davis wrote:

> For Frank (and Ira?), not having the latest codes be in the
> canonical form is (I guess) not fashionable (ok, I'm being a
> bit flip, but I really don't know what their rationale is).

User1: My cc just changed from GE to XX...
M.D. : Don't panic, GE is still valid.
User1: But the new government is very XX.
M.D. : Forget governments.  This is the Internet.  Not a zoo.
User1: But ISO 3166 also says XX.
M.D. : ISO says many things.  IANA knows what's good for you.
User2 (interrupting): IANA has GG, can I use it ?
M.D. : That's a ccTLD and no country code.
User1: So I should use GE instead of XX ?
M.D. : Yes.
User2: I want GG.
M.D. : I'm only talking with User1, *plonk*
User1: Thanks, and there won't be a problem with GE ?
M.D. : Of course not, it's stable and canonical forever.

[some years later, Georgia finds that GE is free and grabs it]

User3: What are these crazy XX-bastards doing, are they mad ?
User2 (interrupting): I want GG.
User1: GE is XX.
User3: No, GE is Georgia.  Idiot.
User2: It's not GG.
User3: GE is Georgia. *plonk*
User1: No, it's XX.
M.D. : Wait a moment.
User3: We waited 50 years, that's long enough.
User1: No, GE is XX, I was 20 years in prison for saying GE.
User3: I've already told you that you're an idiot.

                         Bye, Frank

---

From: "Mark Davis" <[email-masked]>
Date: Sat, 21 May 2005 23:13:26 -0700

I was trying to describe a compromise approach. I can't make any sense of
what you are trying to say below, but as I said, it doesn't much matter. We
can support both formulations, a stable canonical form and an unstable (pick
latest) one, the one you want.

‎Mark