Re: A proposal

[Erik Naggum <erik@xxxxxxxxxxxx>]

> > B. Mandate that the third token on the 220 greeting line be some
> >    magic, like "8859-1", unlikely to be part of a normal greeting.

> If a round-trip must be avoided and the reply code method isn't
> feasible, something like this might be tried. The magic shouldn't say
> anything about the character set, though, if you only want to advertize
> your 8-bit capability. Something like "I-HAVE-EIGHT-BIT-DATA-PATH" might
> be better. The server could also tell at the same time if it can do
> binary.

Whatever you say.  The point is that we do, in fact, transfer text, and
we do not, in fact, transfer binary data.  There seems to be (at least to
me) a consensus that ISO 8859-1 is the way to go for 8-bit _text_ _mail_.
Robert Ullmann (hi!) has even made a refrain out of it.  So let's sing!

I may have been unclear in my own enthusiasm, but my point was that there
had to be _some_ magic cookie, but as far as I'm concerned, it can be
_any_ magic cookie as long as it carries the important semantics.  That
I picked "8859-1" was not that essential to my message, but I think it
makes sense, semantically, in lieu of the recent discussion of it.

> > I thus propose that for multi-part, multi-media messages, we adopt a new
> > verb in place of MAIL, but otherwise identical:

> > 	MESG From:<erik@naggum.uu.no>
> > 	250 OK, accepting binary message
> > 	RCPT To:<enag@ifi.uio.no>
> > 	250 OK, he's here
> > 	DATA 59636
> > 	<59636 bytes of content>
> > 	250 OK, message delivered

> Multi-part and multi-media has nothing to do with the extended SMTP.

I see that my message must have been much less forceful and elegant than
I thought at the time of writing it.  Risto, I do know that m-p and m-b
messages have nothing to do with the extended SMTP, as far as a few people
on this list are concerned.  That doesn't make it so, even though I may
agree with it under favorable weather conditions.

> I assume you mean MESG would indicate that the message is transferred
> in binary.

I'm glad that this came through.

> Why do you change the MAIL verb instead of DATA?

After considering the difference between MAIL and MESSAGE which John
Klensin brought forth with elegance and force, and what it would mean
to have negotiated sender and recipients and only after everything was
set up to be informed that the server couldn't handle what I wanted to
give it, and that round-trip time is a concern, I unanimously agreed
(apologies to those who don't read CCITT docs) that it would be beneficial
to find out what the server could handle as early as possible, that the
server might prepare itself for a different format as soon as possible,
and that error recovery would be simpler with early warning systems than
with damage assessment squads.

> Keep the MAIL and change DATA to "BDAT 59636".

To checkpoint my argument:  What do you do if the server NAKs your BDAT
request?  RSET or major conversion in the backroom and another DATA?
The point with the binary transfer option is that it can't readily be
converted into ordinary line-delimited text on the fly, and you wouldn't
what that, either.  Wherefore, of course, we discuss a way to make SMTP
carry some heavily encoded format.  I think we should perhaps make it
possible for those who wish to talk with more efficiency to be able to
do that.

> Another alternative is not to announce the count
> but to use the period stuffing like normal DATA. In this case the server
> can read the data part the same way whether the data was 7 or 8 bit
> binary or not. I'dont know if this is an advantage.

It certainly makes for an interesting situation when you deal with text
and binary in different ways and end up with less bytes received in line
mode than you would have expected in binary mode.  Remember, we're dealing
with text, here.  (Robert sings refrain in background.)  If we wish to
deal with binary, there has to be changes somewhere.

[Erik]