URL External-Body Type: Definition of the URL MIME External-Body Access-Type
How a MIME mail message can point at its content with a URL instead of carrying the data.
Freed, N., Moore, K., and A. Cargille, "Definition of the URL MIME External-Body Access-Type", RFC 2017, DOI 10.17487/RFC2017, October 1996, <https://www.rfc-editor.org/info/rfc2017>.
@misc{rfc2017,
series = {Request for Comments},
number = 2017,
howpublished = {RFC 2017},
publisher = {RFC Editor},
doi = {10.17487/RFC2017},
url = {https://www.rfc-editor.org/info/rfc2017},
author = {N. Freed and K. Moore and A. Cargille},
title = {{Definition of the URL MIME External-Body Access-Type}},
pagetotal = 5,
year = 1996,
month = oct,
} RFC text
Contents
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".
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!
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
nothing more than a different representation of the
original URL.
(2) The resulting URL string is broken up into substrings
of 40 characters or less.
(3) Each substring is placed in a URL-parameter string as a
URL-word, separated by one or more spaces. Note that
the enclosing quotes are always required since all URLs
contain one or more colons, and colons are tspecial
characters [RFC 1521].
Extraction of the URL string from the URL-parameter is even simpler:
The enclosing quotes and any linear whitespace are removed and the
remaining material is the URL string.
The following example shows how a long URL is handled:
Content-type: message/external-body; access-type=URL;
URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/
8/9/10/11/12/13/14/15/16/17/18/20/21/
file.html"
Content-type: text/html
Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!
Some URLs may provide access to multiple versions of the same object
in different formats. The HTTP URL mechanism has this capability, for
example. However, applications may not expect to receive something
whose type doesn't agree with that expressed in the
message/external-body, and may in fact have already made irrevocable
choices based on this information.
Due to these considerations, the following restriction is imposed:
When URLs are used in the context of an access-type only those
versions of an object whose content-type agrees with that specified
by the inner message/external-body header can be retrieved and used.
4. Security Considerations
The security considerations of using URLs in the context of a MIME
access-type are no different from the concerns that arise from their
use in other contexts. The specific security considerations
associated with each type of URL are discussed in the URL's defining
document.
Note that the Content-MD5 field can be used in conjunction with any
message/external-body access-type to provide an integrity check. This
insures that the referenced object really is what the message
originator intended it to be. This is not a signature service and
should not be confused with one, but nevetheless is quite useful in
many situations.
5. Acknowledgements
The authors are grateful for the feedback and review provided by John
Beck and John Klensin.
6. References
[RFC-822]
Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[RFC-1521]
Borenstein, N. and N. Freed, "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1521, Bellcore, Innosoft, September, 1993.
[RFC-1590]
Postel, J., "Media Type Registration Procedure", RFC
1590, USC/Information Sciences Institute, March 1994.
[RFC-1738]
Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", December 1994.
7. Authors' Addresses
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.com
Keith Moore
Computer Science Dept.
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA
EMail: moore@cs.utk.edu
AI ELI5
On this page
§1Why a URL Access Type
MIME's message/external-body media type lets a message hold a pointer to data rather than the data itself. This saves bandwidth when large objects go to large mailing lists. Each pointer must say how the data can be fetched; these methods are called access types. RFC 1521 defined FTP, ANON-FTP, TFTP, LOCAL-FILE and MAIL-SERVER.
URLs already describe how to retrieve remote data, and some URL schemes have no matching access type. Registering one access type for URLs gives message/external-body access to all of them, including future schemes. It is only meant for URLs that actually retrieve something, so mailto may not be used.
The old ways of saying where to find something were a short list. A web-style address works for almost anything, so now it can be used too.
§2The URL Access Type and Parameter
The access type is named URL. A content-type parameter, also named URL, holds the address and is mandatory. The phantom body area of the part is not used and should be left blank.
A URL can be any length and contain arbitrary characters, which clashes with header wrapping rules. So the string is prepared in three steps: any space, control character, double quote, backslash or 8-bit character is URL-encoded as in RFC 1738; the result is cut into pieces of 40 characters or less; and the pieces are placed as words separated by spaces inside quotes. The quotes are always required because every URL contains a colon. To read it back, remove the quotes and whitespace.
A very long address is chopped into short pieces so mail systems do not mangle it, and glued back together by the reader.
Content-type: message/external-body; access-type=URL;
URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/
8/9/10/11/12/13/14/15/16/17/18/20/21/
file.html"
Content-type: text/html
Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!§3Matching the Declared Type
Some URLs, such as HTTP ones, can offer several versions of an object in different formats. An application may already have made irrevocable choices based on the content type in the message/external-body header.
So the RFC restricts retrieval: only versions whose content-type agrees with the one in the inner message/external-body header may be retrieved and used.
If the note says you are getting a photo, you may only accept a photo, not a surprise movie.
§4Security Considerations
Using URLs as an access type raises no new concerns beyond using them elsewhere; each URL type's own defining document discusses its issues.
The Content-MD5 field can be used with any message/external-body access type as an integrity check, confirming the referenced object is what the sender intended. The RFC stresses that this is not a signature service.
You can attach a fingerprint of the file so you know you fetched the right one, though a fingerprint does not prove who sent it.