idnits 2.17.1 draft-ietf-mailext-acc-url-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 10362 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1521' is mentioned on line 131, but not defined ** Obsolete undefined reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Unused Reference: 'RFC-822' is defined on line 184, but no explicit reference was found in the text == Unused Reference: 'RFC-1521' is defined on line 188, but no explicit reference was found in the text == Unused Reference: 'RFC-1590' is defined on line 194, but no explicit reference was found in the text == Unused Reference: 'RFC-1738' is defined on line 198, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1590 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ned Freed 2 Internet Draft Keith Moore 3 Allan Cargille, WG Chair 5 Definition of the URL 6 MIME External-Body Access-Type 8 November 1995 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced, or obsoleted 20 by other documents at any time. It is not appropriate to use 21 Internet-Drafts as reference material or to cite them other 22 than as a "working draft" or "work in progress". 24 To learn the current status of any Internet-Draft, please 25 check the 1id-abstracts.txt listing contained in the 26 Internet-Drafts Shadow Directories on ds.internic.net (US East 27 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 28 or munnari.oz.au (Pacific Rim). 30 1. Abstract 32 This memo defines a new access-type for message/external-body 33 MIME parts for Uniform Resource Locators (URLs). URLs provide 34 schemes to access external objects via a growing number of 35 protocols, including HTTP, Gopher, and TELNET. An initial set 36 of URL schemes are defined in RFC 1738. 38 2. Introduction 40 The Multipurpose Internet Message Extensions (MIME) define a 41 facility whereby an object can contain a reference or pointer 42 to some form of data rather than the actual data itself. This 43 facility is embodied in the message/external-body media type 44 defined in RFC 1521. Use of this facility is growing as a 45 means of conserving bandwidth when large objects are sent to 46 large mailing lists. 48 Each message/external-body reference must specify a mechanism 49 whereby the actual data can be retrieved. These mechanisms 50 are called access types, and RFC 1521 defines an initial set 51 of access types: "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE", and 52 "MAIL-SERVER". 54 Uniform Resource Locators, or URLs, also provide a means by 55 which remote data can be retrieved automatically. Each URL 56 string begins with a scheme specification, which in turn 57 specifies how the remaining string is to be used in 58 conjunction with some protocol to retrieve the data. However, 59 URL schemes exist for protocol operations that have no 60 corresponding MIME message/external-body access type. 61 Registering an access type for URLs therefore provides 62 message/external-body with access to the retrieval mechanisms 63 of URLs that are not currently available as access types. It 64 also provides access to any future mechanisms for which URL 65 schemes are developed. 67 This access type is only intended for use with URLs that 68 actually retreive something. Other URL mechansisms, e.g. 69 mailto, may not be used in this context. 71 3. Definition of the URL Access-Type 73 The URL access-type is defined as follows: 75 (1) The name of the access-type is URL. 77 (2) A new message/external-body content-type parameter is 78 used to actually store the URL string. The name of the 79 parameter is also "URL", and this parameter is 80 mandatory for this access-type. The syntax and use of 81 this parameter is specified in the next section. 83 (3) The phantom body area of the message/external-body is 84 not used and should be left blank. 86 For example, the following message illustrates how the URL 87 access-type is used: 89 Content-type: message/external-body; access-type=URL; 90 URL="http://www.foo.com/file" 92 Content-type: text/html 93 Content-Transfer-Encoding: binary 95 THIS IS NOT REALLY THE BODY! 97 3.1. Syntax and Use of the URL parameter 99 Using the ANBF notations and definitions of RFC 822 and RFC 100 1521, the syntax of the URL parameter Is as follows: 102 URL-parameter := <"> URL-word *(*LWSP-char URL-word) <"> 104 URL-word := token 105 ; Must not exceed 40 characters in length 107 The syntax of an actual URL string is given in RFC 1738. URL 108 strings can be of any length and can contain arbitrary 109 character content. This presents problems when URLs are 110 embedded in MIME body part headers that are wrapped according 111 to RFC 822 rules. For this reason they are transformed into a 112 URL-parameter for inclusion in a message/external-body 113 content-type specification as follows: 115 (1) A check is made to make sure that all occurrences of 116 SPACE, CTLs, double quotes, backslashes, and 8-bit 117 characters in the URL string are already encoded using 118 the URL encoding scheme specified in RFC 1738. Any 119 unencoded occurrences of these characters must be 120 encoded. Note that the result of this operation is 121 nothing more than a different representation of the 122 original URL. 124 (2) The resulting URL string is broken up into substrings 125 of 40 characters or less. 127 (3) Each substring is placed in a URL-parameter string as a 128 URL-word, separated by one or more spaces. Note that 129 the enclosing quotes are always required since all URLs 130 contain one or more colons, and colons are tspecial 131 characters [RFC 1521]. 133 Extraction of the URL string from the URL-parameter is even 134 simpler: The enclosing quotes and any linear whitespace are 135 removed and the remaining material is the URL string. 137 The follow example shows how a long URL is handled: 139 Content-type: message/external-body; access-type=URL; 140 URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/ 141 8/9/10/11/12/13/14/15/16/17/18/20/21/ 142 file.html" 144 Content-type: text/html 145 Content-Transfer-Encoding: binary 147 THIS IS NOT REALLY THE BODY! 149 Some URLs may provide access to multiple versions of the same 150 object in different formats. The HTTP URL mechanism has this 151 capability, for example. However, applications may not expect 152 to receive something whose type doesn't agree with that 153 expressed in the message/external-body, and may in fact have 154 already made irrevocable choices based on this information. 156 Due to these considerations, the following restriction is 157 imposed: When URLs are used in the context of an access-type 158 only those versions of an object whose content-type agrees 159 with that specified by the inner message/external-body header 160 can be retrieved and used. 162 4. Security Considerations 164 The security considerations of using URLs in the context of a 165 MIME access-type are no different from the concerns that arise 166 from their use in other contexts. The specific security 167 considerations associated with each type of URL are discussed 168 in the URL's defining document. 170 Note that the Content-MD5 field can be used in conjunction 171 with any message/external-body access-type to provide an 172 integrity check. This insures that the referenced object 173 really is what the message originator intended it to be. This 174 is not a signature service and should not be confused with 175 one, but nevetheless is quite useful in many situations. 177 5. Acknowledgements 179 The authors are grateful for the feedback and review provided 180 by John Beck and John Klensin. 182 6. References 184 [RFC-822] 185 Crocker, D., "Standard for the Format of ARPA Internet 186 Text Messages", STD 11, RFC 822, UDEL, August 1982. 188 [RFC-1521] 189 Borenstein, N. and Freed, N., "MIME (Multipurpose 190 Internet Mail Extensions): Mechanisms for Specifying and 191 Describing the Format of Internet Message Bodies", RFC 192 1521, Bellcore, Innosoft, September, 1993. 194 [RFC-1590] 195 Postel, J., "Media Type Registration Procedure", RFC 196 1590, USC/Information Sciences Institute, March 1994. 198 [RFC-1738] 199 Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 200 Resource Locators (URL)", December 1994. 202 7. Author Addresses 204 Ned Freed 205 Innosoft International, Inc. 206 1050 East Garvey Avenue South 207 West Covina, CA 91790 208 USA 209 tel: +1 818 919 3600 fax: +1 818 919 3614 210 email: ned@innosoft.com 212 Keith Moore 213 Computer Science Dept. 214 University of Tennessee 215 107 Ayres Hall 216 Knoxville, TN 37996-1301 217 USA 218 email: moore@cs.utk.edu