Re: Fwd: I-D ACTION:draft-goldsmith-utf7-01.txt

["Martin J. Duerst" <mduerst@ifi.unizh.ch>]

On Thu, 6 Feb 1997, Dan Oscarsson wrote:
 
> > > UTF-7 would work very nice with 8-bit transports, for example when sending
> > > e-mail and using charset=iso-8859-1; content-transfer-encoding=8bit
> > > allowing all 8-bits to be used giving an easy to read text of the
> > > 8bit character set and still allowing all UCS-2 characters to be used.
> > > 
> > > Most 8-bit character sets should be able to use it allowing them to
> > > still be readable and compact without removing the possiblity to include
> > > all UCS-2 characters. Is like if we had an UTF-8 that did not destroy
> > > the 8-bit character set in use.
> > 
> > This may sound like a good idea, but probably isn't. The main problem
> > is that you would need "charset" tags of the form iso-8859-1-utf-7
> > and so on. We already have way too much different character encodings,
> > so let's not create more without really strong needs.
> > 
> 
> Actually UTF-7 for me is much more a content-encoding than
> a character set. And could be used for other character sets than UCS.

It looks like this to many people. But it is in no way intended
to be a content-encoding. Just look at what the accronym means:
UCS Transfer Format, where UCS is Universal Character Set.
The same applies for UTF-8 and UTF-16.


> But even if is is restricted to UCS is would work fine to use:
> 
> Content-Type: text/plain; charset=UTF-7
> Content-Transfer-Encoding: 8bit
> 
> 
> and only encode characters that can not be represented by 8 bits.

Would work fine, eh? Who's going to figure out what the 8-bit
characters are, and how? And then also something like
	Content-Type: text/plain; charset=iso-2022-jp
	Content-Transfer-Encoding: 8bit
would have to mean something (because iso-2022-jp is a pure
7-bit encoding). Very strange indeed!

Regards,	Martin.