idnits 2.17.1 draft-masinter-url-data-02.txt: 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-04-25) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 172 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1522], [RFC-URL-SYNTAX], [RFC1866]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 13, 1996) is 10025 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-URL-SYNTAX' is mentioned on line 66, but not defined == Missing Reference: 'RFC 1522' is mentioned on line 69, but not defined ** Obsolete undefined reference: RFC 1522 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Unused Reference: 'RFCSYNTAX' is defined on line 153, but no explicit reference was found in the text == Unused Reference: 'RFC1522' is defined on line 159, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCSYNTAX' ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 1522 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Larry Masinter 3 draft-masinter-url-data-02.txt Xerox Corporation 4 Expires in 6 months November 13, 1996 6 The "data" URL scheme 8 Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 A new URL scheme, "data", is defined. It allows inclusion of small 30 data items as "immediate" data, as if it had been included externally. 32 Description 34 Some applications that use URLs also have a need to embed (small) 35 media type data directly inline. This document defines a new URL 36 scheme that would work like 'immediate addressing'. The URLs are of 37 the form: 39 data:[][;base64], 41 The is an Internet media type specification (with optional 42 parameters, etc.) The appearance of ";base64" means that the data is 43 encoded as base64. Without ";base64", the data (as a sequence of 44 octets) is represented using ASCII encoding for octets inside the 45 range of safe URL characters and using the standard %xx hex encoding 46 of URLs for octets outside that range. If is omitted, it 47 defaults to text/plain;charset=US-ASCII. As a shorthand, "text/plain" 48 can be omitted but the charset parameter supplied. 50 The "data" URL scheme is intended for short values. Many applications 51 that use URLs may impose a length limit; for example, URLs embedded 52 within anchors in HTML have a length limit determined by the SGML 53 declaration for HTML[RFC1866]. 55 The "data" URL scheme has no relative URL forms. 57 Syntax 59 dataurl := "data:" [ mediatype [ ";base64" ] "," data 60 mediatype := type "/" subtype *( ";" parameter ) 61 data := *urlchar 62 parameter := attribute "=" value 64 where "urlchar" is imported from [RFC-URL-SYNTAX], and "type", 65 "subtype", "attribute" and "value" are the corresponding tokens from 66 [RFC 1522], represented using URL escaped encoding of [RFC-URL-SYNTAX] 67 as necessary. 69 Attribute values in [RFC 1522] are allowed to be either represented as 70 tokens or as quoted strings. However, within a "data" URL, the 71 "quoted-string" representation would be awkward, since the quote mark 72 is itself not a valid urlchar. For this reason, parameter values 73 should use the URL Escaped encoding instead of quoted string if the 74 parameter values contain any "tspecial". 76 The ";base64" extension is distinguishable from a content-type 77 parameter by the fact that it doesn't have a following "=" sign. 79 Examples 81 A data URL might be used for arbitrary types of data. The URL 83 data:,A%20brief%20note 85 encodes the text/plain string "A brief note", which might be useful in 86 a footnote link. 88 The HTML fragment: 90 Larry 100 could be used for a small inline image in a HTML document. (The 101 embedded image is probably near the limit of utility. For anything 102 else larger, data URLs are likely to be inappropriate.) 104 A data URL scheme's media type specification can include other 105 parameters; for example, one might specify a charset parameter. 107 data:text/plain;charset=iso-8859-7;%be%fg%be 109 can be used for a short sequence of greek characters. 111 Some applications may use the "data" URL scheme in order to provide 112 setup parameters for other kinds of networking applications. For 113 example, one might create a media type 114 application/vnd.xxx-query 116 whose content consists of a query string and a database identifier for 117 the "xxx" vendor's databases. A URL of the form: 119 data:application/vnd.xxx-query,select_vcount,fcol_from_fieldtable/local 121 could then be used in a local application to launch the "helper" for 122 application/vnd.xxx-query and give it the immediate data included. 124 History 126 This idea was originally proposed August 1995. Some versions of the 127 data URL scheme have been used in the definition of VRML, and a 128 version has appeared as part of a proposal for embedded data in HTML. 129 Various changes have been made, based on requests, to elide the media 130 type, pack the indication of the base64 encoding more tightly, and 131 eliminate "quoted printable" as an encoding since it would not easily 132 yield valid URLs without additional %xx encoding, which itself is 133 sufficient. The "data" URL scheme is in use in VRML, new applications of 134 HTML, and various commercial products. 136 Security 138 Interpretation of the data within a "data" URL has the same 139 security considerations as any implementation of the given media type. 140 An application should not interpret the contents of a data URL which 141 is marked with a media type that has been disallowed for processing 142 by the application's configuration. 144 Sites which use firewall proxies to disallow the retrieval of certain 145 media types (such as application script languages or types with known 146 security problems) will find it difficult to screen against the inclusion 147 of such types using the "data" URL scheme. However, they should be 148 aware of the threat and take whatever precautions are considered 149 necessary within their domain. 151 References 153 [RFCSYNTAX] RFC xxxx. Uniform Resource Locators (URL). R. Fielding, 154 L. Masinter, T. Berners-Lee, December 1996. 156 [RFC1866] RFC 1866: Hypertext Markup Language - 2.0. 157 T. Berners-Lee & D. Connolly. November 1995. 159 [RFC1522] RFC 1522: MIME (Multipurpose Internet Mail Extensions) 160 Part One: Mechanisms for Specifying and Describing 161 the Format of Internet Message Bodies 163 Author contact information: 165 Larry Masinter 166 Xerox Palo Alto Research Center 167 3333 Coyote Hill Road 168 Palo Alto, CA 94304 169 masinter@parc.xerox.com