VEMMI URL Specification                                     22 Feb 1996

ETSI TE1 VEMMI Working Group                                 D. Mavrakis
Internet-Draft                                               H. Layec
draft-mavrakis-vemmi-url-spec-00.txt                         K. Kartmann
February 22, 1996                             Expires -> August 21, 1996

                           VEMMI URL Specification


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 (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

     Distribution of this document is unlimited. Please send comments
     to <>. This specification is also available via
     the Web in HTML form, see:

1) Abstract

A new URL scheme, "vemmi" is defined. It allows vemmi client software to
connect to multimedia interactive services compliant to the VEMMI
standard (Enhanced Man-Machine Interface for Videotex and
Multimedia/Hypermedia Information Retrieval Services).

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                                     22 Feb 1996

VEMMI could be described as a 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
port number 575 has been assigned by IANA to the VEMMI protocol.

A description of the VEMMI standard along with its last approved version
is publicly available on the Web: see the URL A presentation of VEMMI could
be found on

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
  VEMMI application desired, as a same system may host different VEMMI
  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                                     22 Feb 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:

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.

This URL does not designate a data object, but rather a multimedia
interactive service. A VEMMI service start 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 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).

The <vemmiservice> is the name of the VEMMI service to activate, and
will be sent in answer to the service command received from the host.
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. In addition, after the
<vemmiservice>, optional attributes and values associated with the VEMMI
service may be specified as part of the URL. When present, each
attribute/value pair is separated from each other and from the rest of
the URL by a ";" (semicolon). The name of the attributes and its value

Mavrakis, Layec & Kartmann                                     Page 3

VEMMI URL Specification                                     22 Feb 1996

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 additionnal user-specified data to the VEMMI
service. These fields will be sent following the <vemmiservice>
transmitted to the host in answer to the service command received from
the host.

Should an error occur during VEMMI service activation, the remote host
may inform the user by displaying the error cause. It is recommended
that, when possible and applicable, the status code syntax described in
HTTP [8] [9] be used to facilitate automatic processing by the client of
the host answer during error or normal operation.

If a VEMMI client software wants to request a VEMMI object without
establishing a continuous VEMMI session, such a request may also be
performed using a HTTP request for the vemmi object encoded using the
Internet media type application/vemmi (pending registration by IANA
[10]). In the same way, HTTP could be used in some cases to exchange
data pertaining to a VEMMI session with or without setting the keep-
alive keyword in the Connection header to request a persistent
connection [9]. Protocol switching using the upgrade header field may
be used in such case to switch to vemmi protocol [9]. This possible use
of HTTP for VEMMI is not described in this document.

4) 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 selects a specific port, it is expected the information
  providers and VEMMI software will mostly use the port number assigned
  to VEMMI (575).
- allows him to select a specific VEMMI service if the remote host
  manages several different VEMMI services.
- allows also to send additionnal 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

Mavrakis, Layec & Kartmann                                     Page 4

VEMMI URL Specification                                     22 Feb 1996

  in [4], the parameter syntax requires each value to be labelled by an
  attribute. The parameter attribute names are case-insensitive.
  Parameter values may or may not be case-sensitive, depending on the

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: request the retransmission of a given VEMMI object.
- $USERDATA: user data specific by the user and to be processed by the
  VEMMI service.

5) Examples:

Some examples are presented below, they are for information only:

a) A simple VEMMI URL for a VEMMI service that does not enforce access
   control might be:
     URL: vemmi://
   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
service:        demo
200 OK                     {status code returned by the VEMMI host}
...starting VEMMI session...

b) If the remote server hosts only one VEMMI service, this field may be
   omitted and the URL might be:
     URL: vemmi://
   In this case, the VEMMI 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: vemmi://
   The exchange between the client and server will be:
...establishing TCP/IP link to
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.

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

Mavrakis, Layec & Kartmann                                     Page 5

VEMMI URL Specification                                     22 Feb 1996

   default specified for this service or prompt the user for them (for
   example it could propose anonymous and user e-mail address as
     URL: vemmi://
   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
service:        demo
login:          anonymous        {user has been prompted for username}
password:   {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) Some services may use additionnal data transmitted in the parameter
   fields, for example:
     URL: vemmi://;$USERDATA=smith;account=1234
   If no access check is done by the host, the dialog might be:
...establishing TCP/IP link to
service:        demo;$USERDATA=smith;account=1234
200 OK
...starting VEMMI session...

6)  Procedure to use when a VEMMI URL is encountered without VEMMI

The VEMMI URL support may be built in some Web browsers, or offered
by an associated software interworking with the user browser, for
example using the WWW_RegisterProtocol API command.

When a Web browser encounter a VEMMI URL without having VEMMI support,
two cases may occur:
- some browsers will detect an unrecognized scheme and signal an error
- 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 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 occur 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://">start the interactive
     multimedia service</A>, otherwise
     <A HREF="">download first a VEMMI
     client software</A>.

Mavrakis, Layec & Kartmann                                     Page 6

VEMMI URL Specification                                     22 Feb 1996

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

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

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

        Electronic mail:
        Tel: (+33) 92 16 88 60
        Fax: (+33) 93 30 45 45

Comments may also be addressed to:

        Mr. Herve Layec,
        ETSI STC TE1
        06921 SOPHIA ANTIPOLIS Cedex
        Tel: (+33) 99 12 73 01
        Fax: (+33) 99 38 49 61

Mavrakis, Layec & Kartmann                                     Page 7

VEMMI URL Specification                                     22 Feb 1996

        Mr. Kurt Kartmann
        Danet GmbH/Deutsche Telekom
        Gutenberg Str. 10
        D-64331 WEITERSTADT
        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 (
- Agnelo Fernandes (
- Daniel Allonsius (
- Stefaan Herrebout (
- Francisca Oliva (

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

[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

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

[8] T. Berners-Lee, R. Fielding, H. Frystyk,: "Hypertext Transfer
    Protocol - HTTP/1.0", Work in Progress (draft-ietf-http-v10-spec-
    04.txt), MIT/W3C, October 1995.

Mavrakis, Layec & Kartmann                                     Page 8

VEMMI URL Specification                                     22 Feb 1996

[9] R. Fielding, H. Frystyk, T. Berners-Lee: "Hypertext Transfer
    Protocol - HTTP/1.1", Work in Progress (draft-ietf-http-v11-spec-
    00.txt), UC Irvine, November 1995.

[10] J. Postel, "Media Type Registration Procedure", RFC 1590, March

[11] DRAFT: Considerations for the new UR* schemes

Mavrakis, Layec & Kartmann                                     Page 8