rfc965.txt

RFC 相关的技术文档

Network Working Group                                    Lorenzo Aguilar
Request for Comments: 965                              SRI International
                                                           December 1985

            A Format for a Graphical Communication Protocol


STATUS OF THIS MEMO

   This paper describes the requirements for a graphical format on which
   to base a graphical on-line communication protocol.  The proposal is
   an Interactive Graphical Communication Format using the GKSM session
   metafile.  Distribution of this memo is unlimited.

ABSTRACT

   This paper describes the requirements for a graphical format on which
   to base a graphical on-line communication protocol. It is argued that
   on-line graphical communication is similar to graphical session
   capture, and thus we propose an Interactive Graphical Communication
   Format using the GKSM session metafile.

   We discuss the items that we believe complement the GKSM metafile as
   a format for on-line interactive exchanges. One key application area
   of such a format is multi-media on-line conferencing; therefore, we
   present a conferencing software architecture for processing the
   proposed format. We make this format specification available to those
   planning multi-media conferencing systems as a contribution toward
   the development of a graphical communication protocol that will
   permit the interoperation of these systems.

   We hope this contribution will encourage the discussion of multimedia
   data exchange and the proposal of solutions. At SRI, we stay open to
   the exploration of alternatives and we will continue our research and
   development work in this problem area.

ACKNOWLEDGEMENTS

   The author wants to thank Andy Poggio of SRI who made many insightful
   and valuable suggestions that trimmed and improved level U. His
   expertise in multi-media communication systems and his encouragement
   were a most positive input to the creation of this IGCF. Dave
   Worthington of SRI also participated in the project discussions
   involving this IGCF. Thanks are also due to Tom Powers, chairman of
   ANSI X3H33, who opened this forum to the presentation of an earlier
   version of this paper, thereby providing an opportunity for the
   invaluable feedback of the X3H33 members. Jon Postel of ISI
   recommended a number of changes that made this paper more coherent
   and accessible.




Aguilar                                                         [Page 1]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


   Most of the work reported in this paper was sponsored by the U.S.
   Navy, Naval Electronic Systems Command, Washington D.C., under
   Contract No. N00039-83-K-0623.

I.  INTRODUCTION

   A. Use of a Graphical Communication Protocol

      In the field of computer communications, a protocol is a procedure
      executed by two cooperating processes in order to attain a
      meaningful exchange of information. A graphical communication
      protocol is needed to exchange interactive vector graphics
      information, possibly in conjunction with other information media
      like voice, text, and video. Within this multi-media communication
      environment, computer vector graphics plays a key role because it
      takes full advantage of the processing capabilities of
      communicating computers and human users, and thus it is far more
      compact than digital images which are not generated from data
      structures containing positional information. Vector graphical
      communication trades intensive use of storage and processing, at
      the communicating ends, in return for a low volume of exchanged
      data, because workstations with graphical hardware exchange
      graphics commands in conjunction with large data structures at the
      transmitter and receivers. In this manner, the transmission of a
      single command can produce extensive changes in the data displayed
      at the sending and receiving ends.

      It is helpful to situate the aforesaid protocol at one of the
      functional levels of the ISO Open Systems Interconnection
      Reference Model [1]. Within such a model, a graphical protocol
      functionality belongs primarily in the application level, though
      some of it fits in the presentation level.  We can distinguish the
      following components of a communication protocol:

         a) a data format
         b) rules to interpret transmitted data
         c) state information tables
         d) message exchange rules

      A format for a graphical protocol should provide the layout of the
      transmitted data, and indicate how the formated data are
      associated with interpretation rules. The choice of format
      influences the state tables to be maintained for the correct
      processing of the transmitted data stream. The graphical format
      has a minor influence on the exchange rules, which should provide
      for the efficient use of transmission capacity to transport the
      data under such a format. Besides the graphical format, there are


Aguilar                                                         [Page 2]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      other aspects of a graphical protocol that determine state tables
      and exchange rules. This paper concentrates in the data format,
      and it does not discuss the message exchange. Nevertheless, we
      discuss a simple software architecture for generating and
      interpreting data streams written in our proposed format. Further,
      we give an example of an application of a proposed format (in
      Appendix B), and it illustrates the type of message exchanges that
      are needed for establishing a communication session and exchanging
      graphical information.

      Those in the computer communication field are well aware of the
      importance of widely accepted protocols in order to achieve
      meaningful communication. Those who need to implement interactive
      graphical communications today are confronted with the lack of an
      standard for computer graphics communication among application
      programs. Nevertheless, we can use some of the work already done
      by the computer graphics standard bodies. As a matter of fact, ISO
      and ANSI have already appended, to the Graphical Kernel System
      (GKS) standard, the GKSM session metafile specification that has
      many of the features needed for an on-line graphical protocol.

      It is pertinent to mention an example of graphical communication
      that illustrates the real-time nature of the interaction and also
      illustrates the use of graphics in conjunction with other
      information media. With audio-graphics conferencing, a group of
      individuals at two or more locations can carry on an electronic
      meeting. They can converse over voice channels and concurrently
      share a graphics space on which they can display, point at, and
      manipulate vector graphics pictures [2, 3, 4, 5, 6, 7].

      The conference voice channels can be provided by a variety of
      transmission technologies. The shared graphics space can be
      implemented on workstations that display the pictures and permit
      graphical interaction and communication with other locations. The
      communication of operations upon pictures involves modifications
      to the underlying data structures, but we are concerned with
      graphical database updating only to the extent that such updating
      supports the communication.

      In order to play out a recorded graphical session, we will need
      indications of the rate at which the graphical elements must be
      shown and the graphical operations recreated. We do not include
      the means for indicating the timing of a session in a format
      because our main purpose is to use it in mixed-media communication
      environments.  In these environments, the play-out timing must be
      compatible across information media in order to coordinate them.
      Therefore, we leave the timing mechanisms to conference-control


Aguilar                                                         [Page 3]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      modules. We also leave to conference control processes the manner
      in which a conferee station emulates a graphical capability that
      it lacks. One example is the representation of color in monochrome
      displays.

   B. Relationship to Other Work

      There are a number of actual, and proposed, standards for graphics
      information exchange. In the following, we explain the reasons
      why, at present, none of them can be used as the basis of an
      on-line protocol. As some of these standards evolve, however, some
      may become suitable. Moreover, the experience gained with early
      on-line graphics communication systems will provide insight into
      the proper standard extensions to support more advanced systems.
      Such insight could also be used to modify the format proposed in
      this paper, which we consider an initial approach to the problem.
      In the future, the format proposed in this paper could be replaced
      by one of the aforesaid extended standards.

      The North American Presentation Level Protocol Syntax, NAPLPS,
      specifies a data syntax and application semantics for one-way
      teletext information dissemination and two-way videotex database
      access and transaction services. The two-way videotex operational
      model is based on the concept of a consumer and an information
      provider or service operator. Because of this asymmetry, it is
      assumed that almost all graphical information will flow from the
      provider toward the consumer. In the reverse direction, the
      consumer is expected to manipulate and transmit alphanumeric
      information, for the most part. Although this standard includes
      geometric drawing primitives, a user cannot directly modify shapes
      drawn with the primitives.

      At present, NAPLPS does not include interaction concepts like
      picture transformations or detectability, which are fundamental
      for attaining a shared graphical workspace. Neither does it allow
      key graphics input devices like mice, joysticks, stylus, rotating
      balls, or light pens, which are needed for simple and efficient
      editing of the shared workspace.

      We want to have user-to-user graphical communication that features
      the level of sophistication and ease of interaction provided by
      today's interactive graphics packages. Computer vector graphics
      can provide both because its paradigm includes an application
      program that keeps track of a very large number of possible
      changes of state of the displayed picture. In addition, the
      application drives a powerful graphics package, like GKS or ACM
      Core. In the videotex paradigm, the provider application only


Aguilar                                                         [Page 4]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      allows limited changes to the displayed image, primarily database
      retrieval requests. Also, the paradigm does not include a separate
      graphics package. Both the graphics functionality and the data
      format are collapsed into a coding specification, like NAPLPS.

      In this paper we are interested primarily in business and
      industrial applications where there is a two-way, or multi-way,
      flow of vector graphics information among the users. The users
      will have workstations with substantial processing and storage
      capacities, and high-resolution monitors; moreover, the
      communication will be on a distributed architecture not depending
      on a central server host, like the provider application host of
      videotex.

      Currently, the videotex equipment at the consumer end consists of
      inexpensive microprocessor-based decoders or personal computer
      boards driving, in most cases, low-resolution standard TV sets and
      personal computer displays. There is already affordable technology
      to produce sophisticated decoders and high-resolution graphics
      devices. The videotex standards need extensive revisions to take
      advantage of these advances; in particular, they should consider
      the receiving devices as capable of hosting a programmable
      customer-application process. When this happens, videotex
      protocols will be applicable to our intended problem areas [8].

      The Computer Graphics Metafile [9] will become an international
      and North American standard for graphics picture interchange in
      the near future. However, the CGM, also referred as VDM, is a
      picture-capture metafile that only records the final result of a
      graphics session. It is not intended to record the
      picture-creation process, which is fundamental for the interactive
      applications that we are addressing. Moreover, the CGM is
      presently aimed at a minimum support of GKS functionality. It will
      be some time before the CGM will have some of the elements needed
      for on-line interaction. If, after these additions, the CGM is
      augmented for session capture, it would become a logical candidate
      for a protocol format.

      Another future standard is the Computer Graphics Interface, CGI
      also referred as VDI [10]. The CGI is a standard functional and
      syntactical specification of the control and data exchange between
      device-independent graphics software and one or more
      device-dependent graphics device drivers. A major use of the CGI
      is for the communication between an application host and a
      graphics device, but the asymmetry between its intended
      communicating ends hinders the use of CGI for our purposes.



Aguilar                                                         [Page 5]



RFC 965                                                    December 1985
A Format for a Graphical Communication Protocol


      As previously stated, we want to take advantage of intelligence
      and storage at the communicating ends in order to achieve powerful
      information-conveying effects using narrow-bandwidth channels.
      This requires that the format we seek must have items for
      communication between two applications. In contrast, the CGI
      streams are processed by device-dependent drivers, rather than by
      applications. The CGI specification does include application data
      elements, but only to be stored in a metafile. These application
      data elements are not interpreted by the drivers, but by
      applications that read the metafile, some time after metafile
      creation.

      Furthermore, the CGI has elements for obtaining graphical input,
      as well as elements for inquiring graphics device capabilities,
      characteristics, and states. Later, in Section III, we explain why
      these two classes of elements are unnecessary for the
      communication protocol we need. As the CGI evolves, it will
      undergo significant changes, and, in the future, it may become a
      very suitable kernel for the graphics protocol we seek.  As a
      matter of fact, the CGI will be the communication protocol between
      graphical application hosts and graphics terminals.  At SRI we are