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