Re: Language tags (Re: Statistics on reusing request)

>     If you wish to register I-SIL-nnn as a standard for three-letter
>     Ethnologue-based tags, or even want to push for updating RFC 1766 to
>     include S-nnn as a new category, I would not argue against that, but
>     I would like to stick to the principle of using ISO standards for
>     the basic namespace.

If there's even the slightest chance that multiple three letter code schemes
will exist in the future then the S-nnn approach seems like the way to go to
me.

> Since IANA does not otherwise use such a principle I don't know why you
> would adopt it here, let alone insist on it.

Incorrect. IANA does use such a principle elsewhere: In handling the
registration of top-level domains it follows ISO country codes. There was a lot
of wailing about this policy at one point but as far as I know it has never
been changed.

>     Otherwise, we will end up with a really confusing situation once the
>     ISO 3166 three-letter project finishes (if it ever does); its tags are
>     SURE to conflict with the SIL tag.

> Even more incongruent does your "principle" appear given the laggardness
> of this particular ISO work item.  It is extremely unlikely that ISO or
> anyone else for that matter will do as comprehensive a job as SIL has done
> in creating their language database.

The problem as I see it is the adoption of a different set of criteria for
language tags here than what was used in the content-language work. I for one
don't especially care what we use as long as it is the same everywhere. I do
NOT want to have two different language tag namespaces to contend with. In fact
I'm not particularly happy with the notion of having overlapping subspaces, but
I think that's inevitable.

> I was rather surprised to learn that you did not even know about the
> Ethnologue database prior to writing your RFC.  Let's just forget about 3166
> and use what exists, namely 639 for 2 letter codes and the Ethnologue for
> three letter codes.  Unless you can give a firm estimate of when (or if)
> ISO is going to actually produce a revision to 639, then your objection
> surely sounds quite empty to me.

You may not approve of it, but we have a proposed standard for language tags in
place -- RFC1766. And this is what HTTP needs to use. Defining another scheme
specifically for HTTP is not acceptable.

Now, it may well be that RFC1766 is broken. If it is then we need to fix it.
Its almost time for it to be up for review anyhow. It may be somewhat harder to
fix RFC1766 than to invent an incompatible scheme for HTTP, but the difficulty
of the task should not prevent us from doing the right thing.

In summary, the only thing here that "sounds empty" to me is the notion that
its acceptable to have two different sets of language tags in different IETF
work items and that its acceptable avoid revising documents that need revision.
Glenn may have an excellent case for putting the SIL codes in RFC1766. He may
even have a case for putting the SIL codes in without an "S-" introducer and
putting the introducer on the son-of-639 codes should they ever appear. If so,
he needs to bring this up with the WG that produced the content-language
specification -- the MAILEXT WG, I believe.

In fact it may even be possible to revise the tags specification and get a new
version of it out before the work on HTTP is finished. The MAILEXT WG has a
proven track record of getting more work done faster than any other group I've
been associated with.

				Ned

Received on Thursday, 2 November 1995 17:42:05 UTC