nsb@thumper.bellcore.com (Nathaniel Borenstein) (06/18/91)
I am pleased to announce the publication of an Internet Draft document entitled "Mechanisms for Specifying and Describing the Format of Internet Message Bodies" by Ned Freed and myself. This document is the result of several months worth of work on the part of dozens of people who have participated in the Internet Extensions Task Force Working Group on SMTP Extensions, and in the ietf-822 mailing list. As an Internet Draft, the document has no status as a standard, but specifies a protocol that many of us hope to see evolve, with modifications, into an Internet standard eventually. In particular, after a few months for experimentation and comment, we will submit a revised version as an RFC (Request for Comments), which is the next step on that path. The document is about 40 pages long, and specifies several backward-compatible extensions to the Internet Message Format standard (RFC 822). In particular, it specifies standardized and robust ways to do the following: -- Describe the contents and type of a message body, e.g. as audio or image or formatted text data in a certain format. -- Encode arbitrary binary or 8-bit data for transmission via 7-bit SMTP. -- Use certain non-ASCII character sets to transmit text in virtually any natural language -- Combine multiple parts, each of potentially differing types, in a single email message. At least four, and probably more, independent implementations of this protocol are currently in progress. Already, for example, it has been used to interchange multipart audio/video/text mail between two users of independent software using two different windowing systems. After a few months of such experimentation and comments from a wider community, a new version of the document will be drafted and submitted as an RFC. If you are interested in reading this document, which is approximately 40 pages long, it will be available soon as an Internet Draft. Alternately, it is available now via anonymous ftp from the host thumper.bellcore.com, in the directory /pub/nsb. The PostScript version is called "BodyFormats.ps" and the plain text version is called "BodyFormats.txt". Also available in that directory is a much shorter document that describes a configuration mechanism for compatibly extending existing mail-reading agents to handle arbitrary mail types of the kind described by the first document. (This document is my own work, and does not reflect the work of the IETF working group or any other semi-official body.) Copies of that document are availble in the same place, under the names "Configuration.ps" and "Configuration.txt". Although I encourage you to read and comment on these documents, I also encourage you to relax and do so carefully and at your leisure. As you will read in the document, we do not expect to begin working hard on the next draft until late September, so there's no reason to rush hasty comments to us in the next few weeks. Of course, your comments are welcome at any time before that, as well. If you do not have ftp access to either the Internet Drafts or to thumper.bellcore.com, you may send mail to me (Nathaniel Borenstein <nsb@thumper.bellcore.com>) and I will send them to you. Please specify whether you want the text or PostScript versions. -- Nathaniel Borenstein, Bellcore
david@actsn.fay.ar.us (David Summers) (06/23/91)
Hopefully this belongs in all of these groups... What chances are there of SMAIL 3.1.21, MUSH 7.2.3, and ELM 2.3.11 supporting this (new?) "standard"? How easy would it be to make changes for this? What changes would be necessary? I'm really excited by this and in a way am kind of confused as to why it has taken so long (???) to come up with a binary "standard" for e-mail? It SOUNDS like it wouldn't be too hard to make changes to support this. Am I being naive? I haven't even looked at the code for these programs yet (very much). Also: What about UseNet/NetNews? Could this also apply to that? Let's have some discussion! :-) - David Summers (david@actsn.fay.ar.us) -- I'm sick and tired of this machine, I wish that I could sell it. It never does just what I want, but only what I tell it! - David Summers (david@actsn.fay.ar.us)
rfarris@rfengr.com (Rick Farris) (06/24/91)
In article <335@actsn.fay.ar.us> david@actsn.fay.ar.us (David Summers) writes: > I'm really excited by this and in a way am kind of confused > as to why it has taken so long (???) to come up with a > binary "standard" for e-mail? Well, to start off with, it is no mistake nor accident that many uucp sites limit the size and content of the email they are willing to process. In the Unix world the "binary standard for e-mail" is called "uucp." If you point out that most sites won't forward multi-hop uucp traffic, I'll again claim that it is no mistake nor accident. > It SOUNDS like it wouldn't be too hard to make changes to > support this. It's not a technical problem, it's a social problem. Many uucp sites don't wish to pick up the tab so that you can transfer your gifs or fax files at no cost to yourself. > Am I being naive? Only politically. :-) > Also: What about UseNet/NetNews? Could this also apply to > that? Same answer. -- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757
scum@walney.com (Steven C. Monroe) (06/24/91)
Is there a chance that someone could e-mail a copy of this to me? Thanks -- -*-*-* Steve Monroe scum@walney.com 304 E. Amhurst St., Sterling, VA 22170, (703)430-1388
syd@DSI.COM (Syd Weinstein) (06/24/91)
david@actsn.fay.ar.us (David Summers) writes: >What chances are there of SMAIL 3.1.21, MUSH 7.2.3, and ELM 2.3.11 supporting >this (new?) "standard"? How easy would it be to make changes for this? >What changes would be necessary? If I understand what the IAB is doing, there would need to be no to very minimal changes to the MTA level. (Unsure if non 8 bit MTAs would have to be 8 bit clean) As for MUSH, I cannot answer, I can for Elm... There is no chance Elm 2.3.PL11 can handle it :-) thats because if we add support we have to change the number.... Seriously, Elm will eventually follow the standard. But I doubt the IAB stuff will be done in time to make any difference in 2.4, and I doubt that it will fit cleanly into the Elm 2.x version anyway. As for 3.0, where we will be rewriting Elm, yup, it will be in there, unless its a total abomination (which I doubt) -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
david@twg.com (David S. Herron) (06/25/91)
In article <335@actsn.fay.ar.us> david@actsn.fay.ar.us (David Summers) writes: >Hopefully this belongs in all of these groups... > >What chances are there of SMAIL 3.1.21, Smail shouldn't care unless it wants to try to intelligently fiddle with the contents. At least the contents are well enough marked that fiddling with them should be doable. But doing so shouldn't be necessary in all but the weirdest cases. (For instance, if final delivery is to a FAX machine...) >Also: What about UseNet/NetNews? Could this also apply to that? Sure, why not? The existing transport should be able to handle it since it just passes along headers it doesn't understand. All you'd have to do is fix up the user agents ... -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
nazgul@alphalpha.com (Kee Hinckley) (06/25/91)
In article <335@actsn.fay.ar.us> david@actsn.fay.ar.us (David Summers) writes: >I'm really excited by this and in a way am kind of confused as to why it has >taken so long (???) to come up with a binary "standard" for e-mail? It It hasn't. RFC 1154 provids support for it (and the Poste mail system uses this). Z-Mail also supports binary enclosures, but not using any of the released RFCs. And there are older RFCs than 1154 which also provide means of doing binary message transfer. There just hasn't been the critical mass or need to see these things used heavily before now. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
ziegast@uunet.uu.net (Eric W. Ziegast) (06/27/91)
scum@walney.com (Steven C. Monroe) writes: } Is there a chance that someone could e-mail a copy of this to me? For the convenience of those using UUCP, I've gotten copies of these files and put them on uunet (temporarily)... 80591 uunet!tmp/nsb/BodyFormats.ps.Z (40pg paper) 40728 uunet!tmp/nsb/BodyFormats.txt.Z 19440 uunet!tmp/nsb/Configuration.ps.Z (7pg paper) 7672 uunet!tmp/nsb/Configuration.txt.Z 25863 uunet!tmp/nsb/EdV.ps.Z (Screen dump) They'll be there for at least a week. -- Eric W. Ziegast Jr Postmaster - UUNET Technologies ziegast@uunet.uu.net postmaster@uunet.uu.net