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

[Erik Naggum <erik@xxxxxxxxxxxx>]

> This argument would make sense if there were any reason for the UA's to
> change, period.  The point is, however, that if you change SMTP, all
> MTA's MUST change.  If you change RFC 822, UA's don't need to change
> unless their users are actually going to be exchanging multimedia mail. 
> In other words, you don't have to change the whole world to make it
> start working properly for the people who are playing the new game.

> If changing every UA were necessary for the only-change-822 scheme, then
> changing 821 would indeed be the better option.  But that's not really
> the right alternative.  If we change 822, the UA's can change gradually
> or never, depending on the needs of their user communities.

Please listen, I shall be brief.

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.

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.

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.

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.

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.

As an example of the latter, several people at the University of Oslo
contemplated just removing the 7-bit restriction in SMTP and accept
that users send 8-bit mail internally.  I'd be in favor of allowing
some leeway for local delivery, for a deliberately fuzzy "local".  I
mean, NORDUNET could mandate that all of Scandinavia was a "local"
area, and they could decide to use ISO 8859-1 "internally" and perhaps
use some encoding scheme to mail to Greece, Israel, Russia, or
whatever.  I DO NOT THINK THIS IS A GOOD WAY TO GO.  I do, however,
contend that further delay in the specification of clean 8-bit mail for
ordinary text is going to cause both random character sets, random use
of introducing sequences, and interoperability lossage.

Thanks for listening.

A meta-comment:

Due to the unavailability of graphical renditions for highlighted
phrases, CAPITAL LETTERS have been used to mark such.  I sent this
message without waiting for multi-media-in-7-bits because old con-
ventions could do what I needed.  On the other hand, I <hp0>could</>
have used the highlighted phrase tags from the general document type
definition in ISO 8879 (SGML) just to annoy those who are not familiar
with SGML.  SGML allows encoding of any conceivable character entity
with an entity reference, and my father's name would be coded as
"Bj&oslash;rn", rather than "Bj|rn", which he actually understands.
A comparison of this to 7-bit encoding to 8-bit character data is
<hp1>not</> coincidental.  I hope this example has provided some input
to those who are so engorged in multi-media mail that they have no time
to think of simple 8-bit text.

[Erik]