home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2122 < prev    next >
Text File  |  1997-03-28  |  25KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      D. Mavrakis
  8. Request for Comments: 2122                   Monaco Telematique MC-TEL
  9. Category: Standards Track                                     H. Layec
  10.                                                                   ETSI
  11.                                                            K. Kartmann
  12.                                           Telecommunication+Multimedia
  13.                                                             March 1997
  14.  
  15.                         VEMMI URL Specification
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. 1) Abstract
  26.  
  27.    A new URL scheme, "vemmi" is defined. It allows VEMMI client software
  28.    and VEMMI terminals to connect to multimedia interactive services
  29.    compliant to the VEMMI standard (Enhanced Man-Machine Interface for
  30.    Videotex and Multimedia/Hypermedia Information Retrieval Services),
  31.    sometimes abbreviated as "VErsatile MultiMedia Interface".
  32.  
  33.    VEMMI is a new international standard for on-line multimedia
  34.    services, that is both an ITU-T (International Telecommunications
  35.    Union, ex.  CCITT)  International Standard (T.107) [2] and an
  36.    European Standard (ETSI European Telecommunications Standard
  37.    Institute) standard (ETS 300 382  [3], obsoleted by ETS 300 709 [1]).
  38.  
  39.    VEMMI could be described as an on-line multimedia protocol describing
  40.    both the man-machine interface and the client/server exchange
  41.    protocol.  VEMMI operates usually on a single continuous session
  42.    between a client and a host and supports an object-oriented, event-
  43.    driven, client/server oriented and platform independent multimedia
  44.    interface. The well-known tcp port number 575 has been assigned by
  45.    IANA to the VEMMI protocol [13].
  46.  
  47.    A description of the VEMMI standard along with its last approved
  48.    version is publicly available on the Web: see the URL
  49.    http://www.etsi.fr/ecs/projects/vemmi/vemmi.htm). A presentation of
  50.    VEMMI can be found on http://www.mctel.fr/VEMMI/vemmien_intro.html
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Mavrakis, et. al.           Standards Track                     [Page 1]
  59.  
  60. RFC 2122                VEMMI URL Specification               March 1997
  61.  
  62.  
  63. 2) VEMMI URL scheme utility and operability:
  64.  
  65.    - VEMMI service selection: A VEMMI multimedia server will listen on
  66.      its VEMMI well-known port for incoming connections. The server
  67.      could of course be engaged in many simultaneous connections, and
  68.      after a connection is established, the terminal must be able to
  69.      select the desired VEMMI application, as a same system may host
  70.      different VEMMI applications.
  71.      The best mechanism to fully describe the VEMMI service to activate
  72.      is the URL mechanism.
  73.      - Reporting user action to a remote server: The VEMMI protocol
  74.      establishes a continuous TCP/IP link between the terminal and the
  75.      server during the whole user session. During a session managing
  76.      VEMMI objects, the user actions are usually reported back to the
  77.      server using the VEMMI user data report mechanism that is an
  78.      integral part of the VEMMI protocol.
  79.      However, in some case, the URL mechanism may be required to send
  80.      back reports to a remote host. VEMMI is for example able to display
  81.      HTML documents within a multimedia display area in a VEMMI dialog
  82.      box. these HTML documents may be managed either by the VEMMI server
  83.      (acting as a proxy gateway) or directly by the client software that
  84.      will issue itself the HTTP requests on the network and browse
  85.      across documents on the Web as a standard Web browser (the link to
  86.      the VEMMI server is kept and used for interacting with other VEMMI
  87.      objects and components but the VEMMI server may not be informed of
  88.      the user navigation on the Web inside the multimedia area).
  89.      In such a case, the URL mechanism could also be used to report the
  90.      user actions and commands within a HTML document to be reported to
  91.      the VEMMI server or even another system.
  92.    - Extension of Web browsers: The VEMMI protocol is quite
  93.      complementary to HTTP/HTML used by Web browsers, and several
  94.      networks operators have decided to support jointly Web and VEMMI
  95.      (seen as complementary protocols). Thanks to the VEMMI URL, Web
  96.      browsers will be able to activate a VEMMI client software module to
  97.      start a VEMMI session to the requested service when the user
  98.      activate a vemmi URL included in the HTML document.
  99.  
  100. 3) Description of the VEMMI scheme
  101.  
  102.    The VEMMI URL scheme is used to designate multimedia interactive
  103.    services conforming to the VEMMI standard (ITU/T T.107 and ETS 300
  104.    709).
  105.  
  106.    A VEMMI URL takes the form:
  107.        vemmi://<host>:<port>/<vemmiservice>;
  108.        <attribute>=<value>
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Mavrakis, et. al.           Standards Track                     [Page 2]
  115.  
  116. RFC 2122                VEMMI URL Specification               March 1997
  117.  
  118.  
  119.    as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the
  120.    port defaults to 575 (client software may choose to ignore the
  121.    optional port number in order to increase security). The
  122.    <vemmiservice> part is optional and may be omitted.
  123.  
  124.    This URL does not designate a data object, but rather a multimedia
  125.    interactive service. A VEMMI service starts a multimedia session
  126.    managing multimedia objects and interacting with the user during the
  127.    session. To the difference of other stateless protocols, the link
  128.    between the client and the server is usually maintained during the
  129.    whole session (although in some cases other mechanisms may be used,
  130.    see below).
  131.  
  132.    The <vemmiservice> is the name of the VEMMI service to activate. This
  133.    field is not mandatory and could be omitted for example if the remote
  134.    host manages only one VEMMI service or activates a VEMMI service by
  135.    default when no service is specified. If this field is omitted in the
  136.    URL and the server requests it, it is assumed that the VEMMI client
  137.    software will prompt the user for it.
  138.  
  139.    In addition, after the <vemmiservice>, optional attributes and values
  140.    (parameters) associated with the VEMMI service may be specified as
  141.    part of the URL. When present, each parameter (attribute/value pair)
  142.    is separated from each other and from the rest of the URL by a ";"
  143.    (semicolon). The name of the attribute and its value are separated by
  144.    a "=" (equal sign). If present, these fields are used to transmit
  145.    additional data useful for service selection or to request to perform
  146.    a specific processing. For example, the $USERDATA field can be
  147.    specified to transmit additional user-specified data to the VEMMI
  148.    service.
  149.  
  150. 4) Client/server dialog during service selection
  151.  
  152.    The VEMMI client will interpret the VEMMI URL to connect to the
  153.    remote host and to access the specified VEMMI service. After
  154.    connecting to the remote system, the host may prompt the VEMMI client
  155.    for service name and user identification.
  156.  
  157.    Before starting the VEMMI session, a VEMMI terminal is in 'standard'
  158.    mode and may display the data received from the network in a videotex
  159.    or telnet terminal window. As the VEMMI session may be started
  160.    anytime during an interactive videotex or telnet session, the VEMMI
  161.    service selection is performed by a simple dialog between the client
  162.    and the server.
  163.  
  164.    The service, username and password information are transmitted by the
  165.    client software to the host in answer to the corresponding requests
  166.    received from the host. The following behavior is expected from the
  167.  
  168.  
  169.  
  170. Mavrakis, et. al.           Standards Track                     [Page 3]
  171.  
  172. RFC 2122                VEMMI URL Specification               March 1997
  173.  
  174.  
  175.    client:
  176.    - wait for the optional request strings from the host server
  177.      ('service:', 'username:' and 'password:') and answer them
  178.      (respectively by <vemmiservice> value defined in the URL and the
  179.      <username> and <password> entered by the user if required).  The
  180.      terminal answer may be sent automatically if the answers are known
  181.      (that is if they are specified in the URL or terminal
  182.      configuration) or it may prompt the user for the needed
  183.      informations.  When parameters (attribute and value pairs) are
  184.      present in the URL, these fields will be sent following the
  185.      <vemmiservice> transmitted to the host in answer to the 'service:'
  186.      request received from the host, separated from the <vemmiservice>
  187.      value by a semicolon.
  188.    - the client answers must always be followed by a Carriage Return
  189.      (CR). If a Line Feed (LF) is transmitted after the CR, it will be
  190.      ignored by the server.
  191.    - in both cases, the server may echo the characters received from the
  192.      client terminal, the received CR being echoed as CR LF. The server
  193.      may echo the password characters as stars or any other scrambled
  194.      output for safety purpose.
  195.    - the client must also be ready to start the VEMMI session as soon
  196.      as it receives the VEMMI_Open command. Before starting this VEMMI
  197.      session, the terminal is in 'standard' mode and may display the
  198.      data received from the network in a videotex or telnet terminal
  199.      window (this is the reason why the service, username and password
  200.      data are requested by the server using a telnet or videotex
  201.      compatible dialog).
  202.  
  203.    Should an error occur during VEMMI service activation, the remote
  204.    host may inform the user by displaying the error cause. It is
  205.    recommended that, when possible and applicable, the status code
  206.    syntax described in HTTP [8] [9] be used to facilitate automatic
  207.    processing by the client of the host answer during error or normal
  208.    operation.
  209.  
  210.    If a VEMMI client software wants to request a VEMMI object without
  211.    establishing a continuous VEMMI session, such a request may also be
  212.    performed using a HTTP request for the vemmi object encoded using the
  213.    Internet media type application/vemmi (pending registration by IANA
  214.    [10]). In the same way, HTTP could be used in some cases to exchange
  215.    data pertaining to a VEMMI session with or without setting the keep-
  216.    alive keyword in the Connection header to request a persistent
  217.    connection [9]. Protocol switching using the upgrade header field may
  218.    be used in such case to switch to vemmi protocol [9]. This possible
  219.    use of HTTP for VEMMI is not described in this document.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Mavrakis, et. al.           Standards Track                     [Page 4]
  227.  
  228. RFC 2122                VEMMI URL Specification               March 1997
  229.  
  230.  
  231. 5) Proposed syntax
  232.  
  233.    The proposed BNF syntax is encoded as specified in RFC 1738 [5] [14]:
  234.  
  235. ; vemmi (see ITU-T T.107 and ETSI ETS 300 709)
  236.  
  237. vemmiurl      = "vemmi://" hostport [ "/" vemmiservice *[ parameter ] ]
  238. vemmiservice  = *[ uchar | "/" | "?" | ":" | "@" | "&" | "=" ]
  239. parameter     = ";" attribute "=" value
  240. attribute     = *[ uchar | "/" | "?" | ":" | "@" | "&" ]
  241. value         = *[ uchar | "/" | "?" | ":" | "@" | "&" ]
  242.  
  243.    This syntax: - allows the user to specify the remote host address by
  244.      its name or numeric address. Although he could select a specific
  245.      port, it is expected the information providers and VEMMI software
  246.      will mostly use the port number assigned to VEMMI (575) [13]. For
  247.      security reasons, the username and password could not be specified
  248.      in the URL.
  249.    - allows him to select a specific VEMMI service if the remote host
  250.      manages several different VEMMI services.
  251.    - allows also to send additional data to the service using the
  252.      parameter syntax, either during the service selection phase or when
  253.      the user selects a vemmi hyperlink within a HTML document displayed
  254.      in a VEMMI multimedia area. To the difference of the params syntax
  255.      used in [4], the parameter syntax requires each value to be labeled
  256.      by an attribute. The parameter attribute names are case-
  257.      insensitive. Parameter values may or may not be case-sensitive,
  258.      depending on the attribute.
  259.  
  260.    All the values of fieldname beginning by a dollar ($) sign are
  261.    reserved for specific use, including:
  262.    - $COMMAND: VEMMI command to be returned to the host when the VEMMI
  263.      session do not use a continuous link.
  264.    - $CONTEXTDATA: context data.
  265.    - $OBJECT_REQUEST: requests the retransmission of a given VEMMI object.
  266.    - $USERDATA: user data specific by the user and to be processed by the
  267.      VEMMI service.
  268.  
  269. 6) Examples:
  270.  
  271.    Some examples of VEMMI URLs along with the corresponding
  272.    client/server dialog are presented below, they are for information
  273.    only:
  274.  
  275.    a) A simple VEMMI URL and the corresponding dialog for a VEMMI
  276.       service that does not enforce access control might be:
  277.         URL: vemmi://zeus.mctel.fr/demo
  278.  
  279.  
  280.  
  281.  
  282. Mavrakis, et. al.           Standards Track                     [Page 5]
  283.  
  284. RFC 2122                VEMMI URL Specification               March 1997
  285.  
  286.  
  287.       In this case, the exchange between client and server will be as
  288.       follow (the server requests are presented left, client answers
  289.       right):
  290.    service:        demo
  291.    200 OK                     {status code returned by the VEMMI host}
  292.  
  293.    b) The service name may be omitted (for example if the remote server
  294.       hosts only one VEMMI service), and the URL might then be:
  295.         URL: vemmi://zeus.mctel.fr
  296.       In this case, the VEMMI interactive session is started immediately
  297.       by the host without requesting first the service name (should the
  298.       client receive a service request from the host, it will prompt the
  299.       user for service name).
  300.  
  301.    c) The URL could not include the username and password. In this case,
  302.       should they be requested by the host, the VEMMI client may use a
  303.       default value specified for this service or prompt the user for
  304.       them (for example it could propose anonymous and user e-mail
  305.       address as defaults):
  306.         URL: vemmi://mctel.fr/demo
  307.       In this case, the exchange between client and server may be as
  308.       follows (server requests at the left, client answers at the right):
  309.    service:        demo
  310.    login:          anonymous       {user has been prompted for username}
  311.    password:       mavrakis@ties.itu.ch  {user prompted for password}
  312.    401 Unauthorized                {an anonymous user is not allowed to
  313.                                     access the service}
  314.  
  315.    d) Some services may use additional data transmitted in the parameter
  316.       fields, for example:
  317.         URL: vemmi://mctel.fr/demo;$USERDATA=smith;account=1234
  318.       If no access check is done by the host, the dialog might be:
  319.    service:        demo;$USERDATA=smith;account=1234
  320.    200 OK
  321.     ...starting VEMMI session...
  322.  
  323. 7)  Procedure to use when a VEMMI URL is encountered in a HTML document
  324.     without VEMMI support:
  325.  
  326.    The VEMMI URL support may be built-in in some Web browsers, or
  327.    offered by an associated software or plug-in interworking with the
  328.    user browser, for example using the WWW_RegisterProtocol API command
  329.    to register the new VEMMI protocol.
  330.  
  331.    When a Web browser encounters a VEMMI URL without having VEMMI support,
  332.    two cases may occur:
  333.    - some browsers will detect an unrecognized scheme and signal an
  334.      unrecoverable error directly.
  335.  
  336.  
  337.  
  338. Mavrakis, et. al.           Standards Track                     [Page 6]
  339.  
  340. RFC 2122                VEMMI URL Specification               March 1997
  341.  
  342.  
  343.    - others will manage it as a relative URL [4] and will build a
  344.      complete URL including the VEMMI URL and will request it from the
  345.      host having sent the current document. In this case the host will
  346.      usually return the error "not found".
  347.  
  348.    Among the mechanisms that could be used in order to offer a friendly
  349.    interface to both users with and without VEMMI support:
  350.    - when the second case occurs and the relative URL including the
  351.      vemmi:// string is transmitted to the server, the HTTPD server may
  352.      be modified in order to recognize such URL and to propose the
  353.      downloading of a VEMMI client software.
  354.    - the HTML document including the vemmi URL allowing to start the
  355.      VEMMI session may propose both options, for example:
  356.         If your browser supports VEMMI, directly
  357.         <A HREF="vemmi://ares.mctel.fr/TEST">start the interactive
  358.         multimedia service</A>, otherwise
  359.         <A HREF="ftp://ftp.mctel.fr/vemmi.exe">download first a VEMMI
  360.         client software</A>.
  361.    - the application/vemmi MIME type is defined below (to allow for
  362.      example exchange of vemmi objects). A possible way is for the
  363.      server to look in the HTTP Accept header field and to deduce that if
  364.      application/vemmi is supported, then the VEMMI support exists (in
  365.      this case, application/vemmi is to be defined in the browser and
  366.      associated with the vemmi decoder).
  367.  
  368. 8) Security Considerations:
  369.  
  370.    The VEMMI URL scheme is subject to the same security implications as
  371.    the general URL scheme [5] [14], so the usual precautions outlined in
  372.    [5] [14] apply (for example, it is not allowed to store the username
  373.    and password in the URLs).
  374.  
  375.    Furthermore, among VEMMI objects that could be used during the
  376.    interactive session, metacode objects (representing a sequence of
  377.    VEMMI commands) and operative objects (they are executable programs
  378.    to be run on the client platform) may be downloaded and/or started.
  379.  
  380.    In order to protect the user against the activation of an harmful
  381.    operative object, it is strongly recommended that the users use the
  382.    configuration menu of their VEMMI software to disable the option of
  383.    running operative objects when receiving potentially unsafe VEMMI
  384.    objects, or at least enable the option to request first user approval
  385.    before starting the execution of an operative object.
  386.  
  387.    The VEMMI remote interactive services may vary widely in their access
  388.    control policies; in practice, when a prompt for username or password
  389.    is received, the VEMMI terminal should request them from the user.
  390.    The VEMMI terminal implementation could support additional features,
  391.  
  392.  
  393.  
  394. Mavrakis, et. al.           Standards Track                     [Page 7]
  395.  
  396. RFC 2122                VEMMI URL Specification               March 1997
  397.  
  398.  
  399.    for example proposing by default "anonymous" as username and the user
  400.    Internet e-mail address as password, or looking in an encrypted local
  401.    database for user identification on this service.
  402.  
  403.    Such an identification mechanism using the username/password scheme
  404.    is unsecure and is provided for backwards compatibility only. The
  405.    VEMMI services requiring a safe identification procedure must rely on
  406.    other alternative mechanisms (e.g. S/KEY or other). In numerous
  407.    cases, the user identification procedure will be performed by the
  408.    VEMMI service.
  409.  
  410. 9) application/vemmi MIME type
  411.  
  412.    VEMMI is a multimedia interactive service and VEMMI objects are
  413.    usually exchanged through a continuous VEMMI multimedia session.
  414.    However, VEMMI objects could also be transmitted and exchanged using
  415.    other mechanisms, for example using HTTP, through e-mail, and so
  416.    on... The assignment of a MIME media type application/vemmi will
  417.    allow this transport and exchange of VEMMI objects, and this
  418.    paragraph describes this MIME type.
  419.  
  420.    Furthermore, for Web browsers not supporting the addition of new URL
  421.    protocol scheme, the VEMMI MIME type may also be used to transmit,
  422.    instead of a VEMMI object, a text file containing the VEMMI URL to
  423.    activate to connect to a VEMMI server.
  424.  
  425. 9A) DESCRIPTION:
  426.  
  427.    MIME media type name: "application"
  428.  
  429.    MIME subtype name: "vemmi"
  430.  
  431.    Required parameters: none
  432.  
  433.    Optional parameters:
  434.    - version:
  435.      an optional version number may be specified, in the format:
  436.  
  437.        version=<integer>
  438.  
  439.      The version number is a numeric integer whose is encoded as the
  440.      <version> parameter defined in ETS 300 709 (e.g. version=100), and
  441.      whose the first digit represents the major VEMMI version number.
  442.      It must be pointed out that the VEMMI objects includes the VEMMI
  443.      version and a timestamp.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Mavrakis, et. al.           Standards Track                     [Page 8]
  451.  
  452. RFC 2122                VEMMI URL Specification               March 1997
  453.  
  454.  
  455. 9B) ENCODING CONSIDERATIONS:
  456.  
  457.    The "base64" mechanism is preferred because VEMMI use a native 8-bit
  458.    binary file format. However, as VEMMI includes its own 7-bits
  459.    encoding mechanisms, VEMMI data could also be transmitted in 7-bit
  460.    mode.
  461.  
  462. 9C) SECURITY CONSIDERATIONS:
  463.  
  464.    Refer to paragraph 8.
  465.  
  466. 9D) INTEROPERABILITY CONSIDERATIONS:
  467.  
  468.    VEMMI is designed to be fully platform independent, and the VEMMI
  469.    objects and contents could interoperate between any platform. The
  470.    only exception are the VEMMI operative objects that could be binary
  471.    programs specific to a given hardware platform and operating system.
  472.  
  473. 10) Liaison address:
  474.  
  475.    For all technical questions regarding this request, please contact:
  476.  
  477.            Daniel Mavrakis
  478.            Monaco Telematique MC-TEL
  479.            P.O. Box 225
  480.            MC 98004 Monte-Carlo Cedex
  481.            PRINCIPALITY OF MONACO
  482.            EMail: Mavrakis@mctel.fr
  483.            Tel: (+377) 9216 8860
  484.            Fax: (+377) 9330 4545
  485.  
  486.    Comments may also be addressed to:
  487.  
  488.            Mr. Herve Layec,
  489.            ETSI STC TE1
  490.            06921 SOPHIA ANTIPOLIS Cedex
  491.            FRANCE
  492.            EMail: herve.layec@dri.france-telecom.fr
  493.            Tel: (+33) 2 99 12 73 01
  494.            Fax: (+33) 2 99 38 49 61
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Mavrakis, et. al.           Standards Track                     [Page 9]
  507.  
  508. RFC 2122                VEMMI URL Specification               March 1997
  509.  
  510.  
  511.            Mr. Kurt Kartmann
  512.            Consulting
  513.            Telecommunication+Multimedia
  514.            Gabelsbergerstr. 2
  515.            D-64807 DIEBURG
  516.            GERMANY
  517.            EMail: k.kartmann@t-online.de
  518.            Tel: (+49) 6071 1528
  519.            c/o Deutsche Telekom AG
  520.            Tel. (+49)6151 834965, Fax (+49) 6151 834284
  521.  
  522.    The authors thank the other members of the ETSI TE1 VEMMI Working
  523.    Group for their comments:
  524.  
  525.       - Michael Blaschitz (michael.blaschitz@etsi.fr)
  526.       - Agnelo Fernandes (agnelo@telepac.pt)
  527.       - Daniel Allonsius (daniel.allonsius@is.belgacom.be)
  528.       - Stefaan Herrebout (Stefaan.Herrebout@mail.interpac.be)
  529.       - Francisca Oliva (oliva@tid.es)
  530.       - Herwart Wermescher (Herwart.Wermescher@infonova.telecom.at)
  531.  
  532. 11) References:
  533.  
  534.    [1] "Enhanced Man-Machine Interface for Videotex and
  535.        Multimedia/Hypermedia Information Retrieval Services (VEMMI
  536.        revision 1)", ETS 300 709 standard (European Telecommunications
  537.        Standards Institute), September 1996.
  538.        This document is available on the Web in HTML format: see
  539.        http://www.etsi.fr/ecs/projects/vemmi/vemmi.htm
  540.  
  541.    [2] "Enhanced Man-Machine Interface for Videotex and Other
  542.        Information Retrieval Services (VEMMI)", ITU-T T.107 standard
  543.        (International Telecommunications Union), March 1995.
  544.  
  545.    [3] "Videotex Enhanced Man-Machine Interface service (VEMMI)",
  546.        ETS 300 382 standard (European Telecommunications Standards
  547.        Institute), February 1995.
  548.  
  549.    [4] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC
  550.        Irvine, June 1995.
  551.  
  552.    [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
  553.        Locators (URL)", RFC 1738, December 1994.
  554.  
  555.    [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  556.        October 1994.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Mavrakis, et. al.           Standards Track                    [Page 10]
  563.  
  564. RFC 2122                VEMMI URL Specification               March 1997
  565.  
  566.  
  567.    [7] Mavrakis, D., "VEMMI and Internet", TD 44, ETSI TE1 plenary
  568.        meeting in Brussels, October 20, 1995.
  569.  
  570.    [8] Berners-Lee, T., Fielding, R., and H. Frystyk: "Hypertext Transfer
  571.        Protocol - HTTP/1.0", RFC 1945, MIT/LCS, UC Irvine, May 1996.
  572.  
  573.    [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
  574.        Berners-Lee, Transfer Protocol - HTTP/1.1", RFC 2068, UC Irvine,
  575.        January 1997.
  576.  
  577.    [10] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
  578.         Mail Extensions (MIME) Part Four Registration Procedures", BCP
  579.         13, RFC 2048, November 1996.
  580.  
  581.    [11] Masinter, L., Zigmond, D., and H. Alvestrand, "Guidelines and
  582.         Process for new URL Schemes", Work in Progress.
  583.  
  584.    [12] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language
  585.         Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
  586.  
  587.    [13] "Port Numbers",
  588.         ftp://venera.isi.edu/in-notes/iana/assignments/port-numbers
  589.  
  590.    [14] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
  591.         Locators (URL)", Work in Progress.
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Mavrakis, et. al.           Standards Track                    [Page 11]
  619.  
  620.