[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/