home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc910 < prev    next >
Text File  |  1991-04-21  |  25KB  |  639 lines

  1.  
  2.  
  3. Network Working Group                                     Harry Forsdick
  4. Request for Comments: 910                               BBN Laboratories
  5.                                                              August 1984
  6.  
  7.  
  8.                      Multimedia Mail Meeting Notes
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This memo is a report on a meeting about the experimental multimedia
  14.    mail system (and in a sense a status report on that experiment).
  15.    Distribution of this memo is unlimited.
  16.  
  17. 1. Introduction
  18.  
  19.    A meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to
  20.    discuss recent progress by groups who are building multimedia mail
  21.    systems and to discuss a variety of issues related to the further
  22.    development of multimedia systems.  Representatives were present from
  23.    BBN, ISI, SRI and Linkabit.  The list of attendees appears at the end
  24.    of this note.
  25.  
  26.    The result of this meeting is a series of agreements that will be
  27.    incorporated in the next set of experiments with multimedia mail as
  28.    well as a set of items for further action.
  29.  
  30.    Note: There are references in this document to notes in a series
  31.    devoted to multimedia mail.  These notes are available on-line in the
  32.    directory [USC-ISIF]<MMM> and have the names MMM-N.TXT where N is the
  33.    note number.  The file MMM-INDEX.TXT is a list of all of the notes in
  34.    the series.  These public files may be copied via FTP using the FTP
  35.    username ANONYMOUS and password GUEST.
  36.  
  37. 2. Review of Status
  38.  
  39.    Status reports on work accomplished in the last year were given by
  40.    each organization.
  41.  
  42. 2.1. BBN
  43.  
  44.    The initial implementation of Diamond is complete and runs on the
  45.    Jericho workstation.  Diamond currently supports the exchange of
  46.    compound documents which contain text, graphics, images, voice and
  47.    spreadsheet/charts.  A demonstration of this system was presented
  48.    showing both the user's view of Diamond messages and message
  49.    management as well as the interactions between the components of this
  50.    distributed system. Diamond currently uses the TOPS-20 implementation
  51.    of MPM for inter-cluster message transport but the plan is to
  52.    integrate an implementation of MPM for the Sun Workstation into
  53.    Diamond.  Current activity is focused on porting Diamond to the Sun
  54.    Workstation.  A first version of Diamond for the Sun is nearly
  55.  
  56.  
  57. Forsdick                                                        [Page 1]
  58.  
  59.  
  60.  
  61. RFC 910                                                      August 1984
  62. Multimedia Mail Meeting Notes
  63.  
  64.  
  65.    completed and parts (the document editor) were demonstrated running
  66.    on the Sun.  Diamond will be used in the ADDCOMPE testbed with
  67.    100-200 users expected in the next year or so.  Future plans include
  68.    building on the experience gained with Diamond in the area of
  69.    multimedia conferencing, extending the use of multimedia into other
  70.    application areas and applying the distributed architecture of
  71.    Diamond to other application areas.
  72.  
  73. 2.2. ISI
  74.  
  75.    A new effort aimed at developing a user interface on a Xerox 1108
  76.    (Dandelion) workstation has just begun.  All of the implementation is
  77.    being done in Interlisp.  Initial work has been done to implement IP
  78.    and TFTP on the 1108 as well as a document editor that makes use of
  79.    the Interlisp-D window system.  Work on the user interface that was
  80.    developed on the Perq will be cycling down.  The implementation of
  81.    the MPM on TOPS-20 is essentially complete with the addition of MPM
  82.    to SMTP mail conversion; no major changes are anticipated.  The
  83.    TOPS-20 MPM will be used as the message transport facility for the
  84.    1108 user interface implementation.  TFTP will be used to get
  85.    messages from the 1108 to the TOPS-20.
  86.  
  87. 2.3. SRI
  88.  
  89.    The SRI multimedia mail system consists of three parts: The
  90.    Multimedia Mail Handler (MMH) which is the user's interface for
  91.    managing mail, the Structure Editor (SE) which is used to view and
  92.    compose multimedia messages and the MPM for mail transport.  This
  93.    system is implemented on the Sun Workstation.  The first release of
  94.    the MPM on the Sun will be ready for distribution at the end of this
  95.    summer.  The SE is used to view and compose structures of multimedia
  96.    objects.  Currently there is support for text, voice and graphics.
  97.  
  98.    Another effort at SRI involves integration of applications to run in
  99.    the ADDCOMPE testbed.  Diamond will be the first example of an
  100.    application which uses multimedia data in the testbed.  SRI is
  101.    interested in examining the issues associated with multimedia systems
  102.    to determine how multimedia data can be used in other applications
  103.    that might be put into the testbed.
  104.  
  105. 2.4. Linkabit
  106.  
  107.    Linkabit has recently received a contract to work on protocol
  108.    evaluation, problems associated with working in a large internet
  109.    environment, and new real-time end-to-end services.  They will be
  110.    working with Sun workstations.  Areas of interest are protocols,
  111.    multimedia conferencing and domains.
  112.  
  113.  
  114.  
  115. Forsdick                                                        [Page 2]
  116.  
  117.  
  118.  
  119. RFC 910                                                      August 1984
  120. Multimedia Mail Meeting Notes
  121.  
  122.  
  123. 3. Discussions and Agreements
  124.  
  125. 3.1. Conversion to the New Multimedia Syntax
  126.  
  127.    There was general agreement that in future experiments we would all
  128.    adopt the revised syntax for multimedia mail as described in the
  129.    Final Report to SRI Project 5363.  It was agreed that RFC767 should
  130.    be revised to reflect these changes.  The timing for switching over
  131.    should be as soon as possible and should be completed by October 1,
  132.    1984.
  133.  
  134. 3.2. Graphics Representation
  135.  
  136.    A wide ranging discussion on the way in which graphics is to be
  137.    represented in multimedia documents occurred.  It was generally
  138.    agreed that the first style of graphical object to be included in
  139.    multimedia messages would be a simple line-drawing, such as those
  140.    that can be produced by the many "draw" programs (e.g. LisaDraw)
  141.    currently in existence.  Attention was focused on the two existing
  142.    standards (ACM-CORE and GKS) and the interim protocol used in the
  143.    Diamond system.  Two major problems with the existing standards were
  144.    mentioned:
  145.  
  146.       o In both ACM-CORE and GKS grouping is inadequate or non-existent.
  147.         This means that it is difficult or impossible to build up a
  148.         composition of several graphical objects and then manipulate
  149.         that composite as a single graphical object.
  150.  
  151.       o Neither ACM-CORE or GKS have specified a standard method for
  152.         representing graphical drawings in memory (e.g. long term file
  153.         storage).  This is one of the most important aspects of a
  154.         graphical standard for multimedia mail.  The focus of graphical
  155.         standards so far has been towards driving devices in a
  156.         independent manner, not storing graphics in a standard
  157.         representation.
  158.  
  159.    A presentation of the representation for graphical objects in Diamond
  160.    was given.  The protocol is documented in MMM-18 and MMM-23.
  161.    Requests for hardcopies of the diagrams in those documents (sigh) can
  162.    be sent to Travers@BBN.
  163.  
  164.    The discussion then focused on the level of effort required to switch
  165.    from one representation to another.  It was generally agreed that
  166.    compared to the entire editor used to manipulate graphical objects
  167.    (e.g., the "draw" program), the part that reads or writes objects
  168.    from or to files is relatively simple.  Most draw programs have a
  169.    unique internal representation which is built when reading the file
  170.    representation and used as the source when writing the file
  171.  
  172.  
  173. Forsdick                                                        [Page 3]
  174.  
  175.  
  176.  
  177. RFC 910                                                      August 1984
  178. Multimedia Mail Meeting Notes
  179.  
  180.  
  181.    representation.  It is this relatively small portion of a graphics
  182.    editor which is impacted by switching from one file representation to
  183.    another.  Thus it seemed that the approach of adopting one interim
  184.    representation now and planning to switch to a standard
  185.    representation when work on the standards solve the problems noted
  186.    above was reasonable.
  187.  
  188.    After considerable examination of the issues, the following decisions
  189.    were reached:
  190.  
  191.       1. The representation for graphics used in Diamond and documented
  192.          in MMM-18 and MMM-23 will be adopted as an interim
  193.          representation for graphics in multimedia mail.  It will be
  194.          known as the MMGraphics1 protocol.
  195.  
  196.       2. We will actively track development of the GKS standard and also
  197.          examine a GKS-subset that has been developed by Sandia Labs.
  198.  
  199.       3. We agreed to settle on an adopted international standard
  200.          eventually.
  201.  
  202. 3.3. Document Presentation Semantics
  203.  
  204.    There was a presentation of the ideas contained in MMM-22: "A Format
  205.    for the Construction of Multimedia Messages".  The resulting
  206.    discussion addressed the following issues:
  207.  
  208.       o Presentation of documents on display devices with different
  209.         characteristics (dimensions, resolutions, available fonts,
  210.         etc.).
  211.  
  212.          The essence of the conversation was that there is no single set
  213.          of fonts, or page sizes that will cover all of the
  214.          possibilities. There was a strong feeling that as long as the
  215.          display surface was of reasonable size that a document should
  216.          be presented in a "correctly" formatted manner.  Rather than
  217.          the originator of a document specifying hard page boundaries,
  218.          the intent of the originator regarding formatting and grouping
  219.          of objects in the document should be preserved and used when
  220.          the document is actually presented on a display device.  A
  221.          window on a bitmap display and a hardcopy page printer are both
  222.          examples of display devices.
  223.  
  224.       o The desire to represent the kinds of documents that currently
  225.         exist in the world of hardcopy as well as to represent documents
  226.         that can take advantage of the new possibilities of electronic
  227.         creation, storage and presentation.
  228.  
  229.  
  230.  
  231. Forsdick                                                        [Page 4]
  232.  
  233.  
  234.  
  235. RFC 910                                                      August 1984
  236. Multimedia Mail Meeting Notes
  237.  
  238.  
  239.    Several points were made:
  240.  
  241.       1. One of the first goals for multimedia systems should be to
  242.          represent the types of documents that are prevalent in the
  243.          hardcopy world.  People are already familiar with these
  244.          documents and will expect multimedia systems to, at least, be
  245.          able to deal with them.
  246.  
  247.       2. In an effort to provide the capabilities of electronically
  248.          originated documents based on the hardcopy model of documents,
  249.          we should not eliminate the great potential of electronic
  250.          documents that have much greater reactive qualities.  For
  251.          example, a document where a graphical figure and a textual
  252.          explanation of that figure are linked so that as long as the
  253.          explanation is being read the figure is visible.
  254.  
  255.       3. In many situations being able to carry away a paper copy of a
  256.          document is a requirement even if the document was not
  257.          primarily intended to be presented in hardcopy.
  258.  
  259.    The following agreements were made:
  260.  
  261.       1. A method for recording the author's intent regarding the
  262.          presentation of a document should be developed.  This
  263.          representation would defer decisions on final presentation
  264.          bindings of size, resolution and fonts to the reader's document
  265.          presenter.
  266.  
  267.          Topics addressed by this representation will include:
  268.  
  269.             o Grouping of objects
  270.  
  271.             o Limited Font attributes (e.g., normal, bold, italic)
  272.  
  273.             o Headings, Footings
  274.  
  275.             o Sectioning
  276.  
  277.          Of course the reader's document presenter is free to ignore any
  278.          of the author's intentions it cannot deal with.  The point of
  279.          this representation is to record the author's desires but to
  280.          defer final decisions on how to use the intentions until the
  281.          capabilities of the reader are known.
  282.  
  283.          This representation will lie some where between the rather
  284.          loose spatial and temporal positioning commands currently in
  285.          the protocol (Sequential, Simultaneous and Independent) and the
  286.  
  287.  
  288.  
  289. Forsdick                                                        [Page 5]
  290.  
  291.  
  292.  
  293. RFC 910                                                      August 1984
  294. Multimedia Mail Meeting Notes
  295.  
  296.  
  297.          absolute positioning of a system that defines rigid page
  298.          boundaries and absolute positions for object placement on a
  299.          page.
  300.  
  301.       2. We will NOT try to make this representation handle all of the
  302.          issues addressed by modern document formatting systems.
  303.          Instead we will skim off some of the most useful ideas but
  304.          perhaps limit the flexibility present in these complex
  305.          formatting systems.
  306.  
  307.       3. The document representation will be able to describe
  308.          relationships between objects that make use of the capabilities
  309.          of electronic document presentation, such as simultaneous
  310.          presentation (i.e., two objects which are visible at the same
  311.          time) and overlay presentation (i.e., two (possibly
  312.          transparent) objects which occupy the same area in a document,
  313.          which may also be separated under viewer control).
  314.  
  315.       4. Methods should be developed for all aspects of the document
  316.          representation for presenting the document in a hardcopy form.
  317.          This applies both electronic documents that fit the tradition
  318.          hardcopy model as well as those that make use of the more
  319.          reactive features of the representation.
  320.  
  321. 3.4. Directory Service
  322.  
  323.    There is an increasing need to be able to determine attributes of
  324.    users, hosts and domains throughout the DARPA Internet.  For example,
  325.    when composing the header fields of a message it is useful to be able
  326.    to inquire about the mail box location of a person to whom the
  327.    message is addressed. Likewise, there is need to determine the
  328.    services provided by a host so that requests that will never be
  329.    satisfied can be avoided.
  330.  
  331.    The feeling of the group was that work on the Internet Domain system
  332.    (being done at ISI and Berkeley) would answer some of these problems
  333.    and that we should examine the design documents to see how that
  334.    system might help us (see RFCs 882 and 883).  The WhoIs server is
  335.    useful, but only for information about the text mail box of a person
  336.    (see RFC812).
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347. Forsdick                                                        [Page 6]
  348.  
  349.  
  350.  
  351. RFC 910                                                      August 1984
  352. Multimedia Mail Meeting Notes
  353.  
  354.  
  355. 3.5. New Media Types
  356.  
  357.    The discussion dealt with three topics:  A proposal for a new media
  358.    type, ideas for other new media types and provisions for dealing with
  359.    unknown media types.
  360.  
  361.    A description of the Diamond SpreadSheet/Chart media type was
  362.    presented.  This is documented in MMM-24.  In this media it is
  363.    possible to represent a table containing numbers, labels, dates and
  364.    formulas.  A unique attribute of this media type is that the
  365.    spreadsheet model as well as the data are transmitted.  The reader of
  366.    a document containing a spreadsheet object can test what effect
  367.    different data would have on conclusions suggested by the spreadsheet
  368.    object.  A spreadsheet may appear as a table and/or one of several
  369.    alternative business charts (line graph, scatter graph, bar chart or
  370.    pie chart).  Rulings may be added to the tabular representation so
  371.    that it is possible to achieve the appearance of sophisticated
  372.    tabular data presentation.  During the discussion, the point was made
  373.    that a minimal implementation of the spreadsheet object could ignore
  374.    the formulas and just present the values of the cells, thus allowing
  375.    a minimal presentation of the tabular and chart information.
  376.  
  377.    Ideas for new media types included:
  378.  
  379.       Form
  380.  
  381.          A set of fields which are Name-Value pairs.  Forms can be used
  382.          for presentation and/or acceptance of information. The act of
  383.          filling out a form might be used (under user approval) to
  384.          trigger sending the completed form to the appropriate person
  385.          who handles such forms.
  386.  
  387.       Animated Graphics
  388.  
  389.          A line drawing that has temporal information encoded in the
  390.          presentation of its components.  The idea is that parts of a
  391.          graphics object could move about the object during its
  392.          presentation.  For example, an arrow could move about a map
  393.          showing a route to be followed.  There was some discussion
  394.          about how this would interact with other media.  For example,
  395.          how could an arrow moving about a map be coordinated with voice
  396.          instructions on how to get from one place to another.  There
  397.          were no decisions about how best to accomplish this.
  398.  
  399.    Finally, we agreed that all of our systems should be prepared to
  400.    accept (and possibly ignore) media types that are not currently
  401.    implemented.  The common way of dealing with this is to include a
  402.    statement of the form "An object of type <Type> appears here".  With
  403.  
  404.  
  405. Forsdick                                                        [Page 7]
  406.  
  407.  
  408.  
  409. RFC 910                                                      August 1984
  410. Multimedia Mail Meeting Notes
  411.  
  412.  
  413.    the regularized syntax that has been adopted many of the common
  414.    attributes of all object types will be able to be understood but the
  415.    actual type may not be implemented.  In Diamond we would like to use
  416.    the MPM to transfer Diamond messages between Diamond and non-Diamond
  417.    clusters.  Currently if we were to include a spreadsheet in one of
  418.    these messages, all of the other implementations of multimedia mail
  419.    would probably end in the debugger when they went to process our
  420.    messages, rather than indicate that there was something that they
  421.    didn't quite understand.
  422.  
  423. 3.6. MPM Support
  424.  
  425.    By the end of the summer there will be two implementation of the MPM:
  426.    on TOPS-20 and on the Sun Workstation.  We agreed to try to set up
  427.    the following operational MPMs:
  428.  
  429.       Organization  Host          MPM Implementation
  430.  
  431.       ISI           ISIF          TOPS-20
  432.       ISI           ISIB          TOPS-20
  433.       SRI           ?             Sun Workstation
  434.       BBN           ?             Sun Workstation
  435.       DARPA         ?             Sun Workstation
  436.       Linkabit      DCN6          Sun Workstation
  437.  
  438.    The idea behind this agreement is to get wide geographic coverage to
  439.    allow us to use multimedia mail on a regular basis and to test the
  440.    impact of realistic use of multiple communicating MPMs using the
  441.    Internet.
  442.  
  443. 3.7. Floating Point Data Type
  444.  
  445.    In the representation for data defined in RFC759, there is no way to
  446.    represent floating point numbers.  We agreed that a new data type
  447.    should be added, called Float64 which is the 64-bit IEEE standard
  448.    floating point number representation.
  449.  
  450. 3.8. Captions
  451.  
  452.    The idea of including a text caption as an optional property of every
  453.    object was discussed.  There are several uses of such a caption:
  454.  
  455.       o For media like voice which do not have an implicit visual
  456.         representation, it is useful to include a caption indicating
  457.         something about the object.  This caption can serve as a visual
  458.         indication of the presence of the non-visual object.
  459.  
  460.  
  461.  
  462.  
  463. Forsdick                                                        [Page 8]
  464.  
  465.  
  466.  
  467. RFC 910                                                      August 1984
  468. Multimedia Mail Meeting Notes
  469.  
  470.  
  471.       o When an implementation of a multimedia message system doesn't
  472.         support a given media type, it can be useful to give some
  473.         information about the object in the form of a text passage.
  474.  
  475.       o In some situations, it is important to present an outline of a
  476.         document.  Captions associated with each object could be used to
  477.         generate a shortened abstract of the document.
  478.  
  479.    We agreed to add to all object types an optional property whose name
  480.    is "Caption" and whose value is of type Text String.
  481.  
  482. 3.9. More Users of Multimedia Mail
  483.  
  484.    We need to increase the use of multimedia mail to gain more
  485.    experience with issues that need attention.  This can be done by:
  486.  
  487.       o Encouraging more sites to participate in the experiments.  There
  488.         are several possible sites which have Sun workstations that
  489.         could be configured to run an MPM and one of the multimedia
  490.         message systems.
  491.  
  492.       o Making the MPMs perform translations to and from SMTP text-only
  493.         mail.  At BBN, the Diamond Import/Export component performs
  494.         translations in both directions and this has proved very useful
  495.         in testing the operation of our system.  In addition, the
  496.         inclusion of statements such as <Graphics appears here> might
  497.         spark interest from text-only mail recipients, although care
  498.         should be taken not to offend anybody with this kind of "class
  499.         differentiation".
  500.  
  501.    To the extent possible, the Sun Workstation MPM will be modified to
  502.    perform translations to and from SMTP mail.  The TOPS-20 MPM already
  503.    does the translation from multimedia mail to text-only mail.  It may
  504.    be possible to add translation in the other direction.
  505.  
  506. 3.10. Multimedia Exploder Mailing List
  507.  
  508.    A mailing list devoted to Multimedia Mail will be set up at ISI.
  509.    This will be of the "exploding" variety so that sending a message to
  510.    the list will cause everybody on the list to receive a copy.  To get
  511.    on or off the list send a note to MMM-People-Request@USC-ISIF.ARPA.
  512.    The exploder mailbox is MMM-People@USC-ISIF.ARPA.
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521. Forsdick                                                        [Page 9]
  522.  
  523.  
  524.  
  525. RFC 910                                                      August 1984
  526. Multimedia Mail Meeting Notes
  527.  
  528.  
  529. 3.11. Next Experiment
  530.  
  531.    The next experiment will be in January 1985.  At that time we will
  532.    try to demonstrate the following new features:
  533.  
  534.       o Use of the revised multimedia syntax described in section 3.1.
  535.  
  536.       o Inclusion of Graphics objects, in addition to Text, Images and
  537.         Voice.
  538.  
  539.       o Use of the, as yet unspecified, document presentation semantics
  540.         described in section 3.3.
  541.  
  542.       o Use of the Sun Workstation MPMs.
  543.  
  544. 4. Further Actions
  545.  
  546.    Several of the agreements reached require further action.  I have
  547.    added dates which seem reasonable.
  548.  
  549.       Revision of RFC759 to include Float64 data type.
  550.       Person:  Greg Finn and Jon Postel.
  551.       Due Date: 1 September 84.
  552.  
  553.       Conversion to the new Multimedia Syntax
  554.       Person:  All groups.
  555.       Due Date: 1 September 84.
  556.  
  557.       Revision of RFC767 to reflect revised Multimedia Syntax and
  558.       optional Caption property
  559.       Person:  Jose Garcia-Luna and Jon Postel
  560.       Due Date: 1 October 84.
  561.  
  562.       Specification of Document Presentation Semantics (Section 3.3)
  563.       Person:  Harry Forsdick
  564.       Due Date: 1 October 84.
  565.  
  566.       Acquisition of GKS and GKS-subset documentation
  567.       Person:  Lou Schreier
  568.       Due Date: 1 September 84
  569.  
  570.       Completion of initial implementation of Sun Workstation MPM
  571.       Person:  Andy Poggio
  572.       Due Date: 15 September 84
  573.  
  574.       Multimedia Exploder Mailing List
  575.       Person:  Greg Finn
  576.       Due Date: 15 August 84       < COMPLETED >
  577.  
  578.  
  579. Forsdick                                                       [Page 10]
  580.  
  581.  
  582.  
  583. RFC 910                                                      August 1984
  584. Multimedia Mail Meeting Notes
  585.  
  586.  
  587.       Addition of MPM<==>SMTP translation logic to Sun Workstation MPM
  588.       Person:  Mike O'Connor
  589.       Due Date: 1 November 84
  590.  
  591.       Demonstrate Text-Graphics-Image-Voice Document Exchange
  592.       Person:  All
  593.       Due Date: January 85
  594.  
  595. 5. Attendees
  596.  
  597.    Harry Forsdick     BBN       Forsdick@BBN       (617) 497-3638
  598.    David L. Mills     Linkabit  Mills@ISID         (703) 734-9000
  599.    Louis Schreier     SRI       Schreier@SRI-SPAM  (415) 326-6200
  600.    Philip Au          SRI       Psa@SRI-SPAM       (415) 326-6200
  601.    Greg Finn          ISI       Finn@ISIF          (213) 822-1511
  602.    Mike O'Connor      Linkabit  OConnor@DCN9       (703) 734-9000
  603.    Ray Tomlinson      BBN       Tomlinson@BBN      (617) 497-3363
  604.    Ginny Travers      BBN       Travers@BBN        (617) 497-2647
  605.    Terry Crowley      BBN       TCrowley@BBN       (617) 497-2677
  606.    Andy Poggio        SRI       Poggio@SRI-TSC     (415) 859-5094
  607.    Jose Garcia-Luna   SRI       Garcia@SRI-TSC     (415) 859-5647
  608.    George Robertson   BBN       GRobertson@BBN     (617) 497-3632
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637. Forsdick                                                       [Page 11]
  638.  
  639.