🚀 go-pugleaf

VA> == Vadim Antonov <avg@rodan.UU.NET>

 ckd> The first is explicitly allowed by the relevant standard (RFC822).  The
 ckd> second is explicitly forbidden by the relevant standard (RFC821):

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

'822 specifically says that extensions may be designed in documents
published as "formal extension[s] to this specification", a classification
which the MIME spec clearly falls into.
     extension-field =
                   <Any field which is defined in a document
                    published as a formal extension to this
                    specification; none will have names beginning
                    with the string "X-">

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

And it will be a different protocol, even if it shares 90% of the command
set and features and runs on the same well-known port, because 8-bit data
is a *contradiction*, not an extension, of the standard.

 VA> After all, that 7-bit limitation was a mistake in the first place
 VA> (and stupid one).

This is very true; I have no argument with you on that point.

 VA> It was evident for a decade but somehow everybody inertia won and we
 VA> still have the old stupid mistake plus millions of machines
 VA> "compatible" with that mistake.

Also true; the SMTP extensions for 8-bit data should have been done a long
time ago.  Unfortunately, they weren't...

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

But to amend a standard in an incompatible way you need a new standard,
preferably one with some kind of negotiation for the new, incompatible
features.

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

I know how they do it.  They do it by breaking the standards within their
community.  That's fine.  However, as a universal solution, it falls down.

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

I've done some SMTP implementation as well.  I use VRFY/EXPN often enough
(one of the hazards of postmastering I guess).  SOML/SAML/TURN can go.
HELO is a good starting point for the version negotiation command (EHLO in
the last SMTP extension document I really looked at).

 VA> You don't send 8 bits to a site which does not understand it. It
 VA> simply makes no sense -- they don't have appopriate fonts on their
 VA> terminals anyway.

How do you know if arbitrary-site understands it or not?  YOU CAN'T.  And
remember, the terminals may be several years newer than the mailhost.

 VA> If they do not coopearte they do not have you proposed bang-whiz 7-bit
 VA> decoder as well and are unable to read the message anyway.

Nope.  Let's say someone has an IBM mainframe with some old IBM TCP/IP
mailer software, and a POP3 daemon.  The mainframe is glaringly 7-bit,
can't be fixed, and can't be thrown out because of some dusty decks.
However, the mail users only read their mail using POP clients on Macs and
PCs.  The POP clients have MIME support, so they can read and send
ISO-8859-x mail, and maybe Unicode/10646 when it's settled out.  But they
don't run SMTP, aren't always up, and are unsuitable for use as a mailhost.

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

That's good, but there's still an information loss, which can be avoided.

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

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

Which is a separate issue from 8-bit SMTP, and is handled by MIME.

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

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

The bug can only be fixed by fixing the standard; the standard can only be
fixed by extending it to include a negotiation phase.

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

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

"Screw you, it works for me, who cares if it crashes your mailer"?

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

MTAs are not MUAs.

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

I'm calling for the same minor changes IN A BACKWARD COMPATIBLE MANNER
(which yours are not) plus a method for working around and through the
7-bit paths which will remain despite all our efforts.

 VA> You're calling for implementing the entirely new standard in EVERY
 VA> piece of mailing software (including end users') and making already
 VA> bloated mailing software even more bloated.

The new SMTP standard only needs to be implemented in MTAs.

MIME only needs to be implemented in MUAs for people who care about reading
eight-bit mail.  To quote you, "Why bother?  I already did it for my native
country."  *I* can live with US-ASCII limits, so maybe I don't install MIME
on my "usual" mailreader (though I'm working on it).

 VA> What do you want to gain this way? More bugs? Or job security for
 VA> system administrators?

More capabilities.  Multimedia mail.  Multilanguage mail.  Easy file
attachment (either directly or with automatic ftp pointers).  MIME is not
just character sets.  ESMTP is not just 8-bit cleanness.

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

Force them to do it?  Have you read the "MILNET DNS Transition Schedule"?
The DoD can't even force them to do it.  (You also can't force sites with
old hardware and software to replace it, unless of course you're
volunteering to pay for all the transition costs...)

You're telling me to accept reality, then you're denying it by saying "oh,
just do this, then they'll upgrade".  Why should they upgrade when you're
the one breaking the standard?
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<ckd@eff.org>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
+1 617 864 0665  [CKD1]   |   --Peter da Silva <peter@ferranti.com>