Subject: RE: [Ltru] Re: Last call comments on LTRU registry and initialization documents

From: "Addison Phillips" <[email-masked]>
Date: Fri, 9 Sep 2005 09:42:17 -0700

The draft does not include any of the overlapping codes on purpose. This is conformant with both RFC 3066 Section 2.2 and draft-registry Section 2.2.1, which both mandate that, where ISO 639-1 (alpha2) and ISO 639-2 (alpha3) codes exist, only the ISO 639-1 codes be used. The registry contains only subtags that are valid in language tags.

I know I'm going to regret asking, but why would the IESG need approval from Michael Everson to tell IANA to publish a registry? They appoint him, after all.

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
> r&d afrac
> Sent: Friday, September 09, 2005 9:32 AM
> To: Doug Ewell; John C Klensin; Sam Hartman
> Cc: [email-masked]; [email-masked]
> Subject: [Ltru] Re: Last call comments on LTRU registry and initialization
> documents
> 
> The problem with your Draft is that you do not include the 3 letters
> version of the 2 letter version as a correlative information between
> ISO 639-2 and ISO 639-3 tables. I do not think should be left to the
> Editor. Otherwise your Draft seems no problem. But I suppose that
> IESG would need a formal OK from Michael Everson since he is charge
> of [email-masked].
> jfc
> 
> At 17:07 09/09/2005, Doug Ewell wrote:
> >John C Klensin <john dash ietf at jck dot com> wrote:
> >
> > > The success or failure of the "foo" registry is
> > > not evaluated on how many foos we can put in to it, or its
> > > comprehensiveness relative to some external foo-list, but on
> > > whether it does the job that the foo-protocol (and maybe foo1,
> > > foo2, etc.), requires.  Normally, we don't even write a "create
> > > the baz registry" document.  Instead, we write a "baz protocol
> > > specification" document and include a more or less long section
> > > that instructs IANA to create the registry, what to put in it,
> > > and how.
> >
> >So, do you propose that we withdraw the specification of the initial
> >registry contents, all 963 tags and subtags, and replace it with a set
> >of instructions to IAN on how they can duplicate our work?  And cross
> >our fingers that they get it right, or prepare to go through
> >item-languages for any correctible errors or omissions they may
> >introduce, and live with the uncorrectable errors?  Just wondering.
> >
> >--
> >Doug Ewell
> >Fullerton, California
> >http://users.adelphia.net/~dewell/
> >
> >
> >
> >_______________________________________________
> >Ietf mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> _______________________________________________
> 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: "Addison Phillips" <[email-masked]>
Date: Fri, 9 Sep 2005 14:15:26 -0700

Hi John,

Thanks for your note back. First I'll respond to a trivial item and then, separately, to the STD/BCP question.

You wrote:
> (ii)
> The idea of using a registry of components (in this case
> subtags) that can be mixed and matched at the implementer's
> discretion, albeit according to specific rules, is somewhat
> untested in the IETF and the Internet applications community.

Perhaps true in most respects, but not with regard to RFC 3066!

RFC 3066 allows specific tag registration, yes, but it also includes a generative syntax (albeit not identified formally as such).

Thus the concern you have about people doing subtag mix-and-match already exists in RFC 3066 (as I'm sure you're aware) and the community has ample experience with that. Here are some perfectly valid RFC 3066 tags that are silly or at least dubious and also not registered:

  tlh-AQ (Klingon as used in the Antarctic)
  it-SG (Italian as used in Singapore)
  zh-CO (Chinese as used in Columbia)
  ang-TL (Old English as used in Timor Leste)
  cs-CS  (Czech as used in Serbia and Montenegro)

So... RFC 3066 has already tested the idea thoroughly and we are just dancing in the margins (he says, squinting VERY hard to ignore obvious questions of order of magnitude). 

Addison

Addison P. Phillips

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 9 Sep 2005 14:50:39 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> don't know why my spell checker corrected "uncorrectible"
>> to "uncorrectable" but left "correctible" uncorrected.
>
> Did you test en-AQ-1996 ?  <gd&r>

My spell checker said:

    Huh?

My RFC 3066bis tag validator said:

    Well-formed: (green light)
    Tag is well-formed

    Valid:  (yellow light)
    Tag is valid but contains non-preferred subtags or non-recommended
    combinations

    Subtag 1: en
    Language subtag: English (registered 2005-08-16)

    Subtag 2: AQ
    Region subtag: Antarctica (registered 2005-08-16)

    Subtag 3: 1996
    Variant subtag: German orthography of 1996 (registered 2005-08-16)
    Recommended prefix is de

Or course, the dates are wrong because nothing is truly "registered"
yet.

---

From: r&d afrac <[email-masked]>
Date: Sat, 10 Sep 2005 04:47:42 +0200

At 18:42 09/09/2005, Addison Phillips wrote:
>The draft does not include any of the overlapping codes on purpose. 
>This is conformant with both RFC 3066 Section 2.2 and draft-registry 
>Section 2.2.1, which both mandate that, where ISO 639-1 (alpha2) and 
>ISO 639-2 (alpha3) codes exist, only the ISO 639-1 codes be used. 
>The registry contains only subtags that are valid in language tags.

This is not what I ask. I say that the registered subtags should 
mention their standardised equivalence in other ISO tables. The 
proposed information is of no help when my application already uses 
an ISO 639-2 (or ISO 639-3) since I have no indication to convert it. 
However, if you do not provide it, we will provide it : it will make 
some advertising to our langroot.

>I know I'm going to regret asking, but why would the IESG need 
>approval from Michael Everson to tell IANA to publish a registry? 
>They appoint him, after all.

I am afraid you might know many things wrong.

The IESG needs approval from Michael _because_ they appointed him to 
that end.  Unless you want to fire him? The Charter explicitely says:

"This working group will not take over the existing review function 
of the ietf-languages list. The ietf-languages list will continue to 
review tags according to RFC 3066 until the first document produced 
by the WG is approved by the IESG for publication as an RFC. Then it 
will review according to whatever procedures the first document specifies."

1) your Draft says that a batch registration is to be made. This is 
part of the new procedures: the Charters say it is to be reviewed.
2) Michael will review subtags the same as today, there is no special 
difference between what is in the Draft and what he is to approve.
2) only Michael has been appointed by the IESG to be "IETF 
authoritative" about the rightness of the Draft. How can we know 
otherwise he has no legitimate IETF opposition or there is no error 
since he is not on this list (he said it).

Actually I am wrong: the whole Draft should be reviewed by 
[email-masked] and _then_ Michael should approve it. 
How do you want them to work on something they did not agree.

To make sure Michael is consulted, is also a simple polite courtesy for us
jfc

---

From: "Addison Phillips" <[email-masked]>
Date: Sat, 10 Sep 2005 13:30:34 -0700

The problem I have with going to the STD track has nothing to do with the process of progressing as a standard. The IESG will decide which track to go down and either track suits me fine... provided...

Draft-registry is actually, despite the appearance of being very different, very much a particular profile of RFC 3066. Its grammar could be pasted into RFC 3066 with no ill effect, since all generative or registered tags extant today follow it. The creation of a central registry to mirror the many external standards (and rules for choosing among them) also has no deleterious effect on implementations because the registry accurately mirrors the rules for tag choice in RFC 3066.

There are two problems, though, that must be solved if we are to go down the STD path.

1. Is draft-registry "Obsoletes: 3066"?

Many standards, protocols, and formats reference something called "RFC 3066 or its successor". Thus the question of whether draft-registry is 3066's successor is important to those standards, protocols, and formats. I have no problem with BCP 47 being replaced with STD xyz, but everyone will be curious about what to do if we have both BCP 47 and STD xyz.

2. When does the registry replace the existing IANA registry?

I don't see how the two language tag registration schemes can coexist peacefully. Even if draft-registry is not RFC 3066's successor, there has to be some consideration for interoperability between the two.

Thus, I think that, if we go down the STD track for whatever reason, these two questions need to be clarified quickly and clearly so that implementers and content taggers can made good, informed choices.

I look forward to the IESG's deliberations.

Addison

Addison P. Phillips

> From: John C Klensin [mailto:[email-masked]]
> Sent: Friday, September 09, 2005 11:15 AM
> To: Addison Phillips; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Ltru] Last call comments on LTRU registry and initialization
> documents
> 
> 
> 
> --On Wednesday, 07 September, 2005 12:19 -0700 Addison Phillips
> <[email-masked]> wrote:
> 
> >> Comments on draft-ietf-ltru-registry and
> >> draft-ietf-ltru-initial and, secondarily, on
> >> draft-ietf-ltru-matching...
> >
> > I've thought a lot about the excellent analysis and comments
> > in John Klensin's message. My perception is that we have a
> > divergent view of the structure and significance of the LTRU
> > draft(s).
> 
> First, my thanks for the obviously careful reading and thought.
> We may indeed have divergent views, although, after reading your
> notes I believe that, in practical terms, we are pretty close
> together.
> ...... <snip to end>