Date: 2004-12-11 11:59
From: "JFC (Jefsey) Morfin" <jefsey(_at_)jefsey(_dot_)com>
To: ietf-languages(_at_)alvestrand(_dot_)no, ietf(_at_)ietf(_dot_)org
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(_dot_)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(_dot_)no",
and the list archive is available at
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
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
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
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.
Ietf mailing list