re John Klensin on my 8-bit comments

[Robert Ullmann <Ariel@xxxxxxxxxxxxxxx>]

>From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
>Subject: Responsive vendors and their implications (was de-facto 8 bit smtp)

>> (me:)
>>I also want to mention that I have a different viewpoint on how long
>>...
>>a version upgrade can be done overnight, and is sometimes done in
>>minutes. (in general, the faster it is done, the happier the customer)
>>...
>This is, of course, correct, at least for the class of environments
>Robert is discussing.  Of course, there are, in addition to local hacks
>and volunteer maintenance, a number of vendors who are, shall we say, a
>little slow about the types of issues Robert raises.  There are at least
>...
>larger than Prime.

And we (Prime) intend to take as much business away from them as we can!
(the big ones. If the small ones with good product have trouble, they should
contact us about providing worldwide sales/service/support :-)

>  Based on his experience and perspective, Robert is an optimist about
>these things.  Possibly based on ours (which includes having significant
>machines abandoned by vendors while the machines were in their prime),

Prime? An intentional pun? I hope not ... :-)

>  But this aside, it seems to me that Robert's argument contains the
>seeds of its own destruction.  Let's assume that the world is populated
>by responsive vendors with good software update and distribution
>mechanisms who can get an update out in a few days if they feel like it.

Days? DAYS? What is the network for? Why do you think we invented Encoding,
and specifically, the encoding used for Prime file-system objects?

When finishing PDNmail 1.6 in 1987, I faced the prospect of making and
mailing 50+ tapes, just to update Prime internal sites. I added "binary"
transfer so that I could MAIL (*electronic* mail!) the 2.0 release.

Minutes is more like it.

(Given that a fix is simple/already available, and given that you
can report the problem that fast to someone who can handle it ...)
If your vendor takes months to send you fixes, find a new vendor.
(I could suggest one, but this has crossed the border into commercial
use :-)

>Robert says...
>>It would be a real shame if a mailer called up one of them, said ...
>  Yep.  But then, by his own argument, the users would call the vendor,
>en mass, and say "hey, your mailer is out of spec, it is rejecting mail
>that it ought to know how to handle".  And the responsive vendor, in a
>matter of days (if not hours) would prepare and ship an update that
>would provide a "2xx OK" in response to these eight-bit indicating
>verbs.

Agreed. If we settle on a ISOC verb (or whatever), I will have fix
release 2.3.1 available to my customers the day I get back from
St. Louis. But (as you so kindly point out :-) other vendors who have
8-bit mailers won't be so responsive ... <grin>

>There is another point here, which has been said in other contexts, and
>I think bears repeating.  There are a lot fewer SMTP MTAs out there than
>there are UAs that handle RFC822.  The MTAs tend to be part of TCP/IP
>...

A somewhat different point, that is often forgotten: I am not talking
about breaking, in any way, the existing function: that is, the
transport of 7-bit ASCII messages.

We can't "fix" every component at once to handle 8 bit. (tautology,
for practical purposes). First, we have to fix the MTAs, then the UAs
(where needed, IMHO, most UAs will work fine when 8859/1 or ISO10646
is implemented where it should be: in terminal drivers and terminals.)

First: we permit 8 bit SMTP. Operative word is "permit".

>>Possible answer: send the command  n o o <eth> <nbsp> p <cr> <lf>
>>(Hex: 6E 6F 6F F0 A0 70 0D 0A)
>>
>>An 8-bit mailer will reply 500 No Such Command. ("Nooeth p"? Nil. :-)
>  I don't know that this is necessary or desirable, especially since I
>think that Robert has just argued that he can quickly adapt to whatever
>is decided and that his customers will make him do that :-), but I must
>say it is a fascinating approach.

The point is: if you want a detection verb, this WORKS NOW.

>    --john

Rob