From someone who has been sitting on the fence a little bit here, I
think Erik's recent note has focused my thinking. For whatever it is
worth...
Yes. There are at least two issues here. One is the type of tag,
i.e. language tagging or font tagging. Font tagging can be further
subdivided into specific, e.g. Ryumin Light, and less specific, e.g.
Japanese (as Masataka has been suggesting).
The other issue is whether to do the tagging at the body-part level,
e.g. in the charset parameter, or within the body-part, e.g. the way
"richtext" does <bold>, <italic>, etc.
I would argue that "font tagging" is a markup matter, to be pushed into
richtext (at least) and probably to SGML and similar applications. It
has little or no place in plain text mail.
If that is true, then the critical question is whether language tagging
(at body-part level) provides enough information to be worth the
trouble, or whether that should be forced into markup ("within
body-part") as well.
I think we have seen very convincing arguments that senders providing
this type of information to receiving UAs is likely to be desirable in
many cases. I don't think we have seen an adequately strong argument
for requiring it, i.e., including it as profile information in the
charset name, although we have gotten close.
No, the sender should not be encouraged to include font info. The
sender should be reminded of the fact that the receiver may have a
preferred way of looking at the text. The sender should be told that
font info is allowed, but not always desirable. (My opinion.)
I think this reads a bit differently when "character set" is substituted
for "font". We should encourage, but not require, the sender to supply
language info. We should provide a standard way for it to do so. We
should encourage receivers to pay attention to that information when it
is supplied and meaningful, but not require that either.
And I think we should accept the fact that sender-specified rendering
of multilanguage text or text in which either font presentation or page
layout are important to understanding is going to require medium (e.g.,
richtext)- to- heavyweight (e.g., SGML) markup or page description
languages to transmit reliably and are hence, not part of the text/plain
story.
Anyone for Content-Language: ? Would that, with the "not required, but
encouraged when it is important" solve enough of this problem that we
can get on with our lives?
--john
p.s. If we decide to pursue this (or, for that matter, something of the
10646-lang1-and-lang2 flavor), please note that there is an ISO
standard, IS 639, which specifies codes for all (or most) of the world's
languages. It could permit a certain amount of definition-by-reference,
rather than having to invent our own rules. And, unlike the character
set standards and even IS 3166 (the country name codes), IS 639 is old,
settled, and very stable.