🚀 go-pugleaf

In article <24424@alice.att.com> andrew@alice.att.com (Andrew Hume) writes:
>
>
>	i appear to have confused randall a tad. the UTF-2 encoding
>requires 8 bit transmission.

  Thanks.  That is OK.  If I have an enhanced SMTP, I can send 8-bits
that using enhanced SMTP way and so UTF-2 is fine.  If not, I can
encode UTF-2 using BASE64 into a 7-bit-safe transmission format and
send it over existing SMTP links while still being fully MIME
compliant either way.

>	i am puzzled why people want to do 8859-* as an intermediate step.
>it seems clear to me that if you can get the damn bits through,
>you may as well do UTF-2, particularly as there is a well-defined
>invertible mapping between 10646 and all the 8859-* character sets.

There are several explanations.  These are all pragmatic explanations,
not technical justifications:

1) There is a fairly decent sized installed base of ISO-8859-* terminals.
2) Many people don't understand that the transmission encoding and 
   the presentation encodings only need to be convertible and do not 
   necessarily have to be identical.
3) ISO-10646 was not finished when MIME finished and ISO-10646 had failed to
   be passed once already and it wasn't clear how long it would take for
   ISO to finish it.  Under IETF/IESG rules, an RFC can only cite existing
   works not "works in progress" such as a pending ISO standard that has
   not been approved.  There was desire not to have MIME publication be
   dependent on ISO getting their act together.  NB: When MIME progresses
   towards full-standard status, I fully expect ISO-10646 to be specifically
   cited and its use to be encouraged.

ASIDE:
   I wish Microsoft had thought about this as much as you all 
at Bell Labs did.  It would be better if everyone used UTF-2 (IMHO).

Ran
atkinson@itd.nrl.navy.mil