rfc910.txt

RFC 相关的技术文档

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 <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 <Graphics appears here> 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 [e-mail].
   The exploder mailbox is [e-mail].








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       [phone]
   David L. Mills     Linkabit  Mills@ISID         [phone]
   Louis Schreier     SRI       Schreier@SRI-SPAM  [phone]
   Philip Au          SRI       Psa@SRI-SPAM       [phone]
   Greg Finn          ISI       Finn@ISIF          [phone]
   Mike O'Connor      Linkabit  OConnor@DCN9       [phone]
   Ray Tomlinson      BBN       Tomlinson@BBN      [phone]
   Ginny Travers      BBN       Travers@BBN        [phone]
   Terry Crowley      BBN       TCrowley@BBN       [phone]
   Andy Poggio        SRI       Poggio@SRI-TSC     [phone]
   Jose Garcia-Luna   SRI       Garcia@SRI-TSC     [phone]
   George Robertson   BBN       GRobertson@BBN     [phone]




























Forsdick                                                       [Page 11]