ETSI TE1 Working Group D. Mavrakis Internet-Draft H. Layec draft-mavrakis-videotex-url-spec-00.txt K. Kartmann November 26, 1996 Expires -> May 25, 1997 Videotex URL Specification <draft-mavrakis-videotex-url-spec-00.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/vtxurl.html ------------------------------------------------------------------------ 1) Abstract A new URL scheme, "videotex" is defined. It allows videotex client software or terminals to connect to videotex services compliant to the ITU-T and ETSI videotex standards, including among others: - ITU/T Recommendation T.101: International Interworking for Videotex [1] - ETS 300 072: Videotex presentation layer protocol, videotex presentation layer data syntax [7]. - ETS 300 073: Videotex presentation layer protocol, Geometric display [12]. - ETS 300 076: Videotex Terminal Facility Identifier (TFI) [14] Mavrakis, Layec & Kartmann Page 1 Videotex URL Specification 26 Nov 1996 - ETS 300 149: Videotex presentation layer protocol, Audio Syntax [16]. - ETS 300 177: Videotex presentation layer protocol, Photographic Syntax [15]. - ANSI X3.110 - CSA T500: Videotex/Teletext Presentation Level Protocol Syntax [17]. The well-known port number 516 has been assigned by IANA to the videotex protocol [2]. ------------------------------------------------------------------------ 2) Videotex URL scheme utility and operability: Numerous countries (mostly in Europe but also in another parts of the world) have setup and are using videotex networks. These networks allows users to call videotex servers using either stand-alone videotex terminals or software emulators running on PC, that could even be integrated with Web browsers as plug-ins (through this document, 'videotex terminal' may refer either to a dedicated terminal or to a computer system running a videotex software emulator). The Videotex URL scheme will be used in several cases to allow access to videotex services from the Internet [1]: - to select a videotex service using a Internet/Videotex gateway: Most videotex networks operators now want to allow their videotex networks to be accessed through the Internet. Several methods could be used to this end [1], but the most easier (and the one mostly used right now, e.g. in France http://www.minitel.fr), is to distribute a videotex software emulator supporting TCP/IP, and to install in the network a gateway between the Internet and the videotex world (that uses mostly X.25 as transport network). ----------- -------------- | PC with | |\ TCP/IP - X.25 | videotex | | videotex| Internet | \ gateway | server | | emulator|-------------| >-----------------------| connected | | on | | / X.25 network | to X.25 | | TCP/IP | |/ | videotex | ----------- | network | | -------------- | -------------- | | videotex | | |access point| | |or videotex | | TCP/IP Internet | server | |---------------------------------------------| with TCPIP | | support | -------------- Mavrakis, Layec & Kartmann Page 2 Videotex URL Specification 26 Nov 1996 - In the same way, a videotex server or a videotex access point (which provides the access to the videotex network) may also support direct TCP/IP connections (see lower part of the figure) from such TCP/IP videotex emulators. The Videotex URL scheme will then be used in both cases to perform videotex service selection: A videotex server or an Internet/Videotex gateway will listen on its videotex well-known port for incoming connections. The server or the gateway could of course be engaged in many simultaneous connections, and after a connection is established, the terminal must be able to select the videotex application desired, as a same system may host or give access to different videotex applications. The best mechanism to fully describe the videotex service to activate is the URL mechanism. ------------------------------------------------------------------------ 3) Description of the videotex scheme The videotex URL scheme is used to designate videotex interactive services conforming to videotex standards. A videotex URL takes the form: videotex://<user>:<password>@<host>:<port>/<videotexservice>; <attribute>=<value> as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the port defaults to 516 (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 <videotexservice> part. This URL does not designate a data object, but rather a videotex interactive service. A videotex service starts a session managing videotex screens and interacting with the user during the session. To the difference of other stateless protocols, the link between the client and the server is maintained during the whole session. The <videotexservice> is the name of the videotex service to activate. This field is not mandatory and could be omitted for example if the remote host or gateway gives access to only one videotex service or activates a videotex service by default when no service is specified. If this field is omitted in the URL and the remote host requests it, it is assumed that the videotex terminal will prompt the user for it. In addition, after the <videotexservice>, optional attributes and values (parameters) associated with the videotex service may be specified as part of the URL. When present, each parameter (attribute/value pair) Mavrakis, Layec & Kartmann Page 3 Videotex URL Specification 26 Nov 1996 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 videotex service. ------------------------------------------------------------------------ 4) Client/server dialog during service selection The videotex terminal will interpret the videotex URL to connect to the remote host or gateway to access the specified videotex service. After connecting to the remote system, the host or gateway may prompt the videotex client for service name and optional user identification. The videotex service selection and the optional user identification procedure are performed using a simple dialog between the terminal and the host or gateway, in videotex or ANSI terminal telnet mode. It is expected the videotex terminal will display this exchange in the terminal window. As existing remote systems may expect to be called by TCP/IP videotex emulators supporting or not supporting automatic service selection using videotex URL specification, a videotex dialog for service selection may be widely used. It is therefore recommended that TCP/IP videotex emulators supporting automatic service selection be able to perform automatically when possible the service selection in both modes (videotex and terminal). When the service selection phase could not be performed automatically (e.g. because the terminal has not recognized the request strings from the host server), the user identification and service selection requests must be answered manually by the user in terminal or videotex dialog mode. The service, username and password information are transmitted by the videotex terminal to the host in answer to the corresponding requests received from the host. The following behavior is expected from the terminal: - wait for the optional request strings from the host server ('service:', 'login:' and 'password:') that could be received in any order, and answer them (respectively by <videotexservice>, <user> and <password> values). It should be noted that, in videotex mode, these strings ('service:', 'login:' and 'password:' may be embedded within videotex data. The terminal answers 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 <videotexservice> transmitted Mavrakis, Layec & Kartmann Page 4 Videotex URL Specification 26 Nov 1996 to the host in answer to the 'service:' request received from the host, separated from the <videotexservice> value by a semicolon. - the client answers are to be followed by a Carriage Return (CR) in telnet mode and by the Send function key or equivalent in videotex mode. In telnet mode, if a Line Feed (LF) is transmitted after the CR, it will be ignored by the remote server or gateway. The remote host shall accept and process in addition to CR in both telnet mode and videotex mode the equivalent videotex function keys (e.g. SEND (1/3h, 4/1h) in Teletel mode, 1/Ch in Btx or # in Prestel mode). The remote host may optionally also recognize and manage the other videotex functions keys (e.g. CANCEL, GUIDE, REPEAT, CORRECTION,...). - The remote host may echo the characters received from the videotex 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. - during the service selection phase and optional identification procedure, the terminal will display the exchange of information in the videotex 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). In the same way, additional negotiation with the user (e.g. request for the user approval of the charging for paying services) may be conducted in videotex or telnet mode before establishing the connection to the service. In order to allow an automatic processing of the charging request for approval, it is recommended that it follows the scenario described below: + the charging to be applied to the service is described by the remote system in videotex mode (e.g. "service charged 1.20 FRF/min"). + the charging approval request sent by the host includes the string "accept charging (y/n):" + on receipt of this string, the terminal may answer automatically "y" (accept the charging) or "n" (reject the charging) if it has been able to understand the charging description and if its configuration allows to accept or reject automatically such a charging. Otherwise, the charging approval or rejection will have to be performed manually by the user. Should an error occur during videotex 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. Some implementations may choose to display instead the error and the continue to interact with the user using a videotex dialog. Mavrakis, Layec & Kartmann Page 5 Videotex URL Specification 26 Nov 1996 ------------------------------------------------------------------------ 5) Proposed syntax The proposed BNF syntax is encoded as specified in RFC 1738 [5]: ; videotex (see ITU-T and ETSI videotex standards) videotexurl = "videotex://" login [ "/" videotexservice *[ parameter ] ] videotexservice = *[ 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 videotex software will mostly use the port number assigned to videotex (516). - allows him to select a specific videotex service if the remote host or gateway manages access to several different videotex services. The videotex service to be accessed may be referred by its name or its X.25 number (including X.25 subaddress if needed). - allows also to send additional data to the service using the parameter syntax during the service selection phase. 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: - $ECHO: the value of this field may be either LOCAL (stating the echo of characters typed by user is performed by the videotex emulator) or REMOTE (stating the echo of characters typed by the user is performed by the remote system). If this parameter is not present, the default value is LOCAL (due to high latency of the Internet network, a remote echo often leads to unacceptable response times). When the echo is performed locally by the videotex terminal, it is expected to complies with the videotex access point behavior regarding the echo of videotex sequences or the processing of function keys and local buffer (e.g. some function keys or data transmitted by the terminal to the network must not be echoed). - $USERDATA: user data specific by the user and to be processed by the videotex service. If the remote system is a videotex host server, it will process the USERDATA as if they have been received as X.25 user data in an incoming X.25 call. If the remote system is an Internet/Videotex gateway, it will forward the USERDATA to the Mavrakis, Layec & Kartmann Page 6 Videotex URL Specification 26 Nov 1996 called videotex service in the X.25 user data field. It should be noted that the user data field of an X.25 call packet could contain at most 16 bytes (without fast select, see below), and that usually a 4-bytes protocol identifier is used at the beginning so there is 12 bytes left. - $FASTSELECT: user data to be processed or transmitted to the remote host as X.25 fast select user data. If the remote system is a videotex host server, it will process the FASTSELECT data as if they have been received as X.25 fast select data in an incoming X.25 call. If the remote system is an Internet/Videotex gateway, it will forward the FASTSELECT data to the called videotex service in the X.25 fast select data field. This field and the $USERDATA field are mutually exclusive. It should be noted that the user data field of an X.25 call packet with fast select could contain at most 128 bytes (the first fourth being usually used for the protocol identifier). It should also be noted that the configuration of some X.25 videotex servers may not allow them to use the fastselect facility. - $LANGUAGE: specify the user current or preferred language, encoded as specified in RFC 1766 [18]. - $CONTEXTDATA: context data. - $ENCRYPTION: specify the encryption mechanism to be used between the videotex client and the remote system, in order to protect the privacy of the videotex session. - $EMULATION: specify the default emulation mode supported to access this videotex service. Among the possible values for this field: CEPT1 (BTX), CEPT2 (Teletel latin mode), CEPT2GREEK (Teletel greek mode), CEPT2ARABIC, CEPT3 (Prestel), CEPT4, NAPLPS, CAPTAIN, VT52, VT100, VT220. It should be noted that the remote host may check the terminal capabilities using the Videotex Terminal Facility Identifier (TFI, ETS 300 076 [14]) and switch the terminal to the desired mode (even before starting the service selection phase). ------------------------------------------------------------------------ 6) Examples: Some examples are presented below, they are for information only: a) A simple videotex URL for a videotex service that does not enforce access control might be: URL: videotex://ares.mctel.fr/demo In this case, the exchange between client and server is as follow (server requests at the left, client answers at the right): ...establishing TCP/IP link to ares.mctel.fr... service: demo 200 OK {status code returned by the videotex host} ...starting videotex session... Mavrakis, Layec & Kartmann Page 7 Videotex URL Specification 26 Nov 1996 b) If the remote server hosts only one videotex service, this field may be omitted and the URL might be: URL: videotex://ares.mctel.fr In this case, the videotex interactive session is started immediately by the host without requesting first the service name. c) A similar URL to a service that requires an username and password might have an URL that looks like: URL: videotex://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 videotex session... Should the server does not prompt the client for login and password, the login information stored in the URL will not be used. d) The URL may not include the username and password. In this case, should they be requested by the host, the videotex client may use a default specified for this service or prompt the user for them (for example it could propose anonymous and user e-mail address as defaults): URL: videotex://mctel.fr/demo In this case, the exchange between client and server may be as follow: ...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... e) When the user access to videotex services is done through a gateway that checks the user authorization before allowing him to access videotex services on the network, the dialog may be: ...establishing TCP/IP link to remote host... login: xyz {the user is prompted for it} password: ****** {the user password echo is scrambled by the gateway} service: demo 200 OK {status code returned by the videotex host} ...starting videotex session... f) Some services may use additional data transmitted in the parameter fields, for example: URL: videotex://mctel.fr/demo;$USERDATA=smith The USERDATA contents will be transmitted to the remote host in the X.25 user data field (if the called system is an Internet/Videotex gateway) or will be managed by the called system as X.25 user data Mavrakis, Layec & Kartmann Page 8 Videotex URL Specification 26 Nov 1996 (if the remote system is a gateway). If no access check is done by the host, the dialog might be: ...establishing TCP/IP link to mctel.fr... service: demo;$USERDATA=smith 200 OK ...starting videotex session... g) The access to some services may be restricted to identified users and charged. In this case, the user approval of the charging to be applied may be requested by the host: ...establishing TCP/IP link to remote host... login: xyz {the user is prompted for it} password: ****** {the user password echo is scrambled} service: demo service charged 0.75 FRF/min accept charging (y/n): y {automatic or manual approval of charging} 200 OK {status code returned by the videotex host} ...starting videotex session... ------------------------------------------------------------------------ 7) Procedure to use when a videotex URL is encountered without videotex support: The videotex URL support may be built-in some Web browsers, or offered by an associated software interworking with the user browser, for example using an API command to register the videotex protocol, or a videotex plug-in. When a Web browser encounters a videotex URL without having videotex support, two cases may occur: - some browsers will detect an unrecognized scheme and signal an error directly. - others will build a relative URL including the URL entered and will request it from the host having sent the current document. In this case the host HTTP server 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 videotex support: - when the second case occurs and the relative URL including the videotex:// string is transmitted to the server, the HTTP server may be modified in order to recognize such URL and to propose the downloading of a videotex client software or plug-in. - the HTML document including the videotex URL allowing to start the videotex session may propose both options, for example: If your browser supports videotex or if you have a videotex plug-in installed, then directly <A HREF="videotex://ares.mctel.fr/TEST">access the videotex service</A>, otherwise <A HREF="ftp://ftp.mctel.fr/videotex.exe">download first a Mavrakis, Layec & Kartmann Page 9 Videotex URL Specification 26 Nov 1996 videotex client software</A>. - the application/videotex MIME type is defined below in 10) (to allow for example exchange of videotex screens). A possible way is for the server to look in the HTTP Accept header field and to deduce that if application/videotex is supported, then the videotex support exists (in this case, application/videotex is to be defined in the browser and associated with the videotex decoder). ------------------------------------------------------------------------ 8) Session control: A session control mechanism must be provided to allow the remote system or gateway to control the behavior of the videotex terminal, and especially the features previously managed in X.25 mode by the videotex access point and that are now performed by the TCP/IP terminal. This is especially true when the echo is performed locally by the videotex terminal, because in a non-TCP/IP videotex network the echo is usually performed by the Videotex Access Point and may be disabled or enabled again by the remote videotex server, using an X.29 PAD command. The remote system must interpret such a command and in most cases could use the videotex terminal supported command set to stop temporarily the echo of the characters. ------------------------------------------------------------------------ 9) Security considerations: The videotex 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). The videotex remote interactive services may vary widely in their access control policies; in practice, the <user> and <password> supplied are advisory only: clients accessing a videotex 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 videotex 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 videotex server, the program interpreting the videotex 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 videotex Mavrakis, Layec & Kartmann Page 10 Videotex URL Specification 26 Nov 1996 services requiring a safe identification procedure must rely on other alternative mechanisms (e.g. S/KEY or other). It must also be pointed out that in most cases the identification procedure is done within the videotex service using a dialog in videotex mode between the user and the server. ------------------------------------------------------------------------ 10) application/videotex MIME type Videotex usually refers to a videotex interactive service and the videotex data (screens, sounds,...) are usually received during a continuous videotex session. However, videotex screens or part of screens could also be transmitted and exchanged using other mechanisms, for example using HTTP, through e-mail, and so on... The assignement of a MIME media type application/videotex will allow this transport and exchange of videotex data, and this paragraph describe this media type. Furthermore, for Web browsers not supporting the addition of new URL protocol schemes, the application/videotex MIME type may also be used to transmit, instead of videotex data, a text file containing the videotex URL to activate to connect to a videotex server. 10A) DESCRIPTION: MIME media type name: "application" MIME subtype name: "videotex" Required parameters: none Optional parameters: It is recommended that the videotex data includes at the beginning the assigned switching sequences allowing to specify and select the relevant data syntax type and profile used to encode the videotex data, as well as the type of data (alpha mosaic or alpha geometric, photographic, audio,...). However if this sequence is not present, the following optional parameters may be used to specify the data syntax type and profile. - Data Syntax: specify the data syntax used for encoding videotex data, that may be 1 (Data Syntax I, Captain Japanese syntax), 2 (Data Syntax II, European syntax) or 3 (Data Syntax III, NAPLPS North-American syntax). - Profile: specify the encoding profile for Data Syntax II, that may be 1 (BTX), 2 (Teletel), 3 (Prestel) or 4. 10B) ENCODING CONSIDERATIONS: The "base64" mechanism is preferred because videotex encoding could use either a native 8-bit format or other formats (7 bits, even Mavrakis, Layec & Kartmann Page 11 Videotex URL Specification 26 Nov 1996 parity). 10C) SECURITY CONSIDERATIONS: Refer to paragraph 9. 10D) INTEROPERABILITY CONSIDERATIONS: The videotex data such videotex screens and sounds could be transmitted and exchanged between any platform running a videotex decoder. ------------------------------------------------------------------------ 11) Liaison address: For all technical questions regarding this document, please contact: Daniel Mavrakis Monaco Telematique MC-TEL P.O. Box 225 MC 98004 Monte-Carlo Cedex 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-2) 99 12 73 01 Fax: (+33-2) 99 38 49 61 Mr. Kurt Kartmann Consulting Telecommunication+Multimedia Gabelsbergerstr. 2 D-64807 DIEBURG GERMANY e-mail: 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: Mavrakis, Layec & Kartmann Page 12 Videotex URL Specification 26 Nov 1996 - Yannick Surzur (surzur@ccett.fr) - Herwart Wermescher (Herwart.Wermescher@infonova.at) ------------------------------------------------------------------------ 11) References: [1] "Interworking between Videotex and Internet", DTR/TE-01065, Draft European Technical Report, June 26, 1996, European Telecommunications Standards Institute. [2] Assigned port numbers, ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers [3] "International Interworking for Videotex Services", ITU Recommendation T.101, version 1994-11. [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] ETS 300 072: "Videotex presentation layer protocol, videotex presentation layer data syntax", November 1991. [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] ETS 300 073: "Videotex presentation layer protocol, Geometric display", November 1990 [13] ETS 300 073: "Videotex presentation layer protocol, Transparent data", November 1990 [14] ETS 300 076: "Videotex Terminal Facility Identifier (TFI)", Edition 3, December 1994. Mavrakis, Layec & Kartmann Page 13 Videotex URL Specification 26 Nov 1996 [15] ETS 300 177: "Videotex: Photographic Syntax", January 1995, Edition 2. [16] ETS 300 149: "Videotex Audio Syntax", March 1992. [17] ANSI X3.110-1983 et CSA T500-1983: "Videotex/Teletext Presentation Level Protocol Syntax: North American PLPS", December 1983. [18] H. Alvestrand: "Tags for the Identification of Languages", RFC 1766, UNINETT, March 1995. Mavrakis, Layec & Kartmann Page 14