Re: Speedy closure & 8bit cleanliness

[hansen@xxxxxxxxxxxxxxx (t.l.hansen)]

< The other argument is that we still have folks around who want to
< transport length-delimited "octet stream" binary over SMTP.  Now,
< personally, I think that is a bad idea, and I've argued fairly strenuously
< against it in the WG.  But, if one were designing a general extension
< mechanism, it could be argued that it should be general enough to provide
< a service extension for binary, and a BINARY keyword, and then the use of,
< e.g., a parameter on DATA to specify the length (no lines, no CRLF.CRLF).
< For technical reasons that Mark Crispin has explained much better than I
< could, one really doesn't want to mix that up with text-based headers.
< So, if you wanted to admit of doing this, ever, you wouldn't want to build
< a general MIME requirement into the extension mechanism.

I am one who would support having some form of BINARY keyword. However, I
feel that it is only useful in conjunction with a MIME requirement. Because,
how else are you going to be able to pick out the parts that are text from
the parts that are binary, and be able to identify what they mean? MIME
currently permits 8bit octet streams for either entire message bodies or for
parts of messages. It would be nice if we can transmit those parts without
having to increase the size by 33% (or however much) by translating to base
64 or quoted printable.

There is a major difference between 8-bit text and binary octet streams. The
8-bit text is something that will be translatable by gateways into another
form of 8-bit text on the receiving side. It is also sensible to have the
1024 length limit on lines of text, whether it is 7-bit or 8-bit. However,
the binary octet streams should never be touched, and have no limits in line
length. They require different handling by the remote end. Given that a MIME
message can specify where one part starts and the other begins, it is fairly
easy to deal with such binary octet stream portions, IF you had MIME. So
SMTP should be able to permit us to transfer it without making any
translations. Currently, to transmit the binary octet streams, I have to
translate everything before transmitting; I'd rather just have a way of
stating its length, or at least the length of a chunk which is to be
transmitted without requiring any CRLF.CRLF. With the latter, I can pass
over chunks of my 8-bit octet stream without worry.

					Tony Hansen
			    hansen@pegasus.att.com, tony@attmail.com
				att!pegasus!hansen, attmail!tony