From donn@hpfcrn.fc.hp.com Wed Jun 26 23:28:24 1991 Received: from relay.hp.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA12678; Wed, 26 Jun 91 23:28:24 +0200 Received: from hpfcrn.fc.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA09197; Wed, 26 Jun 91 13:52:56 -0700 Message-Id: <9106262052.AA09197@relay.hp.com> Received: from hpfcdonn.fc.hp.com by hpfcrn.fc.hp.com with SMTP (16.7/15.5+IOS 3.22) id AA14950; Wed, 26 Jun 91 14:52:41 -0600 To: wg15rin@dkuug.dk Subject: i18n of mail Date: Wed, 26 Jun 91 14:52:40 MDT From: Donn Terry X-Charset: ASCII X-Char-Esc: 29 FYI Donn >From: nsb@thumper.bellcore.com (Nathaniel Borenstein) >Date: Tue, 18 Jun 1991 15:04:14 GMT >Subject: Internet Draft on Multimedia, Multipart Mail >Newsgroups: comp.mail.headers >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 >) and I will send them to you. Please specify >whether you want the text or PostScript versions. > -- Nathaniel Borenstein, Bellcore >------- End of Forwarded Message