ETSI TE1 VEMMI Working Group D. Mavrakis Internet-Draft H. Layec draft-mavrakis-vemmi-url-spec-01.txt K. Kartmann August 21, 1996 Expires -> February 20, 1996 VEMMI URL Specification <draft-mavrakis-vemmi-url-spec-01.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to <mavrakis@mctel.fr>. This specification is also available via the Web in HTML form, see: http://www.mctel.fr/VEMMI/url.html ------------------------------------------------------------------------ 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 prETS 300 709 [1]). Mavrakis, Layec & Kartmann Page 1 VEMMI URL Specification 21 Aug 1996 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 [14]. 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/etsi/vemmi/vemmi.htm). A presentation of VEMMI can be found on http://www.mctel.fr/VEMMI/vemmien_intro.html ------------------------------------------------------------------------ 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. Mavrakis, Layec & Kartmann Page 2 VEMMI URL Specification 21 Aug 1996 ------------------------------------------------------------------------ 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 prETS 300 709). A VEMMI URL takes the form: vemmi://<user>:<password>@<host>:<port>/<vemmiservice>; <attribute>=<value> 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 :<password> may be omitted, as well as the whole <user>:<password> part, or the <vemmiservice> part. 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. Mavrakis, Layec & Kartmann Page 3 VEMMI URL Specification 21 Aug 1996 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 client: - wait for the optional request strings from the host server ('service:', 'username:' and 'password:') and answer them (respectively by <vemmiservice>, <username> and <password> values). 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 Mavrakis, Layec & Kartmann Page 4 VEMMI URL Specification 21 Aug 1996 of HTTP for VEMMI is not described in this document. ------------------------------------------------------------------------ 5) Proposed syntax The proposed BNF syntax is encoded as specified in RFC 1738 [5]: ; vemmi (see ITU-T T.107 and ETSI prETS 300 709) vemmiurl = "vemmi://" login [ "/" 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, along with optional login information (user and password, as login = [ user [ ":" password ] "@" ] hostport). 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) [14]. - 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: Mavrakis, Layec & Kartmann Page 5 VEMMI URL Specification 21 Aug 1996 a) A simple VEMMI URL for a VEMMI service that does not enforce access control might be: URL: vemmi://zeus.mctel.fr/demo In this case, the exchange between client and server will be as follow (the server requests are presented left, client answers right): ...establishing TCP/IP link to zeus.mctel.fr... service: demo 200 OK {status code returned by the VEMMI host} ...starting VEMMI session... 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) A similar URL to a service that requires an username and password might have an URL that looks like: URL: vemmi://smith:12345678@mctel.fr/demo The exchange between the client and server will be: ...establishing TCP/IP link to mctel.fr... service: demo login: smith password: 12345678 200 OK ...starting VEMMI session... Should the server does not prompt the client for login and password, the login information stored in the URL will not be used. The password characters echo may be scrambled. d) The URL may 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 follow (server requests at the left, client answers at the right): ...establishing TCP/IP link to mctel.fr... 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} ...closing TCP/IP link between client and server... Mavrakis, Layec & Kartmann Page 6 VEMMI URL Specification 21 Aug 1996 e) 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: ...establishing TCP/IP link to mctel.fr... 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. - others will manage it as a relative URL [13] 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 pending registration (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). Mavrakis, Layec & Kartmann Page 7 VEMMI URL Specification 22 Aug 1996 ------------------------------------------------------------------------ 8) Security considerations: The VEMMI URL scheme is subject to the same security implications as the general URL scheme [5], so the usual precautions outlined in [5] apply (for example, the use of URLs containing passwords that should be secret is clearly unwise). 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, the <user> and <password> supplied are advisory only: clients accessing a VEMMI URL merely advise the user of the suggested username and password, and the user could supersede them. The <user> and <password> fields supplied either in the URL or the by user will be used to answer the user and password commands received from the remote host after establishing the connection to the VEMMI server. If no user and password commands are received from the remote host, these fields will not be used. If no user name or password is supplied and one is requested by the VEMMI server, the program interpreting the VEMMI URL should request one from the user, proposing by default "anonymous" as user name and the Internet e-mail address of the end user accessing the service as password. 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) 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 Mavrakis, Layec & Kartmann Page 8 VEMMI URL Specification 21 Aug 1996 PRINCIPALITY OF MONACO e-mail: 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 e-mail: herve.layec@dri.france-telecom.fr Tel: (+33) 99 12 73 01 Fax: (+33) 99 38 49 61 Mr. Kurt Kartmann Danet GmbH/Deutsche Telekom AG Gutenberg Str. 10 D-64331 WEITERSTADT GERMANY e-mail: Kurt.Kartmann@T-online.de Tel: (+49) 6151 868 139 Fax: (+49) 6151 868 131 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) ------------------------------------------------------------------------ 10) References: [1] "Enhanced Man-Machine Interface for Videotex and Multimedia/Hypermedia Information Retrieval Services (VEMMI revision 1)", prETS 300 709 standard (European Telecommunications Standards Institute), November 1995. This document is available on the Web in HTML format: see http://www.etsi.fr/etsi/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 Mavrakis, Layec & Kartmann Page 9 VEMMI URL Specification 21 Aug 1996 382 standard (European Telecommunications Standards Institute), February 1995. [4] R. Fielding: "Relative Uniform Resource Locators", RFC 1808, June 1995. [5] T. Berners-Lee, L. Masinter, M. McCahill: "Uniform Resource Locators (URL)", RFC 1738, December 1994. [6] J. Postel: "Assigned Numbers", RFC 1700, October 1994. [7] D. Mavrakis: "VEMMI and Internet", TD 44, ETSI TE1 plenary meeting in Brussels, October 20, 1995. [8] T. Berners-Lee, R. Fielding, H. Frystyk: "Hypertext Transfer Protocol - HTTP/1.0", RFC 1945, MIT/LCS, UC Irvine, May 1996. [9] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee: "Hypertext Transfer Protocol - HTTP/1.1", Work in Progress (draft-ietf-http-v11-spec-07.txt), UC Irvine, August 12, 1996 [10] J. Postel, "Media Type Registration Procedure", RFC 1590, March 1994. [11] DRAFT: Considerations for the new UR* schemes (http://www.apps.ietf.org/apps/url-schemes.html) [12] T. Berners-Lee, D. Connolly: "Hypertext Markup Language Specification - 2.0", RFC 1866, MIT/LCS, November 1995. [13] R. Fielding: "Relative Uniform Resource Locators", RFC 1808, UC Irvine, June 1995. [14] "Port Numbers", ftp://venera.isi.edu/in-notes/iana/assignments/port-numbers Mavrakis, Layec & Kartmann Page 10