Xref: utzoo comp.mail.misc:5774 comp.archives.admin:90 comp.text.sgml:255 Newsgroups: comp.mail.misc,comp.archives.admin,comp.text.sgml Path: utzoo!utgpu!news-server.csri.toronto.edu!ox.com!msen.com!emv From: emv@msen.com (Ed Vielmetti) Subject: Re: [comp.mail.misc] Internet Draft on Multimedia, Multipart Mail In-Reply-To: nsb@thumper.bellcore.com's message of Sat, 22 Jun 1991 02:55:28 GMT Content-Type: multipart; 1-S; comp-archives-multimedia-interface Message-ID: Followup-To: comp.archives.admin Sender: usenet@ox.com (Usenet News Administrator) Organization: MSEN, Inc. Ann Arbor MI References: <1991Jun22.025528.9355@ox.com> Date: Sat, 22 Jun 1991 04:22:35 GMT Lines: 64 Content-type: Message/Partial; "oc=1991Jun22.025528.9355@ox.com; 1; 1" nsb@thumper.bellcore.com (Nathaniel Borenstein) writes: 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. --comp-archives-multimedia-interface Content-type: text-plus/richtext It is my intention to support this mechanism in the newsgroup comp.archives as a standard means of formatting multipart messages. I will do this gradually, with the intent of not breaking any existing scripts if I can help it. In particular, the existing auxilary headers, at least the ones that really get used, will stay around for a while, at least until this Internet Draft turns into an Internet Standard. comp.archives articles are really comprised of multiple parts: there's an excerpt from a usenet news article, a pointer to files on one or more remote systems, a verification that the remote systems actually contain the files in question, and some keyword or proximity information. These pieces are logicially separate, and it would be a fine thing to be able to burst them apart cleanly and do different sensible things with each. I would hope that the eventual result would be a news reader or mail reader capable of putting up buttons on the user's screen asking them if they want a copy of what's mentioned there, and then fetching the file for them. Once the pioneering work is done in comp.archives, other people writing articles in which they want to put up buttons like this will have a standard to go by. That'll make scanning for potential comp.archives articles really easy.... It appears as though the main limiting factor in applying the richmail interface to comp.archives is the need to fully specify a Content-Type which has enough oomph in it to let you snarf things from all over the place, even if they are in odd or out-of-the-way places and are accessible through non-standard means. It's not simply enough to say that a file is available via anonymous ftp from a site; there are enough places with interesting things where there the anonymous password must be "guest" (nnsc.nsf.net), or where there's a second non-anonymous login (netlib@research.att.com), etc. Some thought needs to be given there. I'd also like to get the verification information suitable for direct insertion into archie, so standardization there would help too. Given an infinite amount of bandwidth, you could even encode screen shots, or voice annotations by your erstwhile archivist, or any other definable document type. Could make for interesting viewing. --comp-archives-multimedia-interface-- Content-type: text-plus/richtext Edward Vielmetti, moderator, comp.archives, emv@msen.com (6) The Plan shall identify how agencies and departments can collaborate to ... expand efforts to improve, document, and evaluate unclassified public-domain software developed by federally-funded researchers and other software, including federally-funded educational and training software. High-Performance Computing Act of 1991, S. 272