As per Relevance of the word terminal, we have this rfc below:
Network Working Group D.
Request for Comments: 2122 Monaco Telematique MC-
Category: Standards Track H.
K.
Telecommunication+
March 1997
VEMMI URL
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1)
A new URL scheme, "vemmi" is defined. It allows VEMMI client
and VEMMI terminals to connect to multimedia interactive
compliant to the VEMMI standard (Enhanced Man-Machine Interface
Videotex and Multimedia/Hypermedia Information Retrieval Services),
sometimes abbreviated as "VErsatile MultiMedia Interface".
VEMMI is a new international standard for on-line
services, that is both an ITU-T (International
Union, ex. CCITT) International Standard (T.107) [2] and
European Standard (ETSI European Telecommunications
Institute) standard (ETS 300 382 [3], obsoleted by ETS 300 709 [1]).
VEMMI could be described as an on-line multimedia protocol
both the man-machine interface and the client/server
protocol. VEMMI operates usually on a single continuous
between a client and a host and supports an object-oriented, event
driven, client/server oriented and platform independent
interface. The well-known tcp port number 575 has been assigned
IANA to the VEMMI protocol [13].
A description of the VEMMI standard along with its last
version is publicly available on the Web: see the
http://www.etsi.fr/ecs/projects/vemmi/vemmi.htm). A presentation
VEMMI can be found on http://www.mctel.fr/VEMMI/vemmien_intro.
Mavrakis, et. al. Standards Track [Page 1]
RFC 2122 VEMMI URL Specification March 1997
2) VEMMI URL scheme utility and operability
- VEMMI service selection: A VEMMI multimedia server will listen
its VEMMI well-known port for incoming connections. The
could of course be engaged in many simultaneous connections,
after a connection is established, the terminal must be able
select the desired VEMMI application, as a same system may
different VEMMI applications
The best mechanism to fully describe the VEMMI service to
is the URL mechanism
- Reporting user action to a remote server: The VEMMI
establishes a continuous TCP/IP link between the terminal and
server during the whole user session. During a session
VEMMI objects, the user actions are usually reported back to
server using the VEMMI user data report mechanism that is
integral part of the VEMMI protocol
However, in some case, the URL mechanism may be required to
back reports to a remote host. VEMMI is for example able to
HTML documents within a multimedia display area in a VEMMI
box. these HTML documents may be managed either by the VEMMI
(acting as a proxy gateway) or directly by the client software
will issue itself the HTTP requests on the network and
across documents on the Web as a standard Web browser (the link
the VEMMI server is kept and used for interacting with other
objects and components but the VEMMI server may not be informed
the user navigation on the Web inside the multimedia area).
In such a case, the URL mechanism could also be used to report
user actions and commands within a HTML document to be reported
the VEMMI server or even another system
- Extension of Web browsers: The VEMMI protocol is
complementary to HTTP/HTML used by Web browsers, and
networks operators have decided to support jointly Web and
(seen as complementary protocols). Thanks to the VEMMI URL,
browsers will be able to activate a VEMMI client software module
start a VEMMI session to the requested service when the
activate a vemmi URL included in the HTML document
3) Description of the VEMMI
The VEMMI URL scheme is used to designate multimedia
services conforming to the VEMMI standard (ITU/T T.107 and ETS 300
709).
A VEMMI URL takes the form
vemmi://:/;
<attribute>=
Mavrakis, et. al. Standards Track [Page 2]
RFC 2122 VEMMI URL Specification March 1997
as specified in Section 3.1. of RFC 1738. If : is omitted,
port defaults to 575 (client software may choose to ignore
optional port number in order to increase security).
part is optional and may be omitted
This URL does not designate a data object, but rather a
interactive service. A VEMMI service starts a multimedia
managing multimedia objects and interacting with the user during
session. To the difference of other stateless protocols, the
between the client and the server is usually maintained during
whole session (although in some cases other mechanisms may be used
see below).
The is the name of the VEMMI service to activate.
field is not mandatory and could be omitted for example if the
host manages only one VEMMI service or activates a VEMMI service
default when no service is specified. If this field is omitted in
URL and the server requests it, it is assumed that the VEMMI
software will prompt the user for it
In addition, after the , optional attributes and
(parameters) associated with the VEMMI service may be specified
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
a "=" (equal sign). If present, these fields are used to
additional data useful for service selection or to request to
a specific processing. For example, the $USERDATA field can
specified to transmit additional user-specified data to the
service
4) Client/server dialog during service
The VEMMI client will interpret the VEMMI URL to connect to
remote host and to access the specified VEMMI service.
connecting to the remote system, the host may prompt the VEMMI
for service name and user identification
Before starting the VEMMI session, a VEMMI terminal is in 'standard
mode and may display the data received from the network in a
or telnet terminal window. As the VEMMI session may be
anytime during an interactive videotex or telnet session, the
service selection is performed by a simple dialog between the
and the server
The service, username and password information are transmitted by
client software to the host in answer to the corresponding
received from the host. The following behavior is expected from
Mavrakis, et. al. Standards Track [Page 3]
RFC 2122 VEMMI URL Specification March 1997
client
- wait for the optional request strings from the host
('service:', 'username:' and 'password:') and answer
(respectively by value defined in the URL and
<username> and <password> entered by the user if required).
terminal answer may be sent automatically if the answers are
(that is if they are specified in the URL or
configuration) or it may prompt the user for the
informations. When parameters (attribute and value pairs)
present in the URL, these fields will be sent following
transmitted to the host in answer to the 'service:'
request received from the host, separated from the
value by a semicolon
- the client answers must always be followed by a Carriage
(CR). If a Line Feed (LF) is transmitted after the CR, it will
ignored by the server
- in both cases, the server may echo the characters received from
client terminal, the received CR being echoed as CR LF. The
may echo the password characters as stars or any other
output for safety purpose
- the client must also be ready to start the VEMMI session as
as it receives the VEMMI_Open command. Before starting this
session, the terminal is in 'standard' mode and may display
data received from the network in a videotex or telnet
window (this is the reason why the service, username and
data are requested by the server using a telnet or
compatible dialog).
Should an error occur during VEMMI service activation, the
host may inform the user by displaying the error cause. It
recommended that, when possible and applicable, the status
syntax described in HTTP [8] [9] be used to facilitate
processing by the client of the host answer during error or
operation
If a VEMMI client software wants to request a VEMMI object
establishing a continuous VEMMI session, such a request may also
performed using a HTTP request for the vemmi object encoded using
Internet media type application/vemmi (pending registration by
[10]). In the same way, HTTP could be used in some cases to
data pertaining to a VEMMI session with or without setting the keep
alive keyword in the Connection header to request a
connection [9]. Protocol switching using the upgrade header field
be used in such case to switch to vemmi protocol [9]. This
use of HTTP for VEMMI is not described in this document
Mavrakis, et. al. Standards Track [Page 4]
RFC 2122 VEMMI URL Specification March 1997
5) Proposed
The proposed BNF syntax is encoded as specified in RFC 1738 [5] [14]:
; vemmi (see ITU-T T.107 and ETSI ETS 300 709)
vemmiurl = "vemmi://" hostport [ "/" vemmiservice *[ parameter ] ]
vemmiservice = *[ uchar | "/" | "?" | ":" | "@" | "&" | "=" ]
parameter = ";" attribute "="
attribute = *[ uchar | "/" | "?" | ":" | "@" | "&" ]
value = *[ uchar | "/" | "?" | ":" | "@" | "&" ]
This syntax: - allows the user to specify the remote host address
its name or numeric address. Although he could select a
port, it is expected the information providers and VEMMI
will mostly use the port number assigned to VEMMI (575) [13].
security reasons, the username and password could not be
in the URL
- allows him to select a specific VEMMI service if the remote
manages several different VEMMI services
- allows also to send additional data to the service using
parameter syntax, either during the service selection phase or
the user selects a vemmi hyperlink within a HTML document
in a VEMMI multimedia area. To the difference of the params
used in [4], the parameter syntax requires each value to be
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
reserved for specific use, including
- $COMMAND: VEMMI command to be returned to the host when the
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
VEMMI service
6) Examples
Some examples of VEMMI URLs along with the
client/server dialog are presented below, they are for
only
a) A simple VEMMI URL and the corresponding dialog for a
service that does not enforce access control might be
URL: vemmi://zeus.mctel.fr/
Mavrakis, et. al. Standards Track [Page 5]
RFC 2122 VEMMI URL Specification March 1997
In this case, the exchange between client and server will be
follow (the server requests are presented left, client
right):
service:
200 OK {status code returned by the VEMMI host
b) The service name may be omitted (for example if the remote
hosts only one VEMMI service), and the URL might then be
URL: vemmi://zeus.mctel.
In this case, the VEMMI interactive session is started
by the host without requesting first the service name (should
client receive a service request from the host, it will prompt
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
default value specified for this service or prompt the user
them (for example it could propose anonymous and user e-
address as defaults):
URL: vemmi://mctel.fr/
In this case, the exchange between client and server may be
follows (server requests at the left, client answers at the right):
service:
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
access the service
d) Some services may use additional data transmitted in the
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
service: demo;$USERDATA=smith;account=1234
200
...starting VEMMI session...
7) Procedure to use when a VEMMI URL is encountered in a HTML
without VEMMI support
The VEMMI URL support may be built-in in some Web browsers,
offered by an associated software or plug-in interworking with
user browser, for example using the WWW_RegisterProtocol API
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
unrecoverable error directly
Mavrakis, et. al. Standards Track [Page 6]
RFC 2122 VEMMI URL Specification March 1997
- others will manage it as a relative URL [4] and will build
complete URL including the VEMMI URL and will request it from
host having sent the current document. In this case the host
usually return the error "not found".
Among the mechanisms that could be used in order to offer a
interface to both users with and without VEMMI support
- when the second case occurs and the relative URL including
vemmi:// string is transmitted to the server, the HTTPD server
be modified in order to recognize such URL and to propose
downloading of a VEMMI client software
- the HTML document including the vemmi URL allowing to start
VEMMI session may propose both options, for example
If your browser supports VEMMI,
start the
multimedia service,
download first a
client software.
- the application/vemmi MIME type is defined below (to allow
example exchange of vemmi objects). A possible way is for
server to look in the HTTP Accept header field and to deduce that
application/vemmi is supported, then the VEMMI support exists (
this case, application/vemmi is to be defined in the browser
associated with the vemmi decoder).
8) Security Considerations
The VEMMI URL scheme is subject to the same security implications
the general URL scheme [5] [14], so the usual precautions outlined
[5] [14] apply (for example, it is not allowed to store the
and password in the URLs).
Furthermore, among VEMMI objects that could be used during
interactive session, metacode objects (representing a sequence
VEMMI commands) and operative objects (they are executable
to be run on the client platform) may be downloaded and/or started
In order to protect the user against the activation of an
operative object, it is strongly recommended that the users use
configuration menu of their VEMMI software to disable the option
running operative objects when receiving potentially unsafe
objects, or at least enable the option to request first user
before starting the execution of an operative object
The VEMMI remote interactive services may vary widely in their
control policies; in practice, when a prompt for username or
is received, the VEMMI terminal should request them from the user
The VEMMI terminal implementation could support additional features
Mavrakis, et. al. Standards Track [Page 7]
RFC 2122 VEMMI URL Specification March 1997
for example proposing by default "anonymous" as username and the
Internet e-mail address as password, or looking in an encrypted
database for user identification on this service
Such an identification mechanism using the username/password
is unsecure and is provided for backwards compatibility only.
VEMMI services requiring a safe identification procedure must rely
other alternative mechanisms (e.g. S/KEY or other). In
cases, the user identification procedure will be performed by
VEMMI service
9) application/vemmi MIME
VEMMI is a multimedia interactive service and VEMMI objects
usually exchanged through a continuous VEMMI multimedia session
However, VEMMI objects could also be transmitted and exchanged
other mechanisms, for example using HTTP, through e-mail, and
on... The assignment of a MIME media type application/vemmi
allow this transport and exchange of VEMMI objects, and
paragraph describes this MIME type
Furthermore, for Web browsers not supporting the addition of new
protocol scheme, the VEMMI MIME type may also be used to transmit
instead of a VEMMI object, a text file containing the VEMMI URL
activate to connect to a VEMMI server
9A) DESCRIPTION
MIME media type name: "application
MIME subtype name: "vemmi
Required parameters:
Optional parameters
- version
an optional version number may be specified, in the format
version=
The version number is a numeric integer whose is encoded as
parameter defined in ETS 300 709 (e.g. version=100),
whose the first digit represents the major VEMMI version number
It must be pointed out that the VEMMI objects includes the
version and a timestamp
Mavrakis, et. al. Standards Track [Page 8]
RFC 2122 VEMMI URL Specification March 1997
9B) ENCODING CONSIDERATIONS
The "base64" mechanism is preferred because VEMMI use a native 8-
binary file format. However, as VEMMI includes its own 7-
encoding mechanisms, VEMMI data could also be transmitted in 7-
mode
9C) SECURITY CONSIDERATIONS
Refer to paragraph 8.
9D) INTEROPERABILITY CONSIDERATIONS
VEMMI is designed to be fully platform independent, and the
objects and contents could interoperate between any platform.
only exception are the VEMMI operative objects that could be
programs specific to a given hardware platform and operating system
10) Liaison address
For all technical questions regarding this request, please contact
Daniel
Monaco Telematique MC-
P.O. Box 225
MC 98004 Monte-Carlo
PRINCIPALITY OF
EMail: Mavrakis@mctel.
Tel: (+377) 9216 8860
Fax: (+377) 9330 4545
Comments may also be addressed to
Mr. Herve Layec
ETSI STC TE
06921 SOPHIA ANTIPOLIS
EMail: herve.layec@dri.france-telecom.
Tel: (+33) 2 99 12 73 01
Fax: (+33) 2 99 38 49 61
Mavrakis, et. al. Standards Track [Page 9]
RFC 2122 VEMMI URL Specification March 1997
Mr. Kurt
Telecommunication+
Gabelsbergerstr. 2
D-64807
EMail: k.kartmann@t-online.
Tel: (+49) 6071 1528
c/o Deutsche Telekom
Tel. (+49)6151 834965, Fax (+49) 6151 834284
The authors thank the other members of the ETSI TE1 VEMMI
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
Multimedia/Hypermedia Information Retrieval Services (
revision 1)", ETS 300 709 standard (European
Standards Institute), September 1996.
This document is available on the Web in HTML format:
http://www.etsi.fr/ecs/projects/vemmi/vemmi.
[2] "Enhanced Man-Machine Interface for Videotex and
Information Retrieval Services (VEMMI)", ITU-T T.107
(International Telecommunications Union), March 1995.
[3] "Videotex Enhanced Man-Machine Interface service (VEMMI)",
ETS 300 382 standard (European Telecommunications
Institute), February 1995.
[4] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
Irvine, June 1995.
[5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Locators (URL)", RFC 1738, December 1994.
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
Mavrakis, et. al. Standards Track [Page 10]
RFC 2122 VEMMI URL Specification March 1997
[7] Mavrakis, D., "VEMMI and Internet", TD 44, ETSI TE1
meeting in Brussels, October 20, 1995.
[8] Berners-Lee, T., Fielding, R., and H. Frystyk: "Hypertext
Protocol - HTTP/1.0", RFC 1945, MIT/LCS, UC Irvine, May 1996.
[9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T
Berners-Lee, Transfer Protocol - HTTP/1.1", RFC 2068, UC Irvine
January 1997.
[10] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Mail Extensions (MIME) Part Four Registration Procedures",
13, RFC 2048, November 1996.
[11] Masinter, L., Zigmond, D., and H. Alvestrand, "Guidelines
Process for new URL Schemes", Work in Progress
[12] Berners-Lee, T., and D. Connolly, "Hypertext Markup
Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
[13] "Port Numbers",
ftp://venera.isi.edu/in-notes/iana/assignments/port-
[14] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Locators (URL)", Work in Progress
Mavrakis, et. al. Standards Track [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
