rfc910.txt

RFC 的详细文档！

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]<MMM> 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.