Re: Communicator Unicode

From: Kent Karlsson (keka@im.se)
Date: Thu Sep 25 1997 - 05:41:12 EDT


Alain LaBonté - SCT wrote:
> While in an ideal bugless world, you're perfectly right, encoding à la RFC
> 1522 is a nightmare for users, a way paved with myriads of ubiquitous and
> unsolvable coding and decoding bugs.
>
> And perpetuating the dogma that without tags, the non-English user should
> go to hell (the impression that hopeless users get), nobody will be able to
> convince him/her that good engineering which leads to garbage out is nice
> for their mental and physical health.

Being the one starting this sub(!)thread, I sense the temperature
rising. And I don't know if I can bring it down, especially since
I agree with what Alain says in the two paragraphs quoted above.

However, I would like a simple and universal solution that is also
sane from an engineering point of view.

Martin J. Dürst wrote:
> But maybe time is ripe
> for at least a proposal to remove this restriction. News headers
> are also moving in this direction. Ideally, and in accordance
> with the newly formulated IETF charset policy, one shouldn't
> go to use =?charset?R?XXXXXXXX?= (where "R" would stand for
> raw), but should declare that (within "cooperating subnets"),
> UTF-8 is directly used. Using anything else in headers without
> being labeled (as it is unfortunately done is some areas) greatly
> affects generality, interoperability and future extensibility.

*Without* charset/transf.enc. tags (?...?.?), headings are to be coded
using UTF-8 with 8bit transfer encoding. This would be suitable when
using ESMTP, and would simplify decoding since no charset/transf.enc.
tags anywhere need be processed for displaying a "one-liner", in a
messages summary, for the message.

If the sending user suspects that the transmission might not be 8bit
(ESMTP) all the way, the sending user (not any part of the system,
nor any gateway!) should still be given the (non-default!) possibility
to use charset tagging and Q-P or Base64 transf. enc. Note: this would
be a fallback only.

Also, text parts of message bodies should have the default
charset/transf.enc. of UTF-8/8bit.

                        /kent k




This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:37 EDT