From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc910.txt | 638 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 638 insertions(+) create mode 100644 doc/rfc/rfc910.txt (limited to 'doc/rfc/rfc910.txt') diff --git a/doc/rfc/rfc910.txt b/doc/rfc/rfc910.txt new file mode 100644 index 0000000..815096c --- /dev/null +++ b/doc/rfc/rfc910.txt @@ -0,0 +1,638 @@ + + +Network Working Group Harry Forsdick +Request for Comments: 910 BBN Laboratories + August 1984 + + + Multimedia Mail Meeting Notes + + +Status of this Memo + + This memo is a report on a meeting about the experimental multimedia + mail system (and in a sense a status report on that experiment). + Distribution of this memo is unlimited. + +1. Introduction + + A meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to + discuss recent progress by groups who are building multimedia mail + systems and to discuss a variety of issues related to the further + development of multimedia systems. Representatives were present from + BBN, ISI, SRI and Linkabit. The list of attendees appears at the end + of this note. + + The result of this meeting is a series of agreements that will be + incorporated in the next set of experiments with multimedia mail as + well as a set of items for further action. + + Note: There are references in this document to notes in a series + devoted to multimedia mail. These notes are available on-line in the + directory [USC-ISIF] and have the names MMM-N.TXT where N is the + note number. The file MMM-INDEX.TXT is a list of all of the notes in + the series. These public files may be copied via FTP using the FTP + username ANONYMOUS and password GUEST. + +2. Review of Status + + Status reports on work accomplished in the last year were given by + each organization. + +2.1. BBN + + The initial implementation of Diamond is complete and runs on the + Jericho workstation. Diamond currently supports the exchange of + compound documents which contain text, graphics, images, voice and + spreadsheet/charts. A demonstration of this system was presented + showing both the user's view of Diamond messages and message + management as well as the interactions between the components of this + distributed system. Diamond currently uses the TOPS-20 implementation + of MPM for inter-cluster message transport but the plan is to + integrate an implementation of MPM for the Sun Workstation into + Diamond. Current activity is focused on porting Diamond to the Sun + Workstation. A first version of Diamond for the Sun is nearly + + +Forsdick [Page 1] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + + completed and parts (the document editor) were demonstrated running + on the Sun. Diamond will be used in the ADDCOMPE testbed with + 100-200 users expected in the next year or so. Future plans include + building on the experience gained with Diamond in the area of + multimedia conferencing, extending the use of multimedia into other + application areas and applying the distributed architecture of + Diamond to other application areas. + +2.2. ISI + + A new effort aimed at developing a user interface on a Xerox 1108 + (Dandelion) workstation has just begun. All of the implementation is + being done in Interlisp. Initial work has been done to implement IP + and TFTP on the 1108 as well as a document editor that makes use of + the Interlisp-D window system. Work on the user interface that was + developed on the Perq will be cycling down. The implementation of + the MPM on TOPS-20 is essentially complete with the addition of MPM + to SMTP mail conversion; no major changes are anticipated. The + TOPS-20 MPM will be used as the message transport facility for the + 1108 user interface implementation. TFTP will be used to get + messages from the 1108 to the TOPS-20. + +2.3. SRI + + The SRI multimedia mail system consists of three parts: The + Multimedia Mail Handler (MMH) which is the user's interface for + managing mail, the Structure Editor (SE) which is used to view and + compose multimedia messages and the MPM for mail transport. This + system is implemented on the Sun Workstation. The first release of + the MPM on the Sun will be ready for distribution at the end of this + summer. The SE is used to view and compose structures of multimedia + objects. Currently there is support for text, voice and graphics. + + Another effort at SRI involves integration of applications to run in + the ADDCOMPE testbed. Diamond will be the first example of an + application which uses multimedia data in the testbed. SRI is + interested in examining the issues associated with multimedia systems + to determine how multimedia data can be used in other applications + that might be put into the testbed. + +2.4. Linkabit + + Linkabit has recently received a contract to work on protocol + evaluation, problems associated with working in a large internet + environment, and new real-time end-to-end services. They will be + working with Sun workstations. Areas of interest are protocols, + multimedia conferencing and domains. + + + +Forsdick [Page 2] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + +3. Discussions and Agreements + +3.1. Conversion to the New Multimedia Syntax + + There was general agreement that in future experiments we would all + adopt the revised syntax for multimedia mail as described in the + Final Report to SRI Project 5363. It was agreed that RFC767 should + be revised to reflect these changes. The timing for switching over + should be as soon as possible and should be completed by October 1, + 1984. + +3.2. Graphics Representation + + A wide ranging discussion on the way in which graphics is to be + represented in multimedia documents occurred. It was generally + agreed that the first style of graphical object to be included in + multimedia messages would be a simple line-drawing, such as those + that can be produced by the many "draw" programs (e.g. LisaDraw) + currently in existence. Attention was focused on the two existing + standards (ACM-CORE and GKS) and the interim protocol used in the + Diamond system. Two major problems with the existing standards were + mentioned: + + o In both ACM-CORE and GKS grouping is inadequate or non-existent. + This means that it is difficult or impossible to build up a + composition of several graphical objects and then manipulate + that composite as a single graphical object. + + o Neither ACM-CORE or GKS have specified a standard method for + representing graphical drawings in memory (e.g. long term file + storage). This is one of the most important aspects of a + graphical standard for multimedia mail. The focus of graphical + standards so far has been towards driving devices in a + independent manner, not storing graphics in a standard + representation. + + A presentation of the representation for graphical objects in Diamond + was given. The protocol is documented in MMM-18 and MMM-23. + Requests for hardcopies of the diagrams in those documents (sigh) can + be sent to Travers@BBN. + + The discussion then focused on the level of effort required to switch + from one representation to another. It was generally agreed that + compared to the entire editor used to manipulate graphical objects + (e.g., the "draw" program), the part that reads or writes objects + from or to files is relatively simple. Most draw programs have a + unique internal representation which is built when reading the file + representation and used as the source when writing the file + + +Forsdick [Page 3] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + + representation. It is this relatively small portion of a graphics + editor which is impacted by switching from one file representation to + another. Thus it seemed that the approach of adopting one interim + representation now and planning to switch to a standard + representation when work on the standards solve the problems noted + above was reasonable. + + After considerable examination of the issues, the following decisions + were reached: + + 1. The representation for graphics used in Diamond and documented + in MMM-18 and MMM-23 will be adopted as an interim + representation for graphics in multimedia mail. It will be + known as the MMGraphics1 protocol. + + 2. We will actively track development of the GKS standard and also + examine a GKS-subset that has been developed by Sandia Labs. + + 3. We agreed to settle on an adopted international standard + eventually. + +3.3. Document Presentation Semantics + + There was a presentation of the ideas contained in MMM-22: "A Format + for the Construction of Multimedia Messages". The resulting + discussion addressed the following issues: + + o Presentation of documents on display devices with different + characteristics (dimensions, resolutions, available fonts, + etc.). + + The essence of the conversation was that there is no single set + of fonts, or page sizes that will cover all of the + possibilities. There was a strong feeling that as long as the + display surface was of reasonable size that a document should + be presented in a "correctly" formatted manner. Rather than + the originator of a document specifying hard page boundaries, + the intent of the originator regarding formatting and grouping + of objects in the document should be preserved and used when + the document is actually presented on a display device. A + window on a bitmap display and a hardcopy page printer are both + examples of display devices. + + o The desire to represent the kinds of documents that currently + exist in the world of hardcopy as well as to represent documents + that can take advantage of the new possibilities of electronic + creation, storage and presentation. + + + +Forsdick [Page 4] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + + Several points were made: + + 1. One of the first goals for multimedia systems should be to + represent the types of documents that are prevalent in the + hardcopy world. People are already familiar with these + documents and will expect multimedia systems to, at least, be + able to deal with them. + + 2. In an effort to provide the capabilities of electronically + originated documents based on the hardcopy model of documents, + we should not eliminate the great potential of electronic + documents that have much greater reactive qualities. For + example, a document where a graphical figure and a textual + explanation of that figure are linked so that as long as the + explanation is being read the figure is visible. + + 3. In many situations being able to carry away a paper copy of a + document is a requirement even if the document was not + primarily intended to be presented in hardcopy. + + The following agreements were made: + + 1. A method for recording the author's intent regarding the + presentation of a document should be developed. This + representation would defer decisions on final presentation + bindings of size, resolution and fonts to the reader's document + presenter. + + Topics addressed by this representation will include: + + o Grouping of objects + + o Limited Font attributes (e.g., normal, bold, italic) + + o Headings, Footings + + o Sectioning + + Of course the reader's document presenter is free to ignore any + of the author's intentions it cannot deal with. The point of + this representation is to record the author's desires but to + defer final decisions on how to use the intentions until the + capabilities of the reader are known. + + This representation will lie some where between the rather + loose spatial and temporal positioning commands currently in + the protocol (Sequential, Simultaneous and Independent) and the + + + +Forsdick [Page 5] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + + absolute positioning of a system that defines rigid page + boundaries and absolute positions for object placement on a + page. + + 2. We will NOT try to make this representation handle all of the + issues addressed by modern document formatting systems. + Instead we will skim off some of the most useful ideas but + perhaps limit the flexibility present in these complex + formatting systems. + + 3. The document representation will be able to describe + relationships between objects that make use of the capabilities + of electronic document presentation, such as simultaneous + presentation (i.e., two objects which are visible at the same + time) and overlay presentation (i.e., two (possibly + transparent) objects which occupy the same area in a document, + which may also be separated under viewer control). + + 4. Methods should be developed for all aspects of the document + representation for presenting the document in a hardcopy form. + This applies both electronic documents that fit the tradition + hardcopy model as well as those that make use of the more + reactive features of the representation. + +3.4. Directory Service + + There is an increasing need to be able to determine attributes of + users, hosts and domains throughout the DARPA Internet. For example, + when composing the header fields of a message it is useful to be able + to inquire about the mail box location of a person to whom the + message is addressed. Likewise, there is need to determine the + services provided by a host so that requests that will never be + satisfied can be avoided. + + The feeling of the group was that work on the Internet Domain system + (being done at ISI and Berkeley) would answer some of these problems + and that we should examine the design documents to see how that + system might help us (see RFCs 882 and 883). The WhoIs server is + useful, but only for information about the text mail box of a person + (see RFC812). + + + + + + + + + + +Forsdick [Page 6] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + +3.5. New Media Types + + The discussion dealt with three topics: A proposal for a new media + type, ideas for other new media types and provisions for dealing with + unknown media types. + + A description of the Diamond SpreadSheet/Chart media type was + presented. This is documented in MMM-24. In this media it is + possible to represent a table containing numbers, labels, dates and + formulas. A unique attribute of this media type is that the + spreadsheet model as well as the data are transmitted. The reader of + a document containing a spreadsheet object can test what effect + different data would have on conclusions suggested by the spreadsheet + object. A spreadsheet may appear as a table and/or one of several + alternative business charts (line graph, scatter graph, bar chart or + pie chart). Rulings may be added to the tabular representation so + that it is possible to achieve the appearance of sophisticated + tabular data presentation. During the discussion, the point was made + that a minimal implementation of the spreadsheet object could ignore + the formulas and just present the values of the cells, thus allowing + a minimal presentation of the tabular and chart information. + + Ideas for new media types included: + + Form + + A set of fields which are Name-Value pairs. Forms can be used + for presentation and/or acceptance of information. The act of + filling out a form might be used (under user approval) to + trigger sending the completed form to the appropriate person + who handles such forms. + + Animated Graphics + + A line drawing that has temporal information encoded in the + presentation of its components. The idea is that parts of a + graphics object could move about the object during its + presentation. For example, an arrow could move about a map + showing a route to be followed. There was some discussion + about how this would interact with other media. For example, + how could an arrow moving about a map be coordinated with voice + instructions on how to get from one place to another. There + were no decisions about how best to accomplish this. + + Finally, we agreed that all of our systems should be prepared to + accept (and possibly ignore) media types that are not currently + implemented. The common way of dealing with this is to include a + statement of the form "An object of type appears here". With + + +Forsdick [Page 7] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + + the regularized syntax that has been adopted many of the common + attributes of all object types will be able to be understood but the + actual type may not be implemented. In Diamond we would like to use + the MPM to transfer Diamond messages between Diamond and non-Diamond + clusters. Currently if we were to include a spreadsheet in one of + these messages, all of the other implementations of multimedia mail + would probably end in the debugger when they went to process our + messages, rather than indicate that there was something that they + didn't quite understand. + +3.6. MPM Support + + By the end of the summer there will be two implementation of the MPM: + on TOPS-20 and on the Sun Workstation. We agreed to try to set up + the following operational MPMs: + + Organization Host MPM Implementation + + ISI ISIF TOPS-20 + ISI ISIB TOPS-20 + SRI ? Sun Workstation + BBN ? Sun Workstation + DARPA ? Sun Workstation + Linkabit DCN6 Sun Workstation + + The idea behind this agreement is to get wide geographic coverage to + allow us to use multimedia mail on a regular basis and to test the + impact of realistic use of multiple communicating MPMs using the + Internet. + +3.7. Floating Point Data Type + + In the representation for data defined in RFC759, there is no way to + represent floating point numbers. We agreed that a new data type + should be added, called Float64 which is the 64-bit IEEE standard + floating point number representation. + +3.8. Captions + + The idea of including a text caption as an optional property of every + object was discussed. There are several uses of such a caption: + + o For media like voice which do not have an implicit visual + representation, it is useful to include a caption indicating + something about the object. This caption can serve as a visual + indication of the presence of the non-visual object. + + + + +Forsdick [Page 8] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + + o When an implementation of a multimedia message system doesn't + support a given media type, it can be useful to give some + information about the object in the form of a text passage. + + o In some situations, it is important to present an outline of a + document. Captions associated with each object could be used to + generate a shortened abstract of the document. + + We agreed to add to all object types an optional property whose name + is "Caption" and whose value is of type Text String. + +3.9. More Users of Multimedia Mail + + We need to increase the use of multimedia mail to gain more + experience with issues that need attention. This can be done by: + + o Encouraging more sites to participate in the experiments. There + are several possible sites which have Sun workstations that + could be configured to run an MPM and one of the multimedia + message systems. + + o Making the MPMs perform translations to and from SMTP text-only + mail. At BBN, the Diamond Import/Export component performs + translations in both directions and this has proved very useful + in testing the operation of our system. In addition, the + inclusion of statements such as might + spark interest from text-only mail recipients, although care + should be taken not to offend anybody with this kind of "class + differentiation". + + To the extent possible, the Sun Workstation MPM will be modified to + perform translations to and from SMTP mail. The TOPS-20 MPM already + does the translation from multimedia mail to text-only mail. It may + be possible to add translation in the other direction. + +3.10. Multimedia Exploder Mailing List + + A mailing list devoted to Multimedia Mail will be set up at ISI. + This will be of the "exploding" variety so that sending a message to + the list will cause everybody on the list to receive a copy. To get + on or off the list send a note to MMM-People-Request@USC-ISIF.ARPA. + The exploder mailbox is MMM-People@USC-ISIF.ARPA. + + + + + + + + +Forsdick [Page 9] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + +3.11. Next Experiment + + The next experiment will be in January 1985. At that time we will + try to demonstrate the following new features: + + o Use of the revised multimedia syntax described in section 3.1. + + o Inclusion of Graphics objects, in addition to Text, Images and + Voice. + + o Use of the, as yet unspecified, document presentation semantics + described in section 3.3. + + o Use of the Sun Workstation MPMs. + +4. Further Actions + + Several of the agreements reached require further action. I have + added dates which seem reasonable. + + Revision of RFC759 to include Float64 data type. + Person: Greg Finn and Jon Postel. + Due Date: 1 September 84. + + Conversion to the new Multimedia Syntax + Person: All groups. + Due Date: 1 September 84. + + Revision of RFC767 to reflect revised Multimedia Syntax and + optional Caption property + Person: Jose Garcia-Luna and Jon Postel + Due Date: 1 October 84. + + Specification of Document Presentation Semantics (Section 3.3) + Person: Harry Forsdick + Due Date: 1 October 84. + + Acquisition of GKS and GKS-subset documentation + Person: Lou Schreier + Due Date: 1 September 84 + + Completion of initial implementation of Sun Workstation MPM + Person: Andy Poggio + Due Date: 15 September 84 + + Multimedia Exploder Mailing List + Person: Greg Finn + Due Date: 15 August 84 < COMPLETED > + + +Forsdick [Page 10] + + + +RFC 910 August 1984 +Multimedia Mail Meeting Notes + + + Addition of MPM<==>SMTP translation logic to Sun Workstation MPM + Person: Mike O'Connor + Due Date: 1 November 84 + + Demonstrate Text-Graphics-Image-Voice Document Exchange + Person: All + Due Date: January 85 + +5. Attendees + + Harry Forsdick BBN Forsdick@BBN (617) 497-3638 + David L. Mills Linkabit Mills@ISID (703) 734-9000 + Louis Schreier SRI Schreier@SRI-SPAM (415) 326-6200 + Philip Au SRI Psa@SRI-SPAM (415) 326-6200 + Greg Finn ISI Finn@ISIF (213) 822-1511 + Mike O'Connor Linkabit OConnor@DCN9 (703) 734-9000 + Ray Tomlinson BBN Tomlinson@BBN (617) 497-3363 + Ginny Travers BBN Travers@BBN (617) 497-2647 + Terry Crowley BBN TCrowley@BBN (617) 497-2677 + Andy Poggio SRI Poggio@SRI-TSC (415) 859-5094 + Jose Garcia-Luna SRI Garcia@SRI-TSC (415) 859-5647 + George Robertson BBN GRobertson@BBN (617) 497-3632 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Forsdick [Page 11] + -- cgit v1.2.3