ietf-822
[Top] [All Lists]

Re: A spec for showing language in MIME headers

1993-11-09 18:23:10
Just as an aside, the UofMn English Dept. already offers courses that 
deal with various markup languages and how they can be used in terms of
preservation of texts, production of new texts, etc etc. The people involved
with that work would love to be able to send e-mail in 16th century English
to each other. I'd be willing to bet money on that.

The question as I see it has become: are they going to use their
domain-specific markup languages to send text, or do they want to send
it in text/plain?  Nothing is stopping them defining a "text/old-english"
content type for their particular markup styles, in which case the
language information will be internal to the document, rather than sent
in the Content-Language header.

The Content-Language header was initially presented as a way to choose the
best body part to display to the user, the best fonts to use, or the best
speech synthesis unit to use for sight-impaired people.  If we start getting
into date stamping and linguistic information, our MIME software is going to
be much more complex, for something that already has existing domain-specific
solutions that the IETF parties aren't experts in.

If on the other hand, ISO saw fit to register an "eno" (English Old) language
tag, then text/plain could be used.  The point is that it becomes ISO's
problem to define exactly what range of dates "eno" (and even "en") actually
means: IETF is off the hook.

Masataka seems worried that the "en" of today may bear very little resemblance
to the "en" of 200 years from now, and so old messages in archives may be
interpreted as the future "en" rather than the "old" one.  He also seems
worried that something like "ru-su" becoming "ru-ru" overnight may cause the
net to disintegrate.  I'm unconvinced at the moment that this is a problem
that the IETF needs to solve.  Usage of tags, just as usage of languages,
will evolve over time, and it is not up to the IETF to say how they can evolve.

I _would_ support making the country code into something that should be used
only if it is absolutely necessary to disambiguate different usages of the
same language.  e.g. French and French-Canadian which have different
capitalisation rules I believe.  Hence, Russian would be "ru" and English
would be "en", no matter what country, unless it is absolutely necessary
that the recipient hear it with a Ukrainian ("ru-ua") or an Australian
("en-au") accent respectively.

Cheers,

Rhys.