dpowles@CCD.BBN.COM ("Drew M. Powles") (07/21/87)
This may sound like a silly question, but believe me, I have a need. In going through the SMTP spec, there doesn't seem to be any provision for embedding full octets in the body of the message, only seven bit ascii. Is this an artificial limitation? What if I want to use special characters embedded in my text? TCP does provide an eight-bit byte interface. Does anyone have any thoughts or experiences along these lines they could share with me? thanks. Drew M. Powles BBN Communications dpowles@ccd.bbn.com
mrose@GREMLIN.NRTC.NORTHROP.COM (Marshall Rose) (07/23/87)
I don't know what the "official" word is, but SMTP is designed for
moving ascii messages. Although the gurus will probably tell you
otherwise, SMTP is very dependent on rfc822, which defines the
format of text messages. This probably isn't the fault of SMTP,
since all of the mailers which use SMTP also depend on rfc822 or
rfc822-like formats being used.
If you want to use SMTP to move arbitrary octets in messages, then
on UNIX, using something like atob and btoa. btoa takes a "binary"
stream (8-bit bytes) and explodes it into a 7-bit data path with
line breaks at column 78 (or something like that); atob performs the
inverse operation. I'm sure other systems have similar programs.
Alternately, find someone running X.400 in the Internet and just use
X.400. Of course, it's probably going to be another three years
before X.400 mailers will have the reach of SMTP mailers.
/mtrron@TOPAZ.RUTGERS.EDU (Ron Natalie) (07/23/87)
I strongly object to modifying SMTP and RFC822 to allow for this. Lets keep plaintext plain. If you wish to enhance mail, try the multimedia mail project. The main problem with the existing Multimedia project is that NOBODY OBEYS THE SPECIFICATION. Hence messages from DIAMOND are unreadable on other systems.
ejc@TSCA.ISTC.SRI.COM (07/27/87)
This will likely lead to yet another tangent and should be continued on the MM Mail list, but it isn't true that NOBIDY FOLLOWS THE SPECIFICATION for MM Mail. There was a report written by SRI in 1983 defining the consensus (among DoD researchers) specification for standardized MM Mail exchange at that time. The BBN Diamond, ISI MMM, and SRI MMM systems all conformed to that spec (and also, I believe, Dave Mills' Fuzzballs could read MM msgs). A RFP was to be generated, and more development was to be undertaken, especially in the area of graphics exchange. BBN decided to change the DIAMOND exchange formats to support new capabilities they were developing, and as a result, they were no longer compatible with the other (still operational) systems. SRI, in turn, has been funded to develop systems that handle digitized images (maps) with dynamically changing graphic overlays. One might argue that these enhancements should have been discussed and a common exchange protocol agreed to by the "whole community", but the truth is, minimal funding is being provided for that. One observation that is given to support the cutback in funds is that there aren't any remaining research issues. But, one only has to look at the subject headers on this mailing list (the details quickly become boggling) to see that there are many unresolved issues in information exchange in our current systems (not even addressing enhanced system capabilities) and that a much better framework is needed. So, in summary, there still are "compatible" MM Mail systems, they clearly need upgrading to support new capabilities, DIAMOND is developing such capabilites but common exchange protocols need to be re-established in order to leverage all the on-going research in these areas. Earl
postel@ISI.EDU (08/06/87)
Drew: Once upon a time long ago and far away there were computers that internally stored characters as 7-bit bytes. At the time that the mail protocols were designed such computers were a significant part of the network population. There are still some of these computers in existance, and some of them do a lot of mail forwarding. If a message passes through one of these computers the (high-order) eighth bit will be lost as it is stored (however temporarally) and a zero value (high-order) eighth bit will be supplied as the message is forwarded on. If somehow your message does not pass through any of these aging beasts and passes only through computers that work on eight-bit bytes internally it probably will keep all eight-bits of every byte just the way you wanted them. But there are no guarantees about it. Go ask some old time BBN-er "What does 'TENEX' mean?". --jon.
ROODE@BIONET-20.ARPA (David Roode) (08/12/87)
One reason not to expand SMTP to provide for 8 bit ASCII is that there are a goodly number of obscure computer made by a company called IBM that are probably already internally converting 7 bit ASCII into 8 bit EBCDIC. Who knows what would happen to information encoded into the ASCII parity bit when transmission to one of these guys were attempted. Some of them are still sending mail messages to each other by pretending to punch cards on each others' virtual card punch. Not to poke fun, this is just an example of the sort of baggage that accumulates when one is in business for 40 years or more, give or take a few years, in a field beset by technological advances. It's a miracle that ASCII itself is acceptable in the international community, and I am sure there are some problems with that--going through international mail gateways to other countries' research mail networks would engender problems for 8 bit ASCII, I suspect. -------