Definition of the URL MIME External-Body Access-Type
RFC 2017

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                         N. Freed
Request for Comments: 2017                      Innosoft International
Category: Standards Track                                     K. Moore
                                               University of Tennessee
                                                 A. Cargille, WG Chair
                                                          October 1996

                         Definition of the URL
                     MIME External-Body Access-Type

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

1.  Abstract

   This memo defines a new access-type for message/external-body MIME
   parts for Uniform Resource Locators (URLs).  URLs provide schemes to
   access external objects via a growing number of protocols, including
   HTTP, Gopher, and TELNET.  An initial set of URL schemes are defined
   in RFC 1738.

2.  Introduction

   The Multipurpose Internet Message Extensions (MIME) define a facility
   whereby an object can contain a reference or pointer to some form of
   data rather than the actual data itself. This facility is embodied in
   the message/external-body media type defined in RFC 1521.  Use of
   this facility is growing as a means of conserving bandwidth when
   large objects are sent to large mailing lists.

   Each message/external-body reference must specify a mechanism whereby
   the actual data can be retrieved.  These mechanisms are called access
   types, and RFC 1521 defines an initial set of access types: "FTP",
   "ANON-FTP", "TFTP", "LOCAL-FILE", and "MAIL-SERVER".

Freed, et. al.              Standards Track                     [Page 1]
RFC 2017                    URL Access-Type                 October 1996

   Uniform Resource Locators, or URLs, also provide a means by which
   remote data can be retrieved automatically.  Each URL string begins
   with a scheme specification, which in turn specifies how the
   remaining string is to be used in conjunction with some protocol to
   retrieve the data. However, URL schemes exist for protocol operations
   that have no corresponding MIME message/external-body access type.
   Registering an access type for URLs therefore provides
   message/external-body with access to the retrieval mechanisms of URLs
   that are not currently available as access types.  It also provides
   access to any future mechanisms for which URL schemes are developed.

   This access type is only intended for use with URLs that actually
   retreive something. Other URL mechansisms, e.g.  mailto, may not be
   used in this context.

3.  Definition of the URL Access-Type

   The URL access-type is defined as follows:

    (1)   The name of the access-type is URL.

    (2)   A new message/external-body content-type parameter is
          used to actually store the URL string. The name of the
          parameter is also "URL", and this parameter is
          mandatory for this access-type. The syntax and use of
          this parameter is specified in the next section.

    (3)   The phantom body area of the message/external-body is
          not used and should be left blank.

   For example, the following message illustrates how the URL access-
   type is used:

    Content-type: message/external-body; access-type=URL;
                  URL="http://www.foo.com/file"

    Content-type: text/html
    Content-Transfer-Encoding: binary

    THIS IS NOT REALLY THE BODY!

Freed, et. al.              Standards Track                     [Page 2]
RFC 2017                    URL Access-Type                 October 1996

3.1.  Syntax and Use of the URL parameter

   Using the ANBF notations and definitions of RFC 822 and RFC 1521, the
   syntax of the URL parameter Is as follows:

     URL-parameter := <"> URL-word *(*LWSP-char URL-word) <">

     URL-word := token
                 ; Must not exceed 40 characters in length

   The syntax of an actual URL string is given in RFC 1738.  URL strings
   can be of any length and can contain arbitrary character content.
   This presents problems when URLs are embedded in MIME body part
   headers that are wrapped according to RFC 822 rules. For this reason
   they are transformed into a URL-parameter for inclusion in a
   message/external-body content-type specification as follows:

    (1)   A check is made to make sure that all occurrences of
          SPACE, CTLs, double quotes, backslashes, and 8-bit
          characters in the URL string are already encoded using
          the URL encoding scheme specified in RFC 1738. Any
          unencoded occurrences of these characters must be
          encoded.  Note that the result of this operation is