Re: Responsive vendors and their implications (was de-facto 8 bit

[Nathaniel Borenstein <nsb@xxxxxxxxxxxxxxxxxxxx>]

Excerpts from internet.ietf-smtp: 25-Feb-91 Re: Responsive vendors and
.. Erik Naggum@naggum.uu.no (3922)

> IF we mandate that we are not going to expand the data path of SMTP to
> 8 bits, THEN the UA's will have to change to understand encoded 8-bit
> as meaningful 8-bit data.  I contend that this is not going to happen.

It will happen to some, and not to others.  In particular, with an
approach such as I've proposed under the name "metamail," all that has
to happen is that each UA gets a small change that causes it to run the
metamail program for unrecognized content-types.  Metamail is configured
(by mailcap files) to execute  a viewer/interpreter for a certain set of
content-types.  If you want encoded 8-bit data to be meaningful, all you
need is a viewer/interpreter that understands it.  As far as I can tell,
this is made neither harder nor easier by encoding the data in 7 bit
form.

> IF we go for the New Mail paradigm of multi-media, multi-body-part
> messages, THEN UA's will have to change to understand the encoded stuff.
> I contend that this is most certainly going to happen.

Again, the point is that with the metamail approach, the only UA changes
that are really necessary are totally minimal.  In particular, UA's
won't have to "understand" any particular encoding, merely to recognize
encodings that they don't understand and pass them off to metamail or
something like it.

> 8-bit text and multi-foo are two separate issues.  Even if lovers of
> the multi-media stuff think they can do it with 7-bit data path (and I
> agree with that position), they SHOULD NOT IGNORE 8-BIT TEXT PROBLEMS.

I agree with this completely.  Right now, for example, Andrew lets you
send around 8 bit ISO characters, using its own idiosyncratic 7 bit
encoding.  If 8 bits were available, it would have been a tad easier.  I
just want to decouple the problems and tackle the one I consider most
important first, as my previous message suggested.

> IF we're going to talk to users on the same system, or across the
> street, or city, or mountain range, with some damn encoded 7-bit stuff
> to represent our ISO 8859-1 characters, IT IS NOT GOING TO BE USED.
> People are using ISO 646 + national variants today, and that works,
> albeit not perfectly.  Any encoding scheme into and out of 7-bit for
> 8-bit characters is going to look MORE UGLY, MORE STUPID than it does
> to read text with national variants on ASCII displays.  It requires
> MORE NEW SOFTWARE to handle random 7-bit encoding than to handle full
> 8-bit data paths.

Well, I don't know about this.  Predicting what will and won't be used
is a very risky business.  I think the encoding can be made moderately
readable, and the UA patches extremely simple, and the combination of
the two may make an encoding pretty well acceptable, but I'll admit
there's not much evidence to go on about what people will & won't
tolerate.

> IF the IETF is not going to come to terms with the need for an 8-bit
> clean STMP mail path, people are going to go the brutal and rude way
> that Robert Ullmann has proposed.  I'm beginning to understand why.
> Sooner or later, we're going to have camps of SMTP servers who do
> accept and send 8-bit data, simply because of local user needs.

This is quite probably true.  It's more of a political argument than a
technicalone, but I think it's probably the best reason I've heard for
not resisting an attempt to extend SMTP to 8 bits, provided it is
properly decoupled from (but cooperative with) the effort to provide
multipart 7-bit mail.