The Arachnet Electronic Journal on Virtual Culture __________________________________________________________________ ISSN 1068-5723 August 20, 1993 Volume 1 Issue 5 SQARV1N5 WEIBEL Mime and the Future of Internet Journals An essay written for the _Electronic Journal of Virtual Culture_ Stuart Weibel OCLC Office of Research weibel@oclc.org July 16, 1993 The Chaos of Current Internet Publishing It is often hard to follow, much less predict, the evolution of electronic publishing and scholarly communication. The models of our paper-past have grown fuzzy around the edges in the electronic age of online full text, USENET lists, LISTSERVs, bulletin boards, and myriad network finding aids. Readers of this essay are, by definition, part of the vanguard of this change. We are early adopters of a chaotic technology, and the momentum of our own enthusiasm generally carries us beyond the many annoyances and impediments that stand in the way of an easy, natural, information retrieval environment. The future of electronic publishing is not in ASCII representations, however. If this journal exists in 5 years, it will certainly not be in the form that you are now reading. We are too accustomed to the richness of format the printed page affords, and for good reason. The nuance and artfulness of a well-formatted document provides cues to meaning and eases the eye's burden in extracting both information and pleasure from what we read. It is more than a matter of aesthetics (though aesthetics are certainly a worthy concern), it is a matter of facilitating the transfer of content from the author to the reader. ASCII is not enough. Our present environments are not so much primitive as chaotic. There are many different word processing systems and desk top publishing systems that will produce fine output (in capable hands), but no general agreement about what the display or transfer format should be. This diversity is problematic, but it is also the natural and unavoidable consequence of a rich and rapidly developing world. The challenge is how to accommodate this environment without causing it to solidify prematurely, and yet to rise above the lowest common denominator of hardware and software -- the text-based terminal -- to provide a publishing medium worthy of the ideas it carries. MIME is potentially an important part of the solution. WHAT IS MIME? MIME as an acronym stands for Multipurpose Internet Mail Extensions. It refers to a proposed Internet standard known by the designation RFC 1341 (Internet standards and related proposals are promulgated in numbered documents known as Request for Comments, or RFC's) that provides a framework to ease the task of integrating a variety of types of information into MIME-compliant applications. MIME-compliant applications are mail programs, but as time goes on, they will evolve to become generalized information-gathering tools. MIME applications handle the details of retrieving, converting, and displaying a wide variety of message types in a manner transparent to the user. WHAT IS THE RELATIONSHIP OF MIME TO EXISTING INTERNET MAIL? Imagine that the post office required a separate mailbox on your porch for each variety of mail. That book has halftones? Third row down, three slots to the right. Color photos in that magazine? Top row, second slot. Text only? Upper left hand slot (as long as it has only one font). Silly, yes, but that is pretty much the situation today, and the only standard mailbox in the Internet world is that one on the upper left... ASCII characters only, 1000 characters per line. And make sure it isn't too long a message! Sure, NeXT machines can exchange multi-media mail among themselves, and Sun workstations can send voice mail back and forth, but interoperability is not currently the norm. None of us should be constrained to a particular vendor's notion of what we should receive in our mail. The original Internet E-mail standards were established in 1982 in RFC 821 and RFC 822. Networks and the variety of information traveling them have changed but these standards still specify the headers wrapped around a message that enable its delivery (an electronic envelope of sorts). MIME, as its name indicates, is an extension of the existing standards. Whereas the standard headers define the envelope of the message, MIME headers describe the structure of the content. These headers constitute directions that allow the message to tell the receiving application what sort of data is in the message, what resources are needed on the receiving end, and (in some cases) where on the network part of the message might reside. If you read mail headers regularly, you might think about seeking leisure time counseling, but you probably have seen the following headers appear occasionally: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII These headers tell your mailer that the message originated in a MIME-compliant application and that it consists of a conventional ASCII message (this will continue to be the default format). Your current mail reader probably ignores these headers. MIME-compliant mail readers, however, are able to handle multi-media messages, including richly formatted text, images, audio, and video clips. The presence of a header specifying a more esoteric data type than plain text would invoke an appropriate display or play back mechanism. The local application understands what resources are necessary to display or play back the contents of such messages, and are configured locally to know which of these resources are available and behave accordingly. In many cases, the data objects themselves will not be in the message at all. Instead, there will be a pointer to a remote object somewhere on the net... perhaps a sound clip, a video clip, or a full color image. Local applications that cannot play back or display such an object will simply not issue a request to retrieve it, and instead will notify the user that a particular object type is part of the message but cannot be displayed. HOW CAN MIME BE APPLIED TO INTERNET PUBLISHING PROBLEMS? LISTSERVs have carried the load for newsgroups and most Internet electronic journals in the early stages of Internet publication. They are a primitive, but effective, means for distributing plain text and other formats which are encoded in ASCII (PostScript, for example). Nonetheless, the burden is on the user to select and request a particular format. The additional step of creating a request mail message to retrieve a file may deter users already burdened with overflowing IN boxes. Non-ASCII files cannot be mailed at all without conversion, further complicating the process of retrieval and display. The electronic journal of the future will arrive in your MIME-compliant reader as a table of contents or perhaps as a citation and abstract. The message will be relatively small, consisting mainly of pointers to the articles and their constituent parts. Rather than composing a return message to retrieve further articles, the user will simply select an article with a pointing device or from a menu and the application will retrieve the necessary parts automatically, through the mail or by way of an automated FTP process. This `retrieve as necessary' strategy reduces unnecessary demands on bandwidth and local disk space, important factors as multi-media objects of large size become common on networks. Internet publishers may choose to make available several versions of a document aimed at delivery platforms of various capabilities. The user application can then choose the particular format of the article appropriate to the local environment. The notion of `dynamic data' has become popular as an example of how electronic journals will grow beyond the functionality of `electronic paper'. It would be appealing to have data in an article that could be manipulated dynamically, such as simulation models, molecular interactions, or economic projection models. MIME includes an application content type that will support such mechanisms. Users will need external software (a spreadsheet, for example, or a molecular modeling program), but in many cases such software will be either commonplace within a particular user group, or available in the public domain. The MIME framework, designed as it is to be extensible to arbitrary data types, encourages such developments. MIME will not magically solve all the problems of data conversion and local display. User's systems will still require the appropriate interpreters for converting transmitted data to useful objects locally. But, given a standardized organizing framework such as MIME, and the support of a large user community, the software necessary to support common data exchange will proliferate more quickly and cheaply than otherwise. WHEN WILL IT HAPPEN? MIME has been a proposed Internet standard for only a year, yet there is already growing enthusiasm for the use of this specification to support multimedia mail across hardware platforms. Many vendors, including Microsoft and Sun Microsystems, have announced their intentions to support the MIME specification, but it is likely that they will follow the marketplace rather than lead it. The thrust for interoperable multimedia mail, like that for interoperable open systems in general, is likely to come from user communities. Multimedia mail will become the basis for the development of a more collaborative computing environment. Internet publishers should become strong advocates for adoption of MIME as the basis for their own publishing activities. It is time for the conventional LISTSERV to evolve towards a higher plane, and MIME should be the vehicle for that evolution. WHAT'S MIME IS YOURS You can join the world of MIME messaging now with the help of your local system wizard (that is, if your local system is UNIX, DOS, or Amiga). Nathaniel Borenstein, of Bellcore, has made freely available a generic implementation of MIME called metamail, which, with appropriate patches, will allow the conversion of many standard mail readers into MIME-compliant mail clients. The latest version, metamail 2.6, is available by anonymous ftp from thumper.bellcore.com (Internet address 128.96.41.1) in /pub/nsb. Download the README file and proceed according to the directions. FURTHER INFORMATION: You needn't look far for information on MIME - articles are popping up like mushrooms after a summer rain. A sampling of resources is listed below. ---------------------------- "MIME Overview" Mark Grand Available by anonymous ftp in ASCII text or PostScript format from: adad.premenos.sf.ca.us pub/mime.ps pub/mime.txt An excellent, concise overview of MIME including a top-level, functional description and a nitty-gritty technical summary. ---------------------------- _The Internet Message: Closing the Book with Electronic Mail_ Marshall T. Rose Prentice Hall Englewood Cliffs, New Jersey 07632 1993 ISBN 0-13-092941-7 A good overview of many important issues in electronic mail, including MIME, from one of the old hands of the Internet mail world. ---------------------------- "MIME: A Richer Shade of Mail" Steven Baker _Unix Review_ 11:7 July, 1993 pp 25-34 A well written trade magazine article describing the elements of MIME. ---------------------------- The USENET group, comp.mail.mime, is the major venue for discussion of implementation and technical issues related to MIME. _____ Articles and Sections of this issue of the _Electronic Journal on Virtual Culture_ may be retrieved via anonymous ftp to byrd.mu.wvnet.edu or via e-mail message addressed to LISTSERV@KENTVM or LISTSERV@KENTVM.KENT.EDU (instructions below) Papers may be submitted at anytime by email or send/file to: Ermel Stepp - Editor-in-Chief, _Electronic Journal on Virtual Culture_ M034050@MARSHALL.WVNET.EDU _________________________________ *Copyright Declaration* Copyright of articles published by Electronic Journal on Virtual Culture is held by the author of a given article. If an article is re-published elsewhere it must include a statement that it was originally published by Electronic Journal on Virtual Culture. _________________________________ _THE ELECTRONIC JOURNAL ON VIRTUAL CULTURE_ EDITORIAL BORAD EJVC Founders/Arachnet Moderators Ermel Stepp, Marshall University, Editor-in-Chief M034050@Marshall.wvnet.edu Diane (Di) Kovacs, Kent State University, Co-Editor DKOVACS@Kentvm.Kent.edu A. Ralph Papakhian, Indiana University, Consulting Editor PAPAKHI@@IUBVM Editor, _The Cyberspace Monitor_ Algirdas Pakstas, The University of Trondheim, Norway Algirdas.Pakstas@idt.unit.no Editors, _Virtual Square_ Diane (Di) Kovacs, Kent State University, Co-Editor DKOVACS@Kentvm.Kent.edu James Shimabukuro, University of Hawaii jamess@uhunix.uhcc.Hawaii.Edu Consulting Editors Anne Balsamo, Georgia Institute of Technology ab45@prism.gatech.edu Patrick (Pat) Conner, West Virginia University u47c2@WVNVM.WVNET.EDU Skip Coppola, Applied Technology, Inc. skip%aptech@bagend.atl.ga.us Cynthia J. Fuchs, George Mason University cfuchs@gmuvax.bitnet Stevan Harnad, Princeton University harnad@Princeton.EDU Edward M. (Ted) Jennings, University at Albany, SUNY EMJ69@ALBNYVMS Michael Joyce, Vassar MIJOYCE@vaxsar.vassar.edu or USERTFSG@UMICHUM Jay Lemke, City University of New York JLLBC@CUNYVM.BITNET Carl Eugene Loeffler, Carnegie Mellon University cel+@andrew.cmu.edu Willard McCarty, University of Toronto editor@EPAS.UTORONTO.CA James (Jim) Milles, Saint Louis University millesjg@sluvca.slu.edu Algirdas Pakstas, The University of Trondheim, Norway Algirdas.Pakstas@idt.unit.no A. Ralph Papakhian, Indiana University PAPAKHI@@IUBVM Bernie Sloan, University of Illinois, Champaign AXPBBGS@UICVMC.BITNET or b-sloan@uiuc.edu Allucquere Roseanne Stone, University of Texas, Austin success@emc.cc.utexas.edu Kali Tal, Viet Nam Generation kali@access.digex.com Associate Editors Robert J. (Bob) Beebe, Youngstown State University ad219@yfn.ysu.edu David W. Brown, Ball State University 01dwbrown@LEO.BSUVC.BSU.EDU Kathleen Burnett, Rutgers University BURNET@zodiac.rutgers.edu G. Phillip Cartwight, University of California, Davis PCARTWRI@KENTVM Paulo A. Dasilva, Military Institute of Engineering, Brazil S9PAULO@IMERJ.BITNET Jill Ellsworth, Southwest Texas State University je01@swtexas Jan George Frajkor, Carleton University, Canada gfrajkor@ccs.carleton.ca Dave Gomberg, University of California, San Francisco GOMBERG@UCFSVM Lee Hancock, The University of Kansas Medical Center Le07144@ukanvm Mary Hocks, University of Illinois, Urbana-Champaigne mhocks@ux1.cso.uiuc.edu Nancy Kaplan, University of Texas, Dallas NKaplan@utdallas.bitnet Brendan Kehoe, Cygnus Support bk@well.sf.ca.us Joan Korenman, University of Maryland, Baltimore County korenman@umbc2.umbc.edu or korenman@umbc Steven D. Koski, St. Bonaventure University KOSKI@sbu.edu Sharyn Ladner, University of Miami SLADNER@umiami.IR.miami.EDU Lyonette Louis-Jacques, University of Chicago llou@midway.uchicago.edu Fred Melssen, University of Utrecht F.Melssen@cc.ruu.nl Joseph Psotka, Army Research Institute PSOTKA@alexandria-emh2.army.mil Martin E. Rosenberg, University of Kentucky MROSE01@UKCC.uky.edu Laverna Saunders, University of Nevada, Las Vegas saunders@nevada.edu David Sewell, University of Rochester dsew@TROI.CC.ROCHESTER.EDU James Shimabukuro, University of Hawaii jamess@uhunix.uhcc.Hawaii.Edu Christinger (Chris) Tomer, University of Pittsburgh ctomer@vms.cis.pitt.edu or ctomer+@pitt.edu Stuart Weibel, OCLC stu@oclc.org Bob Zenhausern, St. Johns University drz@sjuvm.stjohns.edu or drz@sjuvm.bitnet ____________________________ Anonymous FTP Instructions ____________________________ ftp byrd.mu.wvnet.edu login anonymous password: users' electronic address cd /pub/ejvc type EJVC.INDEX.FTP get filename (where filename = exact name of file in INDEX) quit LISTSERV Retrieval Instructions _______________________________ Send e-mail addressed to LISTSERV@KENTVM (Bitnet) or LISTSERV@KENTVM.KENT.EDU Leave the subject line empty. The message must read: GET EJVCV1N3 CONTENTS Use this file to identify particular articles or sections then send e-mail to LISTSERV@KENTVM or LISTSERV@KENTVM.KENT.EDU with the command: GET where is the name of the article or section (e.g., author name) and is the V#N# of that issue of EJVC