rfc2122.txt

RFC 的详细文档！

Network Working Group                                      D. Mavrakis
Request for Comments: 2122                   Monaco Telematique MC-TEL
Category: Standards Track                                     H. Layec
                                                                  ETSI
                                                           K. Kartmann
                                          Telecommunication+Multimedia
                                                            March 1997

                        VEMMI URL Specification

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

1) Abstract

   A new URL scheme, "vemmi" is defined. It allows VEMMI client software
   and VEMMI terminals to connect to multimedia interactive services
   compliant to the VEMMI standard (Enhanced Man-Machine Interface for
   Videotex and Multimedia/Hypermedia Information Retrieval Services),
   sometimes abbreviated as "VErsatile MultiMedia Interface".

   VEMMI is a new international standard for on-line multimedia
   services, that is both an ITU-T (International Telecommunications
   Union, ex.  CCITT)  International Standard (T.107) [2] and an
   European Standard (ETSI European Telecommunications Standard
   Institute) standard (ETS 300 382  [3], obsoleted by ETS 300 709 [1]).

   VEMMI could be described as an on-line multimedia protocol describing
   both the man-machine interface and the client/server exchange
   protocol.  VEMMI operates usually on a single continuous session
   between a client and a host and supports an object-oriented, event-
   driven, client/server oriented and platform independent multimedia
   interface. The well-known tcp port number 575 has been assigned by
   IANA to the VEMMI protocol [13].

   A description of the VEMMI standard along with its last approved
   version is publicly available on the Web: see the URL
   http://www.etsi.fr/ecs/projects/vemmi/vemmi.htm). A presentation of
   VEMMI can be found on http://www.mctel.fr/VEMMI/vemmien_intro.html







Mavrakis, et. al.           Standards Track                     [Page 1]

RFC 2122                VEMMI URL Specification               March 1997


2) VEMMI URL scheme utility and operability:

   - VEMMI service selection: A VEMMI multimedia server will listen on
     its VEMMI well-known port for incoming connections. The server
     could of course be engaged in many simultaneous connections, and
     after a connection is established, the terminal must be able to
     select the desired VEMMI application, as a same system may host
     different VEMMI applications.
     The best mechanism to fully describe the VEMMI service to activate
     is the URL mechanism.
     - Reporting user action to a remote server: The VEMMI protocol
     establishes a continuous TCP/IP link between the terminal and the
     server during the whole user session. During a session managing
     VEMMI objects, the user actions are usually reported back to the
     server using the VEMMI user data report mechanism that is an
     integral part of the VEMMI protocol.
     However, in some case, the URL mechanism may be required to send
     back reports to a remote host. VEMMI is for example able to display
     HTML documents within a multimedia display area in a VEMMI dialog
     box. these HTML documents may be managed either by the VEMMI server
     (acting as a proxy gateway) or directly by the client software that
     will issue itself the HTTP requests on the network and browse
     across documents on the Web as a standard Web browser (the link to
     the VEMMI server is kept and used for interacting with other VEMMI
     objects and components but the VEMMI server may not be informed of
     the user navigation on the Web inside the multimedia area).
     In such a case, the URL mechanism could also be used to report the
     user actions and commands within a HTML document to be reported to
     the VEMMI server or even another system.
   - Extension of Web browsers: The VEMMI protocol is quite
     complementary to HTTP/HTML used by Web browsers, and several
     networks operators have decided to support jointly Web and VEMMI
     (seen as complementary protocols). Thanks to the VEMMI URL, Web
     browsers will be able to activate a VEMMI client software module to
     start a VEMMI session to the requested service when the user
     activate a vemmi URL included in the HTML document.

3) Description of the VEMMI scheme

   The VEMMI URL scheme is used to designate multimedia interactive
   services conforming to the VEMMI standard (ITU/T T.107 and ETS 300
   709).

   A VEMMI URL takes the form:
       vemmi://<host>:<port>/<vemmiservice>;
       <attribute>=<value>





Mavrakis, et. al.           Standards Track                     [Page 2]

RFC 2122                VEMMI URL Specification               March 1997


   as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the
   port defaults to 575 (client software may choose to ignore the
   optional port number in order to increase security). The
   <vemmiservice> part is optional and may be omitted.

   This URL does not designate a data object, but rather a multimedia
   interactive service. A VEMMI service starts a multimedia session
   managing multimedia objects and interacting with the user during the
   session. To the difference of other stateless protocols, the link
   between the client and the server is usually maintained during the
   whole session (although in some cases other mechanisms may be used,
   see below).

   The <vemmiservice> is the name of the VEMMI service to activate. This
   field is not mandatory and could be omitted for example if the remote
   host manages only one VEMMI service or activates a VEMMI service by
   default when no service is specified. If this field is omitted in the
   URL and the server requests it, it is assumed that the VEMMI client
   software will prompt the user for it.

   In addition, after the <vemmiservice>, optional attributes and values
   (parameters) associated with the VEMMI service may be specified as
   part of the URL. When present, each parameter (attribute/value pair)
   is separated from each other and from the rest of the URL by a ";"
   (semicolon). The name of the attribute and its value are separated by
   a "=" (equal sign). If present, these fields are used to transmit
   additional data useful for service selection or to request to perform
   a specific processing. For example, the $USERDATA field can be
   specified to transmit additional user-specified data to the VEMMI
   service.

4) Client/server dialog during service selection

   The VEMMI client will interpret the VEMMI URL to connect to the
   remote host and to access the specified VEMMI service. After
   connecting to the remote system, the host may prompt the VEMMI client
   for service name and user identification.

   Before starting the VEMMI session, a VEMMI terminal is in 'standard'
   mode and may display the data received from the network in a videotex
   or telnet terminal window. As the VEMMI session may be started
   anytime during an interactive videotex or telnet session, the VEMMI
   service selection is performed by a simple dialog between the client
   and the server.

   The service, username and password information are transmitted by the
   client software to the host in answer to the corresponding requests
   received from the host. The following behavior is expected from the



Mavrakis, et. al.           Standards Track                     [Page 3]

RFC 2122                VEMMI URL Specification               March 1997


   client:
   - wait for the optional request strings from the host server
     ('service:', 'username:' and 'password:') and answer them
     (respectively by <vemmiservice> value defined in the URL and the
     <username> and <password> entered by the user if required).  The
     terminal answer may be sent automatically if the answers are known
     (that is if they are specified in the URL or terminal
     configuration) or it may prompt the user for the needed
     informations.  When parameters (attribute and value pairs) are
     present in the URL, these fields will be sent following the
     <vemmiservice> transmitted to the host in answer to the 'service:'
     request received from the host, separated from the <vemmiservice>
     value by a semicolon.
   - the client answers must always be followed by a Carriage Return
     (CR). If a Line Feed (LF) is transmitted after the CR, it will be
     ignored by the server.
   - in both cases, the server may echo the characters received from the
     client terminal, the received CR being echoed as CR LF. The server
     may echo the password characters as stars or any other scrambled
     output for safety purpose.
   - the client must also be ready to start the VEMMI session as soon
     as it receives the VEMMI_Open command. Before starting this VEMMI
     session, the terminal is in 'standard' mode and may display the
     data received from the network in a videotex or telnet terminal
     window (this is the reason why the service, username and password
     data are requested by the server using a telnet or videotex
     compatible dialog).

   Should an error occur during VEMMI service activation, the remote
   host may inform the user by displaying the error cause. It is
   recommended that, when possible and applicable, the status code
   syntax described in HTTP [8] [9] be used to facilitate automatic
   processing by the client of the host answer during error or normal
   operation.

   If a VEMMI client software wants to request a VEMMI object without
   establishing a continuous VEMMI session, such a request may also be
   performed using a HTTP request for the vemmi object encoded using the
   Internet media type application/vemmi (pending registration by IANA
   [10]). In the same way, HTTP could be used in some cases to exchange
   data pertaining to a VEMMI session with or without setting the keep-
   alive keyword in the Connection header to request a persistent
   connection [9]. Protocol switching using the upgrade header field may
   be used in such case to switch to vemmi protocol [9]. This possible
   use of HTTP for VEMMI is not described in this document.






Mavrakis, et. al.           Standards Track                     [Page 4]

RFC 2122                VEMMI URL Specification               March 1997


5) Proposed syntax

   The proposed BNF syntax is encoded as specified in RFC 1738 [5] [14]:

; vemmi (see ITU-T T.107 and ETSI ETS 300 709)

vemmiurl      = "vemmi://" hostport [ "/" vemmiservice *[ parameter ] ]
vemmiservice  = *[ uchar | "/" | "?" | ":" | "@" | "&" | "=" ]
parameter     = ";" attribute "=" value
attribute     = *[ uchar | "/" | "?" | ":" | "@" | "&" ]
value         = *[ uchar | "/" | "?" | ":" | "@" | "&" ]

   This syntax: - allows the user to specify the remote host address by
     its name or numeric address. Although he could select a specific
     port, it is expected the information providers and VEMMI software
     will mostly use the port number assigned to VEMMI (575) [13]. For
     security reasons, the username and password could not be specified
     in the URL.
   - allows him to select a specific VEMMI service if the remote host
     manages several different VEMMI services.
   - allows also to send additional data to the service using the
     parameter syntax, either during the service selection phase or when
     the user selects a vemmi hyperlink within a HTML document displayed
     in a VEMMI multimedia area. To the difference of the params syntax
     used in [4], the parameter syntax requires each value to be labeled
     by an attribute. The parameter attribute names are case-
     insensitive. Parameter values may or may not be case-sensitive,
     depending on the attribute.

   All the values of fieldname beginning by a dollar ($) sign are
   reserved for specific use, including:
   - $COMMAND: VEMMI command to be returned to the host when the VEMMI
     session do not use a continuous link.
   - $CONTEXTDATA: context data.
   - $OBJECT_REQUEST: requests the retransmission of a given VEMMI object.
   - $USERDATA: user data specific by the user and to be processed by the
     VEMMI service.

6) Examples:

   Some examples of VEMMI URLs along with the corresponding
   client/server dialog are presented below, they are for information
   only:

   a) A simple VEMMI URL and the corresponding dialog for a VEMMI
      service that does not enforce access control might be:
        URL: vemmi://zeus.mctel.fr/demo




Mavrakis, et. al.           Standards Track                     [Page 5]

RFC 2122                VEMMI URL Specification               March 1997


      In this case, the exchange between client and server will be as
      follow (the server requests are presented left, client answers
      right):
   service:        demo
   200 OK                     {status code returned by the VEMMI host}

   b) The service name may be omitted (for example if the remote server
      hosts only one VEMMI service), and the URL might then be:
        URL: vemmi://zeus.mctel.fr
      In this case, the VEMMI interactive session is started immediately
      by the host without requesting first the service name (should the
      client receive a service request from the host, it will prompt the
      user for service name).

   c) The URL could not include the username and password. In this case,
      should they be requested by the host, the VEMMI client may use a
      default value specified for this service or prompt the user for
      them (for example it could propose anonymous and user e-mail
      address as defaults):
        URL: vemmi://mctel.fr/demo
      In this case, the exchange between client and server may be as
      follows (server requests at the left, client answers at the right):
   service:        demo
   login:          anonymous       {user has been prompted for username}