Definition of the URL MIME External-Body Access-Type

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
2. Introduction
3. Definition of the URL Access-Type
3.1. Syntax and Use of the URL parameter
4. Security Considerations
5. Acknowledgements
6. References (BOILERPLATE)
7. Authors' Addresses (BOILERPLATE)
§ Authors' Addresses
§ Intellectual Property and Copyright Statements

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

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:

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 (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "References."

7. Authors' Addresses (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Author's Address."

Authors' Addresses

Full Copyright Statement

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

	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