Rhys writes:
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.
No, we shouldn't get into that. It's for more sophisticated
systems like TEI.
To your three practical uses for language information,
(1) choose best body part if several langauges are offered
(2) choose best fonts for display
(3) choose best speech synthesis unit,
I would like to add
(4) suppress display/playback of messages in incomprehensible langauges
(5) prioritize messages when you receive to much mail or netnews
(6) choose best hyphenation rules when reformatting text for new
font or window width.
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.
This was actually done in the rejected ISO CD 639-2. It had
these historically defined language codes, among others:
ang English, Old (ca. 450-1100)
enm English, Middle (1100-1500)
eng English
goh German, Old High (ca. 750-1050)
gmh German, Middle High (ca. 1050-1500)
ger German
(but, strangely enough, no codes for Low German)
It also included more exact dating of languages:
grc Greek, Ancient (to 1453)
gre Greek, Modern (1453-)
(the margin of uncertainty reduced to 1 year, obviously)
/Olle