summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2122.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2122.txt')
-rw-r--r--doc/rfc/rfc2122.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2122.txt b/doc/rfc/rfc2122.txt
new file mode 100644
index 0000000..841e367
--- /dev/null
+++ b/doc/rfc/rfc2122.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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}
+ password: mavrakis@ties.itu.ch {user prompted for password}
+ 401 Unauthorized {an anonymous user is not allowed to
+ access the service}
+
+ d) Some services may use additional data transmitted in the parameter
+ fields, for example:
+ URL: vemmi://mctel.fr/demo;$USERDATA=smith;account=1234
+ If no access check is done by the host, the dialog might be:
+ service: demo;$USERDATA=smith;account=1234
+ 200 OK
+ ...starting VEMMI session...
+
+7) Procedure to use when a VEMMI URL is encountered in a HTML document
+ without VEMMI support:
+
+ The VEMMI URL support may be built-in in some Web browsers, or
+ offered by an associated software or plug-in interworking with the
+ user browser, for example using the WWW_RegisterProtocol API command
+ to register the new VEMMI protocol.
+
+ When a Web browser encounters a VEMMI URL without having VEMMI support,
+ two cases may occur:
+ - some browsers will detect an unrecognized scheme and signal an
+ unrecoverable error directly.
+
+
+
+Mavrakis, et. al. Standards Track [Page 6]
+
+RFC 2122 VEMMI URL Specification March 1997
+
+
+ - others will manage it as a relative URL [4] and will build a
+ complete URL including the VEMMI URL and will request it from the
+ host having sent the current document. In this case the host will
+ usually return the error "not found".
+
+ Among the mechanisms that could be used in order to offer a friendly
+ interface to both users with and without VEMMI support:
+ - when the second case occurs and the relative URL including the
+ vemmi:// string is transmitted to the server, the HTTPD server may
+ be modified in order to recognize such URL and to propose the
+ downloading of a VEMMI client software.
+ - the HTML document including the vemmi URL allowing to start the
+ VEMMI session may propose both options, for example:
+ If your browser supports VEMMI, directly
+ <A HREF="vemmi://ares.mctel.fr/TEST">start the interactive
+ multimedia service</A>, otherwise
+ <A HREF="ftp://ftp.mctel.fr/vemmi.exe">download first a VEMMI
+ client software</A>.
+ - the application/vemmi MIME type is defined below (to allow for
+ example exchange of vemmi objects). A possible way is for the
+ server to look in the HTTP Accept header field and to deduce that if
+ application/vemmi is supported, then the VEMMI support exists (in
+ this case, application/vemmi is to be defined in the browser and
+ associated with the vemmi decoder).
+
+8) Security Considerations:
+
+ The VEMMI URL scheme is subject to the same security implications as
+ the general URL scheme [5] [14], so the usual precautions outlined in
+ [5] [14] apply (for example, it is not allowed to store the username
+ and password in the URLs).
+
+ Furthermore, among VEMMI objects that could be used during the
+ interactive session, metacode objects (representing a sequence of
+ VEMMI commands) and operative objects (they are executable programs
+ to be run on the client platform) may be downloaded and/or started.
+
+ In order to protect the user against the activation of an harmful
+ operative object, it is strongly recommended that the users use the
+ configuration menu of their VEMMI software to disable the option of
+ running operative objects when receiving potentially unsafe VEMMI
+ objects, or at least enable the option to request first user approval
+ before starting the execution of an operative object.
+
+ The VEMMI remote interactive services may vary widely in their access
+ control policies; in practice, when a prompt for username or password
+ is received, the VEMMI terminal should request them from the user.
+ The VEMMI terminal implementation could support additional features,
+
+
+
+Mavrakis, et. al. Standards Track [Page 7]
+
+RFC 2122 VEMMI URL Specification March 1997
+
+
+ for example proposing by default "anonymous" as username and the user
+ Internet e-mail address as password, or looking in an encrypted local
+ database for user identification on this service.
+
+ Such an identification mechanism using the username/password scheme
+ is unsecure and is provided for backwards compatibility only. The
+ VEMMI services requiring a safe identification procedure must rely on
+ other alternative mechanisms (e.g. S/KEY or other). In numerous
+ cases, the user identification procedure will be performed by the
+ VEMMI service.
+
+9) application/vemmi MIME type
+
+ VEMMI is a multimedia interactive service and VEMMI objects are
+ usually exchanged through a continuous VEMMI multimedia session.
+ However, VEMMI objects could also be transmitted and exchanged using
+ other mechanisms, for example using HTTP, through e-mail, and so
+ on... The assignment of a MIME media type application/vemmi will
+ allow this transport and exchange of VEMMI objects, and this
+ paragraph describes this MIME type.
+
+ Furthermore, for Web browsers not supporting the addition of new URL
+ protocol scheme, the VEMMI MIME type may also be used to transmit,
+ instead of a VEMMI object, a text file containing the VEMMI URL to
+ activate to connect to a VEMMI server.
+
+9A) DESCRIPTION:
+
+ MIME media type name: "application"
+
+ MIME subtype name: "vemmi"
+
+ Required parameters: none
+
+ Optional parameters:
+ - version:
+ an optional version number may be specified, in the format:
+
+ version=<integer>
+
+ The version number is a numeric integer whose is encoded as the
+ <version> parameter defined in ETS 300 709 (e.g. version=100), and
+ whose the first digit represents the major VEMMI version number.
+ It must be pointed out that the VEMMI objects includes the VEMMI
+ version and a timestamp.
+
+
+
+
+
+
+Mavrakis, et. al. Standards Track [Page 8]
+
+RFC 2122 VEMMI URL Specification March 1997
+
+
+9B) ENCODING CONSIDERATIONS:
+
+ The "base64" mechanism is preferred because VEMMI use a native 8-bit
+ binary file format. However, as VEMMI includes its own 7-bits
+ encoding mechanisms, VEMMI data could also be transmitted in 7-bit
+ mode.
+
+9C) SECURITY CONSIDERATIONS:
+
+ Refer to paragraph 8.
+
+9D) INTEROPERABILITY CONSIDERATIONS:
+
+ VEMMI is designed to be fully platform independent, and the VEMMI
+ objects and contents could interoperate between any platform. The
+ only exception are the VEMMI operative objects that could be binary
+ programs specific to a given hardware platform and operating system.
+
+10) Liaison address:
+
+ For all technical questions regarding this request, please contact:
+
+ Daniel Mavrakis
+ Monaco Telematique MC-TEL
+ P.O. Box 225
+ MC 98004 Monte-Carlo Cedex
+ PRINCIPALITY OF MONACO
+ EMail: Mavrakis@mctel.fr
+ Tel: (+377) 9216 8860
+ Fax: (+377) 9330 4545
+
+ Comments may also be addressed to:
+
+ Mr. Herve Layec,
+ ETSI STC TE1
+ 06921 SOPHIA ANTIPOLIS Cedex
+ FRANCE
+ EMail: herve.layec@dri.france-telecom.fr
+ Tel: (+33) 2 99 12 73 01
+ Fax: (+33) 2 99 38 49 61
+
+
+
+
+
+
+
+
+
+
+
+Mavrakis, et. al. Standards Track [Page 9]
+
+RFC 2122 VEMMI URL Specification March 1997
+
+
+ Mr. Kurt Kartmann
+ Consulting
+ Telecommunication+Multimedia
+ Gabelsbergerstr. 2
+ D-64807 DIEBURG
+ GERMANY
+ EMail: k.kartmann@t-online.de
+ Tel: (+49) 6071 1528
+ c/o Deutsche Telekom AG
+ Tel. (+49)6151 834965, Fax (+49) 6151 834284
+
+ The authors thank the other members of the ETSI TE1 VEMMI Working
+ Group for their comments:
+
+ - Michael Blaschitz (michael.blaschitz@etsi.fr)
+ - Agnelo Fernandes (agnelo@telepac.pt)
+ - Daniel Allonsius (daniel.allonsius@is.belgacom.be)
+ - Stefaan Herrebout (Stefaan.Herrebout@mail.interpac.be)
+ - Francisca Oliva (oliva@tid.es)
+ - Herwart Wermescher (Herwart.Wermescher@infonova.telecom.at)
+
+11) References:
+
+ [1] "Enhanced Man-Machine Interface for Videotex and
+ Multimedia/Hypermedia Information Retrieval Services (VEMMI
+ revision 1)", ETS 300 709 standard (European Telecommunications
+ Standards Institute), September 1996.
+ This document is available on the Web in HTML format: see
+ http://www.etsi.fr/ecs/projects/vemmi/vemmi.htm
+
+ [2] "Enhanced Man-Machine Interface for Videotex and Other
+ Information Retrieval Services (VEMMI)", ITU-T T.107 standard
+ (International Telecommunications Union), March 1995.
+
+ [3] "Videotex Enhanced Man-Machine Interface service (VEMMI)",
+ ETS 300 382 standard (European Telecommunications Standards
+ Institute), February 1995.
+
+ [4] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC
+ Irvine, June 1995.
+
+ [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
+ Locators (URL)", RFC 1738, December 1994.
+
+ [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ October 1994.
+
+
+
+
+
+Mavrakis, et. al. Standards Track [Page 10]
+
+RFC 2122 VEMMI URL Specification March 1997
+
+
+ [7] Mavrakis, D., "VEMMI and Internet", TD 44, ETSI TE1 plenary
+ meeting in Brussels, October 20, 1995.
+
+ [8] Berners-Lee, T., Fielding, R., and H. Frystyk: "Hypertext Transfer
+ Protocol - HTTP/1.0", RFC 1945, MIT/LCS, UC Irvine, May 1996.
+
+ [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
+ Berners-Lee, Transfer Protocol - HTTP/1.1", RFC 2068, UC Irvine,
+ January 1997.
+
+ [10] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
+ Mail Extensions (MIME) Part Four Registration Procedures", BCP
+ 13, RFC 2048, November 1996.
+
+ [11] Masinter, L., Zigmond, D., and H. Alvestrand, "Guidelines and
+ Process for new URL Schemes", Work in Progress.
+
+ [12] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language
+ Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
+
+ [13] "Port Numbers",
+ ftp://venera.isi.edu/in-notes/iana/assignments/port-numbers
+
+ [14] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
+ Locators (URL)", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrakis, et. al. Standards Track [Page 11]
+