VEMMI URL Specification
draft-mavrakis-vemmi-url-spec-03

ETSI TE1 VEMMI Working Group                                 D. Mavrakis
Internet-Draft                                               H. Layec
draft-mavrakis-vemmi-url-spec-03.txt                         K. Kartmann
December 26, 1996                                 Expires -> June 25, 1996

                           VEMMI URL Specification

                   <draft-mavrakis-vemmi-url-spec-03.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 ETS 300 709 [1]).

Mavrakis, Layec & Kartmann                                     Page 1


VEMMI URL Specification                                     26 Dec 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                                     26 Dec 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
ETS 300 709).

A VEMMI URL takes the form:
    vemmi://<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 <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. 

Mavrakis, Layec & Kartmann                                     Page 3


VEMMI URL Specification                                     26 Dec 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> 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

Mavrakis, Layec & Kartmann                                     Page 4


VEMMI URL Specification                                     26 Dec 1996

be used in such case to switch to vemmi protocol [9]. This possible use
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 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) [14]. 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:

Mavrakis, Layec & Kartmann                                     Page 5


VEMMI URL Specification                                     26 Dec 1996

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
   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) 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 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...

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:
...establishing TCP/IP link to mctel.fr...
service:        demo;$USERDATA=smith;account=1234
200 OK
...starting VEMMI session...

Mavrakis, Layec & Kartmann                                     Page 6


VEMMI URL Specification                                     26 Dec 1996

------------------------------------------------------------------------
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 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], so the usual precautions outlined in [5] 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 

Mavrakis, Layec & Kartmann                                     Page 7


VEMMI URL Specification                                     26 Dec 1996

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,
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 assignement 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:

Mavrakis, Layec & Kartmann                                     Page 8


VEMMI URL Specification                                     26 Dec 1996

    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.

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
        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

Mavrakis, Layec & Kartmann                                     Page 9


VEMMI URL Specification                                     26 Dec 1996

        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:
- 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/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 
    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.

Mavrakis, Layec & Kartmann                                     Page 10


VEMMI URL Specification                                     26 Dec 1996

[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 11