home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2017.txt < prev    next >
Text File  |  1996-10-10  |  9KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         N. Freed
  8. Request for Comments: 2017                      Innosoft International
  9. Category: Standards Track                                     K. Moore
  10.                                                University of Tennessee
  11.                                                  A. Cargille, WG Chair
  12.                                                           October 1996
  13.  
  14.  
  15.                          Definition of the URL
  16.                      MIME External-Body Access-Type
  17.  
  18. Status of this Memo
  19.  
  20.    This document specifies an Internet standards track protocol for the
  21.    Internet community, and requests discussion and suggestions for
  22.    improvements.  Please refer to the current edition of the "Internet
  23.    Official Protocol Standards" (STD 1) for the standardization state
  24.    and status of this protocol.  Distribution of this memo is unlimited.
  25.  
  26. 1.  Abstract
  27.  
  28.    This memo defines a new access-type for message/external-body MIME
  29.    parts for Uniform Resource Locators (URLs).  URLs provide schemes to
  30.    access external objects via a growing number of protocols, including
  31.    HTTP, Gopher, and TELNET.  An initial set of URL schemes are defined
  32.    in RFC 1738.
  33.  
  34. 2.  Introduction
  35.  
  36.    The Multipurpose Internet Message Extensions (MIME) define a facility
  37.    whereby an object can contain a reference or pointer to some form of
  38.    data rather than the actual data itself. This facility is embodied in
  39.    the message/external-body media type defined in RFC 1521.  Use of
  40.    this facility is growing as a means of conserving bandwidth when
  41.    large objects are sent to large mailing lists.
  42.  
  43.    Each message/external-body reference must specify a mechanism whereby
  44.    the actual data can be retrieved.  These mechanisms are called access
  45.    types, and RFC 1521 defines an initial set of access types: "FTP",
  46.    "ANON-FTP", "TFTP", "LOCAL-FILE", and "MAIL-SERVER".
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Freed, et. al.              Standards Track                     [Page 1]
  59.  
  60. RFC 2017                    URL Access-Type                 October 1996
  61.  
  62.  
  63.    Uniform Resource Locators, or URLs, also provide a means by which
  64.    remote data can be retrieved automatically.  Each URL string begins
  65.    with a scheme specification, which in turn specifies how the
  66.    remaining string is to be used in conjunction with some protocol to
  67.    retrieve the data. However, URL schemes exist for protocol operations
  68.    that have no corresponding MIME message/external-body access type.
  69.    Registering an access type for URLs therefore provides
  70.    message/external-body with access to the retrieval mechanisms of URLs
  71.    that are not currently available as access types.  It also provides
  72.    access to any future mechanisms for which URL schemes are developed.
  73.  
  74.    This access type is only intended for use with URLs that actually
  75.    retreive something. Other URL mechansisms, e.g.  mailto, may not be
  76.    used in this context.
  77.  
  78. 3.  Definition of the URL Access-Type
  79.  
  80.    The URL access-type is defined as follows:
  81.  
  82.     (1)   The name of the access-type is URL.
  83.  
  84.     (2)   A new message/external-body content-type parameter is
  85.           used to actually store the URL string. The name of the
  86.           parameter is also "URL", and this parameter is
  87.           mandatory for this access-type. The syntax and use of
  88.           this parameter is specified in the next section.
  89.  
  90.     (3)   The phantom body area of the message/external-body is
  91.           not used and should be left blank.
  92.  
  93.    For example, the following message illustrates how the URL access-
  94.    type is used:
  95.  
  96.     Content-type: message/external-body; access-type=URL;
  97.                   URL="http://www.foo.com/file"
  98.  
  99.     Content-type: text/html
  100.     Content-Transfer-Encoding: binary
  101.  
  102.     THIS IS NOT REALLY THE BODY!
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Freed, et. al.              Standards Track                     [Page 2]
  115.  
  116. RFC 2017                    URL Access-Type                 October 1996
  117.  
  118.  
  119. 3.1.  Syntax and Use of the URL parameter
  120.  
  121.    Using the ANBF notations and definitions of RFC 822 and RFC 1521, the
  122.    syntax of the URL parameter Is as follows:
  123.  
  124.      URL-parameter := <"> URL-word *(*LWSP-char URL-word) <">
  125.  
  126.      URL-word := token
  127.                  ; Must not exceed 40 characters in length
  128.  
  129.    The syntax of an actual URL string is given in RFC 1738.  URL strings
  130.    can be of any length and can contain arbitrary character content.
  131.    This presents problems when URLs are embedded in MIME body part
  132.    headers that are wrapped according to RFC 822 rules. For this reason
  133.    they are transformed into a URL-parameter for inclusion in a
  134.    message/external-body content-type specification as follows:
  135.  
  136.     (1)   A check is made to make sure that all occurrences of
  137.           SPACE, CTLs, double quotes, backslashes, and 8-bit
  138.           characters in the URL string are already encoded using
  139.           the URL encoding scheme specified in RFC 1738. Any
  140.           unencoded occurrences of these characters must be
  141.           encoded.  Note that the result of this operation is
  142.           nothing more than a different representation of the
  143.           original URL.
  144.  
  145.     (2)   The resulting URL string is broken up into substrings
  146.           of 40 characters or less.
  147.  
  148.     (3)   Each substring is placed in a URL-parameter string as a
  149.           URL-word, separated by one or more spaces.  Note that
  150.           the enclosing quotes are always required since all URLs
  151.           contain one or more colons, and colons are tspecial
  152.           characters [RFC 1521].
  153.  
  154.    Extraction of the URL string from the URL-parameter is even simpler:
  155.    The enclosing quotes and any linear whitespace are removed and the
  156.    remaining material is the URL string.
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Freed, et. al.              Standards Track                     [Page 3]
  171.  
  172. RFC 2017                    URL Access-Type                 October 1996
  173.  
  174.  
  175.    The following example shows how a long URL is handled:
  176.  
  177.      Content-type: message/external-body; access-type=URL;
  178.                    URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/
  179.                         8/9/10/11/12/13/14/15/16/17/18/20/21/
  180.                         file.html"
  181.  
  182.      Content-type: text/html
  183.      Content-Transfer-Encoding: binary
  184.  
  185.      THIS IS NOT REALLY THE BODY!
  186.  
  187.    Some URLs may provide access to multiple versions of the same object
  188.    in different formats. The HTTP URL mechanism has this capability, for
  189.    example.  However, applications may not expect to receive something
  190.    whose type doesn't agree with that expressed in the
  191.    message/external-body, and may in fact have already made irrevocable
  192.    choices based on this information.
  193.  
  194.    Due to these considerations, the following restriction is imposed:
  195.    When URLs are used in the context of an access-type only those
  196.    versions of an object whose content-type agrees with that specified
  197.    by the inner message/external-body header can be retrieved and used.
  198.  
  199. 4.  Security Considerations
  200.  
  201.    The security considerations of using URLs in the context of a MIME
  202.    access-type are no different from the concerns that arise from their
  203.    use in other contexts. The specific security considerations
  204.    associated with each type of URL are discussed in the URL's defining
  205.    document.
  206.  
  207.    Note that the Content-MD5 field can be used in conjunction with any
  208.    message/external-body access-type to provide an integrity check. This
  209.    insures that the referenced object really is what the message
  210.    originator intended it to be. This is not a signature service and
  211.    should not be confused with one, but nevetheless is quite useful in
  212.    many situations.
  213.  
  214. 5.  Acknowledgements
  215.  
  216.    The authors are grateful for the feedback and review provided by John
  217.    Beck and John Klensin.
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Freed, et. al.              Standards Track                     [Page 4]
  227.  
  228. RFC 2017                    URL Access-Type                 October 1996
  229.  
  230.  
  231. 6.  References
  232.  
  233.    [RFC-822]
  234.         Crocker, D., "Standard for the Format of ARPA Internet
  235.         Text Messages", STD 11, RFC 822, UDEL, August 1982.
  236.  
  237.    [RFC-1521]
  238.         Borenstein, N. and N. Freed, "MIME (Multipurpose
  239.         Internet Mail Extensions): Mechanisms for Specifying and
  240.         Describing the Format of Internet Message Bodies", RFC
  241.         1521, Bellcore, Innosoft, September, 1993.
  242.  
  243.    [RFC-1590]
  244.         Postel, J., "Media Type Registration Procedure", RFC
  245.         1590, USC/Information Sciences Institute, March 1994.
  246.  
  247.    [RFC-1738]
  248.         Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
  249.         Resource Locators (URL)", December 1994.
  250.  
  251. 7.  Authors' Addresses
  252.  
  253.    Ned Freed
  254.    Innosoft International, Inc.
  255.    1050 East Garvey Avenue South
  256.    West Covina, CA 91790
  257.    USA
  258.  
  259.    Phone: +1 818 919 3600
  260.    Fax: +1 818 919 3614
  261.    EMail: ned@innosoft.com
  262.  
  263.  
  264.    Keith Moore
  265.    Computer Science Dept.
  266.    University of Tennessee
  267.    107 Ayres Hall
  268.    Knoxville, TN 37996-1301
  269.    USA
  270.  
  271.    EMail: moore@cs.utk.edu
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Freed, et. al.              Standards Track                     [Page 5]
  283.  
  284.