Re: a different proposed RFC for 8-bit extension

[kankkune@xxxxxxxxxxxxxx (Risto Kankkunen)]

John Klensin wrote a good (and long ;-)) analysis of extending SMTP to 8
bits. I agree with John on this, but as I have mentioned that MTAs could
encode messages if needed, I like to point out that this approach was
what I had in mind:
 
>   (ii)  By a variation of the argument that said "if we have to change 
> 822 anyway, let's try to avoid changing 821 also", it is rational to 
> argue that, if the UAs are going to have to support encoding and 
> decoding characters and binary octets, there is no point putting that 
> capability into the MTAs also.

It isn't relevant whether you put the encoding functionality to the MTA
program or to the UA programs. What I see more important is whether that
functionality is defined in SMTP or in 822++. I could think of
environments where the MTA would decode the messages for the UAs, but it
would do this solely by reading the Encoding-headers. The point is you
can build a lot of intelligence to the sending or receiving MTA, if you
want to, but you can do it without help from SMTP.

And I agree with John here that the best way is to leave the encoding
business to the 822++ and extend SMTP only by a verb that tells 8 bits
is coming. My favourite is to give an alternative to the DATA verb, like
DAT8 or whatever.


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