idnits 2.17.1
draft-hoehrmann-javascript-scheme-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 242.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 253.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 260.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 266.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
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 RFC 3978 Section 5.4 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 (November 5, 2006) is 6382 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)
** Obsolete normative reference: RFC 4329 (Obsoleted by RFC 9239)
Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group B. Hoehrmann
3 Internet-Draft November 5, 2006
4 Intended status: Standards Track
5 Expires: May 9, 2007
7 The 'javascript' resource identifier scheme
8 draft-hoehrmann-javascript-scheme-00
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on May 9, 2007.
35 Copyright Notice
37 Copyright (C) The Internet Society (2006).
39 Abstract
41 This memo defines syntax and semantics of the 'javascript' resource
42 identifier scheme, enabling applications to specify script code in
43 contexts where resource identifiers are expected.
45 1. Introduction
47 The 'javascript' resource identifier scheme allows to encode script
48 code in a resource identifier in a way similar to the 'data' scheme,
49 but with extended semantics. This document defines the scheme and
50 two operations that describe how existing implementations handle it.
52 The first operation, content retrieval, defines which script code a
53 given 'javascript' resource identifier represents. This operation is
54 fully defined in this document and some applications, such as
55 implementations of the Virtual Reality Modeling Language, might take
56 advantage of only this operation.
58 The second operation, in-context evaluation, is often implemented by
59 web browser applications, and provides a means to run custom script
60 code when the resource identifier is dereferenced. As an example,
61 consider a HTML document containing a hyperlink like:
63 ...
65 In typical implementations, when the user activates the hyperlink,
66 the web browser will pass control to the doSomething() function, and
67 if the function returns something, render the result in place of the
68 current document.
70 Some semantics of this operation are out of scope of this document.
71 As an example, in the example above, if the doSomething() function
72 returns a string object, the implementation would lack clues, like an
73 Internet media type, how to process it; it could interprete it as
74 script, style sheet, HTML document, resource identifier, or any other
75 type of resource, as appropriate for the context.
77 In order not to limit the applicability of this scheme for certain
78 applications, this document just describes this operation in terms of
79 an abstract model; it is expected that, where needed, other
80 specifications define the semantics in more detail using this model.
82 2. Terminology and Conformance
84 Resource identifiers, including percent-encoding and requirements for
85 IRIs, are defined in STD 66, [RFC3986] and [RFC3987]. Source text
86 and the media type application/javascript are defined in [RFC4329],
87 the 'data' scheme in [RFC2397], and UTF-8, including the term byte
88 order mark, in STD 63, [RFC3629].
90 An application that generates resource identifiers conforms to this
91 specification if and only if, given a valid application/javascript
92 entity, it generates only 'javascript' resource identifiers that
93 conform to this specification.
95 An application that dereferences 'javascript' resource identifiers
96 conforms to this specification if and only if it implements the
97 content retrieval operation as defined in this specification.
99 A resource identifier conforms to this specification if and only if
100 it is a valid IRI and application of the content retrieval operation
101 yields a valid application/javascript entity without generating any
102 error. Use of a byte order mark and literal use of the character "/"
103 should be avoided.
105 A resource identifier is said to have one or more encoding errors
106 when applying the content retrieval operation to it results in one or
107 more errors. Resource identifiers with encoding errors do not
108 conform to this specification.
110 For resource identifiers with encoding errors the considerations for
111 handling encoding errors in application/javascript entities apply.
113 The algorithms defined in this document are considered equivalent to
114 any and all algorithms that map the same input to the same results.
116 3. Operations
118 This section defines two operations that can be applied to resource
119 identifiers that conform to this specification. Other operations may
120 be defined in other specifications.
122 3.1. Content retrieval
124 This operation retrieves the source text that is included in the
125 scheme-specific part of a given 'javascript' resource identifier.
127 1. Represent the scheme-specific part as sequence of octets in
128 the UTF-8 character encoding.
130 2. Replace any percent-encoded octet by its corresponding octet.
132 3. If the sequence starts with the sequence 0xEF 0xBB 0xBF,
133 discard this sequence.
135 4. Decode the octet sequence using the UTF-8 character encoding
136 and transform the result into source text.
138 3.2. In-context evaluation
140 This operation defines a model under which applications may evaluate
141 the source text included in a given 'javascript' resource identifier.
143 1. Retrieve the source text using the content retrieval
144 operation.
146 2. Determine a dereference context for further processing.
148 3. Evaluate the source text in this context and memorize the
149 result as dereference by-product.
151 4. Process the dereference by-product as appropriate for the
152 dereference context.
154 4. Interoperability Considerations
156 A common error in 'javascript' resource identifiers is incorrect use
157 of fragment identifiers as in , and
158 some applications might have to recover from such errors. Designers
159 of protocol elements that accept resource identifiers as defined in
160 this document should consider this case and, where compatibility is a
161 concern, define a pre-processing step that percent-encodes all '#'
162 characters before the content of the protocol element is processed as
163 'javascript' resource identifier.
165 Authors should be aware that use of 'javascript' resource identifiers
166 may have implications for the interoperability, accessibility, or
167 usability of their documents and applications. Applications may vary
168 in whether and where they support it, and how they implement the in-
169 context evaluation. As an example, a user may ask a web browser to
170 open a 'javascript' hyperlink included in a HTML document in a new
171 browser window; in this case the web browser might establish the
172 dereference context such that references to variables and functions
173 defined elsewhere in the HTML document can no longer be resolved.
175 5. Security Considerations
177 For applications that rely only on the content retrieval operation as
178 defined in this document, the security considerations are equivalent
179 to those for 'data' resource identifiers and application/javascript
180 as defined in their respective specifications. In-context evaluation
181 may introduce additional security issues, but these depend on the
182 dereference context and how the dereference by-product is processed
183 which is not defined by this specification; security considerations
184 for this operation are consequently considered out of scope.
186 6. Internationalization Considerations
188 None beyond those inherent to resource identifiers and entities of
189 type application/javascript.
191 7. IANA Considerations
193 This document registers the 'javascript' scheme as permanent scheme
194 in the IANA Uniform Resource Identifier scheme registry per BCP 115.
196 8. References
198 8.1. Normative References
200 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
201 10646", STD 63, RFC 3629, November 2003.
203 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
204 Resource Identifier (URI): Generic Syntax", STD 66,
205 RFC 3986, January 2005.
207 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
208 Identifiers (IRIs)", RFC 3987, January 2005.
210 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329,
211 April 2006.
213 8.2. Informative References
215 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
216 August 1998.
218 Author's Address
220 Bjoern Hoehrmann
221 Weinheimer Strasse 22
222 Mannheim D-68309
223 Germany
225 Email: mailto:bjoern@hoehrmann.de
226 URI: http://bjoern.hoehrmann.de
228 Full Copyright Statement
230 Copyright (C) The Internet Society (2006).
232 This document is subject to the rights, licenses and restrictions
233 contained in BCP 78, and except as set forth therein, the authors
234 retain all their rights.
236 This document and the information contained herein are provided on an
237 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
238 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
239 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
240 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
241 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
242 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
244 Intellectual Property
246 The IETF takes no position regarding the validity or scope of any
247 Intellectual Property Rights or other rights that might be claimed to
248 pertain to the implementation or use of the technology described in
249 this document or the extent to which any license under such rights
250 might or might not be available; nor does it represent that it has
251 made any independent effort to identify any such rights. Information
252 on the procedures with respect to rights in RFC documents can be
253 found in BCP 78 and BCP 79.
255 Copies of IPR disclosures made to the IETF Secretariat and any
256 assurances of licenses to be made available, or the result of an
257 attempt made to obtain a general license or permission for the use of
258 such proprietary rights by implementers or users of this
259 specification can be obtained from the IETF on-line IPR repository at
260 http://www.ietf.org/ipr.
262 The IETF invites any interested party to bring to its attention any
263 copyrights, patents or patent applications, or other proprietary
264 rights that may cover technology that may be required to implement
265 this standard. Please address the information to the IETF at
266 ietf-ipr@ietf.org.
268 Acknowledgment
270 Funding for the RFC Editor function is provided by the IETF
271 Administrative Support Activity (IASA).