Re: A proposal

[kankkune@xxxxxxxxxxxxxx (Risto Kankkunen)]

> > Something like "I-HAVE-EIGHT-BIT-DATA-PATH" might be better.
> 
> 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.

Well, I though we might allow other sets from the 8859-family, too. The
exact character set could probably be stated in some Encoding-header for
those that have intelligent UAs and hardware. Others could just hope the
message uses the character set their hardware has. Not that this is a
big deal...

> > Multi-part and multi-media has nothing to do with the extended SMTP.
>  
> 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.

To clarify: I meant SMTP shouldn't need to know the message is multi-
something, you can provide that information with RFC822-extensions and
use normal SMTP. That's why I wondered why you brought multimedia-issue
to this is you only meant binary transfer...

> ...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, ...it would be
> beneficial to find out what the server could handle as early as
> possible, ...

If the message is sent (somehow encoded) in this case also, the sender
and recipients have to be negotiated anyway. If it is not sent, you save
a bit.

> 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?

Either.

> > 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.
> 
> 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.

I don't understand. If the sender says DATA, I would read bytes watching
for CRLF.CRLF and CRLF..CRLF sequences. In unix, for example, I would
throw away every CR from CRLF when writing the data to spool directory.
If the sender says BDAT, I would read bytes the same way, but not strip
CR's when writing the data.


-- 
 Risto Kankkunen                   kankkune@cs.Helsinki.FI (Internet)
 Department of Computer Science    kankkunen@finuh          (Bitnet)
 University of Helsinki, Finland   ..!mcsun!uhecs!kankkune   (UUCP)