idnits 2.17.1 draft-hoehrmann-javascript-scheme-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (September 15, 2010) is 4971 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4329 (Obsoleted by RFC 9239) -- Obsolete informational reference (is this intentional?): RFC 4395 (ref. 'BCP0115') (Obsoleted by RFC 7595) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Hoehrmann 3 Internet-Draft September 15, 2010 4 Intended status: Informational 5 Expires: March 19, 2011 7 The 'javascript' resource identifier scheme 8 draft-hoehrmann-javascript-scheme-02 10 Abstract 12 This memo defines the 'javascript' resource identifier scheme. Using 13 this scheme, executable script code can be specified in contexts that 14 support resource identifiers. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 19, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 1. Introduction 50 The 'javascript' resource identifier scheme allows to encode script 51 code in a resource identifier in a way similar to the 'data' scheme, 52 but with extended semantics. This document defines the scheme and 53 two operations that describe how existing implementations handle it. 55 The first operation, content retrieval, defines which script code a 56 given 'javascript' resource identifier represents. This operation is 57 fully defined in this document and some applications might take 58 advantage of only this operation. 60 The second operation, in-context evaluation, is often implemented by 61 web browser applications, and provides a means to run custom script 62 code when the resource identifier is dereferenced. As an example, 63 consider a HTML document containing a hyperlink like: 65 ... 67 In typical implementations, when the user activates the hyperlink, 68 the web browser will pass control to the doSomething() function, and 69 render its result, if any, in place of the current document. 71 Some semantics of this operation are out of scope of this document. 72 For instance, in the example above, if the doSomething() function 73 returns a string object, the implementation would lack clues, like an 74 Internet media type, how to process it; it could treat it as a 75 script, style sheet, HTML document, resource identifier, or other 76 type of resource, as appropriate for the context. 78 In order not to limit the applicability of this scheme for certain 79 applications, this document just describes this operation in terms of 80 an abstract model; it is expected that, where needed, other 81 specifications define the semantics in more detail using this model. 83 2. Terminology and Conformance 85 Resource identifiers, including percent-encoding and requirements for 86 IRIs, are defined in STD 66, [RFC3986], and [RFC3987]. Source text 87 and the media type application/javascript are defined in [RFC4329], 88 the 'data' scheme in [RFC2397], and UTF-8, including the term byte 89 order mark, in STD 63, [RFC3629]. 91 An application that generates resource identifiers conforms to this 92 specification if and only if, given a valid application/javascript 93 entity, it generates only 'javascript' resource identifiers that 94 conform to this specification. 96 An application that dereferences 'javascript' resource identifiers 97 conforms to this specification if and only if it implements the 98 content retrieval operation as defined in this specification. 100 A resource identifier conforms to this specification if and only if 101 it is a valid IRI and application of the content retrieval operation 102 yields a valid application/javascript entity without generating any 103 error. Use of a byte order mark is discouraged; percent-encoding of 104 "/" (U+002F SOLIDUS) characters is encouraged. 106 A resource identifier is said to have encoding errors when applying 107 the content retrieval operation results in one or more errors. 108 Resource identifiers with encoding errors do not conform to this 109 specification. The considerations for handling encoding errors in 110 application/javascript entities apply. 112 3. Operations 114 This section defines two operations that can be applied to resource 115 identifiers that conform to this specification. Other operations may 116 be defined in other specifications. 118 3.1. Content retrieval 120 This operation retrieves the source text that is included in the 121 scheme-specific part of a given 'javascript' resource identifier. 123 1. Represent the scheme-specific part as sequence of octets in 124 the UTF-8 character encoding. 126 2. Replace any percent-encoded octet by its corresponding octet. 128 3. If the sequence starts with the sequence 0xEF 0xBB 0xBF (the 129 UTF-8 signature, or byte order mark), discard this sequence. 131 4. Decode the octet sequence using the UTF-8 character encoding 132 and transform the result into source text. 134 3.2. In-context evaluation 136 This operation defines a model under which applications may evaluate 137 the source text included in a given 'javascript' resource identifier. 139 1. Retrieve the source text using the content retrieval 140 operation. 142 2. Determine the dereference context for further processing. 144 3. Evaluate the source text in this context and memorize the 145 result as dereference by-product. 147 4. Process the dereference by-product as appropriate for the 148 dereference context. 150 4. Interoperability Considerations 152 The character "#" is used to separate a fragment identifier from the 153 scheme-specific part of a resource identifier and consequently needs 154 to be percent-encoded when used as data in the scheme-specific part. 155 In certain protocol elements some existing implementations treat the 156 character as data regardless of whether it is percent-encoded. 158 Protocol element designers who wish to sanction this behavior should 159 specify a pre-processing step that applies percent-encoding to this 160 character for the relevant protocol elements. Such a step precludes 161 use of fragment identifiers for 'javascript' resource identifiers. 163 The in-context evaluation operation is not fully defined in this memo 164 and inherently context-dependant; it follows that implementations can 165 differ in how they support this operation in a given context and some 166 resource identifiers may only function in specific contexts. 168 For instance, a 'javascript' resource identifier might be embedded in 169 a HTML document and depened on properties of the document. A typical 170 consequence is that hyperlinks using this scheme can be activated in 171 a specific document, but trying to open them in a new browser window 172 or a different document fails. 174 Specifications for protocol elements that permit resource identifiers 175 usually do not include special provisions for the 'javascript' scheme 176 and implementations consequently vary in where and how they support 177 them. In the interest of interoperability it is therefore advisable 178 to use the scheme only where no viable alternatives exist. 180 The definition of the scheme does not permit specification of out of 181 band information like which particular incarnation of the underlying 182 scripting language is used by a resource identifier. In consequence 183 version-specific language features may perform unreliably. 185 5. Security Considerations 187 A 'javascript' resource identifier contains a application/javascript 188 entity and the security considerations for such entities apply. The 189 content retrieval operation has no considerations beyond that; other 190 specifications may define operations in addition to the ones defined 191 in this document; security considerations for them are out of scope. 193 The in-context evalutation operation necessitates extreme caution in 194 deciding where resource identifiers using this scheme are recognized 195 and permitted and what facilities are made available to script code, 196 like access to private information and operations with side effects. 198 6. Internationalization Considerations 200 None beyond those inherent to resource identifiers and entities of 201 type application/javascript. Characters are encoded using UTF-8. 203 7. IANA Considerations 205 This document registers the 'javascript' scheme as permanent scheme 206 in the Uniform Resource Identifier scheme registry as per [BCP0115]. 208 8. References 210 8.1. Normative References 212 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 213 10646", STD 63, RFC 3629, November 2003. 215 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 216 Resource Identifier (URI): Generic Syntax", STD 66, 217 RFC 3986, January 2005. 219 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 220 Identifiers (IRIs)", RFC 3987, January 2005. 222 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 223 April 2006. 225 8.2. Informative References 227 [BCP0115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 228 Registration Procedures for New URI Schemes", BCP 115, 229 RFC 4395, February 2006. 231 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 232 August 1998. 234 Author's Address 236 Bjoern Hoehrmann 237 Mittelstrasse 50 238 39114 Magdeburg 239 Germany 241 Email: mailto:bjoern@hoehrmann.de 242 URI: http://bjoern.hoehrmann.de 244 Note: Please write "Bjoern Hoehrmann" with o-umlaut (U+00F6) wherever 245 possible, e.g., as "Björn Höhrmann" in HTML and XML.