Subject: re: 8-bit characters in the header.

From: Laurie Cuthbert <[email-masked]>
Date: Tue, 8 Feb 1994 08:03:21 GMT

I must say I agree with Mark. I'm quite happy to write "pds" (or even "UK pds") 
instead of the pound symbol as I know that character may not display as 
intended; also to address one of my German colleagues as Guenther to avoid the  
                                                         ^^
u-umlaut. 

The whole point about communication is that we should be certain that it can be 
read reliably at the other end wherever that may be, and the only sure way to do 
that is to use the lowest common denominator - as Mark says, a subset of 7-bit 
ASCII. It would be much worse to have to think about what sort of alphabet the 
other end might be using before composing a message.

Regards

Laurie Cuthbert

On Mon, 7 Feb 1994 14:35:00 -0800 (PST) Mark Crispin wrote:

> From: Mark Crispin
> Date: Mon, 7 Feb 1994 14:35:00 -0800 (PST)
> Subject: re: 8-bit characters in the header.
> To: Barry Landy <[email-masked]>
> Cc: Klaus Zeuge <[email-masked]>, [email-masked],
>      [email-masked], [email-masked]
> 
> Barry -
> 
>      It is important to understand that when one waves the banner of
> ``linguistic and cultural fascism'' one should be sure that one's own house is
> in order.  8859 is not universal.  It is a regional character set.  It may be
> recognized outside that region.  But -- and this is important -- there are
> other regional character sets, and they use an overlapping space with 8859.
> 
>      I doubt very much that EDCfB@O: displays as anything sensible on your
> terminal, yet that is a standard representation of a person's name in that
> person's language.  It's just not 8859.
> 
>      This is not a simple problem to solve.  If it were simple, we would have
> solved it by now!
> 
>       Americans are not immune from the problem either; they just are closer
> to the subset and don't have to worry about losing any letters.  Backslash is
> yen-sign in Japan.  Sharp-sign is the British currency symbol in the UK.
> Dollar sign, at-sign, and other familiar characters (to us) are also different
> in various national variants of ASCII.
> 
>      In other words, the lingua franca of Internet email is a *subset* of 7bit
> ASCII.  To be safe, you have to stay within that subset unless you are
> communicating within your region.  Even after Pine supports RFC-1522 header
> encoding, it'll still be advisable to have an acceptable 7bit representation
> of your name along with the 8859 version.
> 
> -- Mark --
>

---

From: Philip Hazel <[email-masked]>
Date: Tue, 8 Feb 1994 09:52:35 +0000 (GMT)

> instead of the pound symbol as I know that character may not display as 

Even within one country there are differences. I'm in the UK, but my X
terminal does not show a pound sterling symbol for ASCII character 35 - it
shows a hash (= "sharp sign").

There are standard TLAs for the world's currencies, used by banks, 
airlines, etc. I don't know if they are a formal ISO standard. Anyway, for 
pounds sterling, you should use GBP, and for U.S. dollars, USD. No doubt 
there is a list somewhere on the Internet...

--
Philip Hazel                   University Computing Service,
[email-masked]             New Museums Site, Cambridge CB2 3QG,
[email-masked]          England.  Phone: +44 223 334714

---

From: [email-masked] (Christer Lindh)
Date: Tue, 8 Feb 94 11:57:20 +0100

> The whole point about communication is that we should be certain
> that it can be read reliably at the other end wherever that may be,
> and the only sure way to do that is to use the lowest common
> denominator - as Mark says, a subset of 7-bit ASCII. 

Using a common *language* like English when communicating in a forum
like this makes total sense. All words in english use characters
available in ASCII.

But sometimes it is necessary to refer to names, places etc in
countries that use extended alphabets. And why should't people with
capable MIME-readers be able to see then "Åke Östäng"'s or some Asians
name like it was intended to be viewed, if at all possible?

And when it can't be viewed properly, the MUA should do it's best.
What's the difference beteen seeing that name as "Ake Ostang", "]ke
\st{ng", "_ke _st_ng", "Eke Vostdng" or whatever your MIME-reader
decides on showing when the charset is missing?  All of these are
obfuscations of the guys real name, equally "useless".

In this particular example the first alternative is the best
approximation and could be achieved by using mapping tables between
some character sets. There is existing code and "standard" for this
available in the public domain (forgot wo wrote it though).

But if the name was in Hebrew (8859-9?) or some Asian language it just
can't be mapped properly on a 7bit terminal. So what?  If the writer
wanted everyone on the world top see it he should supply an alternate
view (MIME supports that, does Pine?).

In earlies version Pine could map 8bit-chars in the wrong charset to
"_" or something, and that's an option the user that's afraid that odd
8bit characters in an unavailable charset may screw up the terminal,
should use. 

(BTW, are we talking about 8bit in pine-list or in general here?  Of
 course we should talk in English here but a little non-ASCII doesn't
 hurt anyone...)

A big point about MIME IMHO is that the user writing a mail shouldn't
have to worry about the capabilities of the receivers MUA.  MIME tags
everything that's in your mail and then it's up to the receivers MUA
to do whatever's appropriate.  Using ISO vs Unicode/Asian charsets are
irrelevant, a good MUA should be able to adopt new registred
MIME-charsets and types.

Pine is great in many respects but has some way to go before it
becomes a good MIME-reader for other languages, for example it should
support character mapping tables and viewing attachments in other
charsets by switching the terminals charset (for xterm for
example). The "metamail" package can do things like this.

This discussion went the wrong track somewhere; the original question
was why MIME was not supported in the header when it is so in the
message body?  These two types of encodings are described in the same
RFC. The answer was that it WILL be, and we applause that (and eagerly
wait for it).

>> in order.  8859 is not universal.  It is a regional character set.
>>
So is ASCII...

--
::       [email-masked]       ::   o/        ::                      ::
:: Abalon AB, Stockholm, Sweden ::  /@         ::        Earth.        ::
::       (MIME compliant)       ::  /!>        :: Love it or leave it. ::
::   * All disclaimers apply *  ::   !  climb! ::                      ::