RE: UTF-7 and java

Chris,

> -----Original Message-----
> From: www-international-request@w3.org
> [mailto:www-international-request@w3.org]On Behalf Of Barry Caplan
> Sent: Tuesday, August 28, 2001 7:46 AM
> To: www-international@w3.org
> Subject: Re: UTF-7 and java
>
>
> At 03:53 PM 8/28/2001 +0200, Chris Lilley wrote:
> >No, the solution to that is to obselete the anachronistic RFC that
> >allows 7bit gateways.
> >
> >Then images, sounds, etc do not need to be specially processed.
> >
> >--
> >Chris
>
>
> Well of course. But practically speaking, how would you propose
> to do such
> a thing?
>
> Anyway as Martin mentioned, it is not really a char encoding
> issue because
> the SMTP servers at both ends will take care of converting to 7 bit via
> base64 encoding and/or quoted-printable.
>

This is not true.  For example look at iso-2022.  This code page exists
because it is 7 bit clean.  It is much more efficient than base64 encoding.
It is a mess to process and many of use would like to see it die a horrible
death.  This is because if RFC 821.  The SMTP transports do not deal with
IS0-2022 but your application does.

It is mostly because they can not be sure that the last 7 bit modem is not
still out there some where.  Quote from RFC 1341:

"Several of the mechanisms described in this document may seem somewhat
strange or even baroque at first reading. It is important to note that
compatibility with existing standards AND robustness across existing
practice were two of the highest priorities of the working group that
developed this document. In particular, compatibility was always favored
over elegance. "

Meaning forget any changes that are not backwardly compatible (support 7
bit).

Carl

Received on Tuesday, 28 August 2001 11:47:05 UTC