🚀 go-pugleaf

In article <CKD.92Dec15215407@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
> VA> What's the difference between putting X- to the header line and
> VA> adding 0200 to the character code?
>
>The first is explicitly allowed by the relevant standard (RFC822).  The
>second is explicitly forbidden by the relevant standard (RFC821):

If any 7-bit encoding will be accepted as standard the corresponding
codewords will not start from X- and therefore will be explicitly
prohibited by the relevant (obsolete) standard.

Yours is non-argument. If a standard allowing 8 bits in SMTP will be
accepted the relevant standard (RFC821) will be superceded and therefore
irrelevant.

After all, that 7-bit limitation was a mistake in the first place
(and stupid one).  It was evident for a decade but somehow everybody
inertia won and we still have the old stupid mistake plus millions of
machines "compatible" with that mistake.

>The whole reason the
>Internet works as well as it does is that multiple independent
>implementations all follow a system-independent standard and not "the
>source code and behavior of <x> is the standard". 

The whole reason Internet works is because standards follow the
practice (instead of standard commitees deciding what's good and what's
bad (OSI, X.25, X.400, X.500 -- where are they?)). Unfortunately it
seems that standard-making frenzy is going to get over Internet too.

We don't need new standards to patch holes in old standards. It's
better done by relevant amending existing standars/software.

As for practice -- the real life in countries where non-ASCII
character sets were necessary decided against 7-bit "solution" long
time ago -- if you ever bothered to look how it works in Europe and
Russia.

>SMTP is bloated?  I'll trade you SOML, SEND, SAML, and TURN for an
>eight-bit negotiation mechanism.  We'll still slim it by a command or two.

It already has features nobody uses (VRFY, EXPN, SOML, SAML, TURN)
and simply useless (HELO). Most implementations simply don't know
what to do with all that (i know because i had a pleasure of
implementing SMTP stuff).

> VA> As i already said a lot of people in Europe already closed that
> VA> discussion using the simpliest solution. As every simple solution it's
> VA> easy to implement (no need to write new code -- just *remove* some
> VA> old), it works (for couple dozens of countries) and it provides easy
> VA> way for future extensions (aka UTF -- it you have 8-bit transparency
> VA> now it'll be really easy to switch to UTF tomorrow).

>And it breaks old code.  And it only works with cooperating sites, but has
>no way to tell whether the site it's talking to is cooperating or not.  And
>it can silently lose information by talking to an uncooperative (but
>standards-conforming) site that clips bits.

You don't send 8 bits to a site which does not understand it. It simply
makes no sense -- they don't have appopriate fonts on their terminals
anyway. If they do not coopearte they do not have you proposed bang-whiz
7-bit decoder as well and are unable to read the message anyway.

As for receiving 8-bit information with MSB trimmed off - it still
will be readable. FYI (if you didn't know that before) the old ISO
standard 8-bit codes were designed to have exactly this property.
For example, the standard Cyrillic code (USSR standard KOI-8) has
letters sorted in phonetical correpondence to the Latin alphabet,
not in the Russian alphabetical order.

	V lesu rodilasx elo^ka w lesu ona rosla

is MUCH MUCH more readable than

	MHHASDHWENSDJJWEHSDASKJWENASDJWEDJH

The advice to check your logic remains.

>I demand no encoding; I'd just as soon use Content-Transfer-Encoding: 8bit.

What for? What is really needed is the name of character set --
USASCII, ISO8859/1, etc.

>However, if I'm shipping it over SMTP, I either encode it or extend SMTP to
>transmit the 8th bit safely.

You need not "extend" SMTP to transmit the 8th bit safely.
The only necessary thing is to fix the old bug in the standard.

>Fine.  So join the ietf-smtp list, get an 8-bit-compatible SMTP, and you're
>set for life.

Why bother? I already did it for my native country.

>Encodings are necessary for 8-bit data over 7-bit paths.  Eliminating those
>paths safely takes a new standard (admittedly, not much of an extension to
>the old one). 

Argh. What a faulty logic. You need a new standard in places which
supposedly won't switch to a (different) new standard. If they won't
fix their software to provide 8-bit-clean links how are you going
to make them to add the new code for handling 7-bit encoding?

I'm calling for REALLY minor changes in the EXISTING software
(and those changes are necessary only on relay machines -- end users
can live without it if they have no use for 8-bit transparency).
7-bit hardware paths are virtually non-existant. Hardware people
overcame that idiocy twenty years ago.

You're calling for implementing the entirely new standard in EVERY piece
of mailing software (including end users') and making already 
bloated mailing software even more bloated. What do you want to gain
this way? More bugs? Or job security for system administrators?

>Someday most of us (never all of us, after all the Host
>Table still reigns on MILNET) will be shipping around mail in its full
>binary glory without encoding.  But we'll have some way to know when we hit
>aging-tops-20.army.mil and feed them our mail properly encoded so they can
>pull it down to their DeskCrays and see it in the full glory of 10646.

How naive... The only way you can make such people to do something
is to force them to do it. With "8 bit is good but you still can use
7 bits..." you'll *never* get them to fix their software toward 
8-bit transparency.

--vadim