Definition of the URL MIME External-Body Access-Type
RFC 2017
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
Show full document text