Re: A spec for showing language in MIME headers

Olle Jarnefors <> Thu, 11 November 1993 21:20 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa08245; 11 Nov 93 16:20 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08241; 11 Nov 93 16:20 EST
Received: from by CNRI.Reston.VA.US id aa19389; 11 Nov 93 16:20 EST
Received: by (5.59/SMI4.0/RU1.5/3.08) id AA11847; Thu, 11 Nov 93 15:05:40 EST
Received: from by (5.59/SMI4.0/RU1.5/3.08) id AA11843; Thu, 11 Nov 93 15:05:39 EST
Received: from by (5.65+bind 1.8+ida 1.4.2/4.0b) id AA10786; Thu, 11 Nov 93 21:05:38 +0100
Received: by (5.65+bind 1.8+ida 1.4.2/4.0) id AA27799; Thu, 11 Nov 93 21:05:33 +0100
Date: Thu, 11 Nov 93 21:05:33 +0100
Message-Id: <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Olle Jarnefors <>
Cc:, Olle Jarnefors <>
In-Reply-To: <> (Tue, 9 Nov 93 21:27:28 JST; From: Masataka Ohta <>)
Subject: Re: A spec for showing language in MIME headers

Ohta-san writes:

> As the CJK disambiguation is necessary word-by-word (don't forget that
> Harald proposes to handle multi-lingual document) and in header part,
> and the disambiguation is necessary only for the specific character
> set: ISO10646/UNICODE, language tag is not a good mechanism for the
> disambiguation. It's better to use ISO10646/UNICODE with the
> charset names "iso-10646-<language tag>" for single language only.

I fail to see why

   Content-Type: Text/Plain; charset=iso-10646-chinese

would solve the problem of word-by-word distinction between
Chinese and Japanese in a multi-lingual text any better than

   Content-Type: Text/Plain; charset=iso-10646
   Content-Language: zh (Chinese)

Neither of them does, I think, and the latter approach seems
cleaner to me, as it doesn't confuse language with coded
character set.

We can't expect _plain text_ to support

a) high-quality rendering of text mixing Chinese and Japanese
   ideographic characters

no more than we expect plain text to preserve the distinctions

b) normal and italicized text

c) a Black-letter or Fraktur font for German words and a Roman
   font for French words in a bilingual pre-WW2 text

d) the correct glyph for the character A with diaeresis in a
   Swedish word and the correct glyph for the same character in
   a German word

e) the correct choice between "ff" and the <ff> ligature in
   different German words.

All these needs a - e can be easily satisfied, however, by a
suitable _rich text_ representation. This could e.g. provide not
only <italic> and </italic>, but also such tags as
<fraktur>...</fraktur>, <lang-zh>...</lang-zh>,

Why should properties like these not be encoded on the basic
plain text level? Because they are not necessary for conveying
the _meaning_ of the text to a human reader (except in extreme