New Last Call: 'Tags for Identifying Languages' to BCP

Doug Ewell dewell at
Tue Dec 21 15:39:37 CET 2004

JFC (Jefsey) Morfin <jefsey at jefsey dot com> wrote:

>> This is a filibuster, an attempt to stall RFC 3066bis out of
>> existence.
> I do resent you saying this.
> I do not object at all to "RFC 3066bis". Any effort which may help
> multilingualism and evade from hierarchical concepts is good to me.

I think you will find, upon re-reading, that I was accusing Bruce of
trying to stall, and using your points about "procedure" to bolster his
argument.  That is not the same as saying *you* are trying to stall.
However, you did write on 2004-12-11:

"I therefore submit that we forget byte oriented details for the time
being, keep this proposition as a draft and use it to open a dialog with
the WGIG over who should to what with who. We can certainly wait one
year more to have a globally accepted approach which will save every one
a huge amount of time and money."

which certainly sounds like an objection to the draft as it stands.

> RFC 3066bis belongs to a 2nd generation network centric (catenet/
> internet) logic I have difficulties with because by nature it does not
> address all my 3rd generation user centric demands. I only document
> and discuss them. But these problems are with the network vision, NOT
> with the improvement of the tools supporting one of these visions.

It is a certainty that RFC 3066bis will not address every possible user
need, or networking vision.  It isn't meant to do that.  It's an
evolutionary upgrade to RFC 3066.

> I would certainly revisit some aspects - the most important one being
> the ISO-639-2 priorty rather than ISO-639-3 only. But this is a logic
> idea in an hierachical/network centric network vision and it is an RFC
> 3066 choice which is broadly in use however confusing it may be in
> "-0z" character set.

ISO 639-3 is not yet an approved standard.  We can't base an RFC on it.
The same problem applied to ISO 15924 for years, until it was finally
approved last year.

However, you should take note of the "extended language" or "extlang"
subtag mechanism in RFC 3066bis.  It exists specifically to allow for
the possibility of using ISO 639-3 codes when that standard does go
live.  Exactly how it will be used is still not determined, but ISO
639-3 has not been overlooked.

I don't know what you mean by the "-0z" character set.

> Another is about the documentation of the character sets.

I don't think RFC 3066bis has anything to do with character sets, unless
you are talking about the limitation that descriptions be in ASCII.  I
am not sure that limitation needs to exist in 2004, but it should not be
considered a showstopper.

> Last, I am not eager for any centralized repository, I think the W3C
> has documented the semantic web enough (even if I would need far more
> time just to assemble all its documents in one reference book) for us
> to conceive more modern, comprehensive and reliable solutions.

RFC 3066bis is not just about "documenting the semantic web."  Many uses
of language tagging have nothing to do with the WWW.  And the RFC
3066bis registry is not really a new thing; it is an upgrade and
remodeling of the IANA Language Tag Registry which was institute by RFC

You might want to share some of your ideas for "more modern,
comprehensive and reliable solutions" to the problem of language
tagging.  They might help when it is truly time for a revolutionary

> But these are NOT reasons to delay a bis to the RFC 3066. Only to
> review the general perspective of the RFC 3066 and the support of
> multilingualism which are not the intent of the proposed text.

I am glad this is your position.

-Doug Ewell
 Fullerton, California

More information about the Ietf-languages mailing list