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)