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

[Bruce Lilly]

>  Date: 2004-12-11 11:59
>  From: "JFC (Jefsey) Morfin" <jefsey at jefsey.com>
>  To: ietf-languages at alvestrand.no, ietf at ietf.org
>  
> Gentlemen,
> I see several points discussed here which are/are not of the same order and 
> seem confusing the issue.
> 
> 1. the discussion creeps from Harald's RFC 3066 to Multilingual Internet. 
> It seems strange to discuss byte oriented details without having first a 
> Multilingual framework telling what is the scope of the discussion and its 
> implications (which are certainly major) on the whole Internet 
> architecture. I submit that an IAB guidance is first necessary. Before 
> going any further a true WG-Multilingualism should be created and open to 
> everyone (a private IETF-Language lists should be an interim situation 
> towards such a WG)

There is in fact an "ietf-languages" list; RFC 3066 and the
draft under discussion give its submission mailbox as
"ietf-languages at iana.org", which makes finding the real
list an exercise since IANA's web site makes no mention
of any mailing lists.  I made an educated guess that I
might find the list at alvestrand.no, and indeed the
list submission mailbox is "ietf-languages at alvestrand.no",
and the list archive is available at
http://www.alvestrand.no/mailman/listinfo/ietf-languages

Neither RFC 3066 nor the draft provide any instruction
for joining the mailing list, and from the remarks above
it should be clear that IANA's web site provides no clear
clue either.
 
> 2. I see quoted "RFC 3066bis" as a document. The RFC Editor seems to ignore 
> that RFC? Where can I find it?

It is apparently an unofficial term for the Phillips draft
mentioned in the new last call and to which you have
repeated the URI.
 
> 3. there are at least four different levels:
> 
> - what is Multilingualism vs. vernacularism (there are 6000 human languages 
> but a standard should be able to support non scripted and computer 
> generated and past languages, what may lead to millions of references).

One should then consider different types of tags for
different uses -- a tag for a non-scripted language
makes no sense in an RFC 2047/2231 encoded-word,
which is strictly text.
 
> - vernacular granularity has nothing to do with geography and countries. 

True in general; but can we reverse the precedent
set by RFC 1766?

> The way this inserts into the general digital convergence (is the IANA the 
> proper register?).
[...]
> The same as the IANA is not in the business of defining 
> countries (Jon Postel, RFC 1591) it should not be in the business of 
> defining languages.

The draft in question apparently seeks to get IANA into the
business of defining countries (and languages), usurping
those roles from ISO (as also noted in RFC 1591).

> I also submit that IANA is not the proper place anymore to support such a 
> Register. Experience shown that IANA (now a function of ICANN) is subject 
> to controversies in this or in parallel real life areas: ccTLD delegation, 
> ccTLD entries in the root file, accepted MINC reaction to the Polish non 
> concerted introduction of Arabic, Russian and Hebraic tables, ICANN 
> strategy for internationalized rather than multilingual TLDs, etc. I also 
> submit that UNESCO, MPEG or other standard/cultural organizations involved 
> in the daily reality (universities, editors, posts, governments, 
> copyrights, WIPO, etc. etc.) are more concerned and may make their own 
> standard prevail after an unnecessary and harassing dispute. It seems that 
> any semantic able to support open sub-tags whatever they originate from, is 
> useful. Going any further would push in favor of a less and less 
> [unilingual or internationalized] network centric market against a 
> market  evolution toward user centric [multilingual/multiulcural] networked 
> relations [P2P, VoIP, NAT, coreboxes, OPES, etc.].

Good points all, though I do sympathize with the concern about
loss of information about what a tag meant at a given time
due to changes in the ISO lists.  I would support provision for
a definitive time-stamped registry of changes of some sort;
ideally that would be provided by ISO as part of (or a supplement
to) the lists, and I would be quite surprised if ISO were not
receptive to such a suggestion if made appropriately and with
a clear indication of the problems.