[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03                                                   
Network Working Group                                       B. Hoehrmann
Internet-Draft                                          November 5, 2006
Intended status: Standards Track
Expires: May 9, 2007

              The 'javascript' resource identifier scheme

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 9, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This memo defines syntax and semantics of the 'javascript' resource
   identifier scheme, enabling applications to specify script code in
   contexts where resource identifiers are expected.

Hoehrmann                  Expires May 9, 2007                  [Page 1]

Internet-Draft           The 'javascript' scheme           November 2006

1.  Introduction

   The 'javascript' resource identifier scheme allows to encode script
   code in a resource identifier in a way similar to the 'data' scheme,
   but with extended semantics.  This document defines the scheme and
   two operations that describe how existing implementations handle it.

   The first operation, content retrieval, defines which script code a
   given 'javascript' resource identifier represents.  This operation is
   fully defined in this document and some applications, such as
   implementations of the Virtual Reality Modeling Language, might take
   advantage of only this operation.

   The second operation, in-context evaluation, is often implemented by
   web browser applications, and provides a means to run custom script
   code when the resource identifier is dereferenced.  As an example,
   consider a HTML document containing a hyperlink like:

      <a href='javascript:doSomething()'>...</a>

   In typical implementations, when the user activates the hyperlink,
   the web browser will pass control to the doSomething() function, and
   if the function returns something, render the result in place of the
   current document.

   Some semantics of this operation are out of scope of this document.
   As an example, in the example above, if the doSomething() function
   returns a string object, the implementation would lack clues, like an
   Internet media type, how to process it; it could interprete it as
   script, style sheet, HTML document, resource identifier, or any other
   type of resource, as appropriate for the context.

   In order not to limit the applicability of this scheme for certain
   applications, this document just describes this operation in terms of
   an abstract model; it is expected that, where needed, other
   specifications define the semantics in more detail using this model.

2.  Terminology and Conformance

   Resource identifiers, including percent-encoding and requirements for
   IRIs, are defined in STD 66, [RFC3986] and [RFC3987].  Source text
   and the media type application/javascript are defined in [RFC4329],
   the 'data' scheme in [RFC2397], and UTF-8, including the term byte
   order mark, in STD 63, [RFC3629].

   An application that generates resource identifiers conforms to this
   specification if and only if, given a valid application/javascript

Hoehrmann                  Expires May 9, 2007                  [Page 2]

Internet-Draft           The 'javascript' scheme           November 2006

   entity, it generates only 'javascript' resource identifiers that
   conform to this specification.

   An application that dereferences 'javascript' resource identifiers
   conforms to this specification if and only if it implements the
   content retrieval operation as defined in this specification.

   A resource identifier conforms to this specification if and only if
   it is a valid IRI and application of the content retrieval operation
   yields a valid application/javascript entity without generating any
   error.  Use of a byte order mark and literal use of the character "/"
   should be avoided.

   A resource identifier is said to have one or more encoding errors
   when applying the content retrieval operation to it results in one or
   more errors.  Resource identifiers with encoding errors do not
   conform to this specification.

   For resource identifiers with encoding errors the considerations for
   handling encoding errors in application/javascript entities apply.

   The algorithms defined in this document are considered equivalent to
   any and all algorithms that map the same input to the same results.

3.  Operations

   This section defines two operations that can be applied to resource
   identifiers that conform to this specification.  Other operations may
   be defined in other specifications.

3.1.  Content retrieval

   This operation retrieves the source text that is included in the
   scheme-specific part of a given 'javascript' resource identifier.

      1.  Represent the scheme-specific part as sequence of octets in
          the UTF-8 character encoding.

      2.  Replace any percent-encoded octet by its corresponding octet.

      3.  If the sequence starts with the sequence 0xEF 0xBB 0xBF,
          discard this sequence.

      4.  Decode the octet sequence using the UTF-8 character encoding
          and transform the result into source text.

Hoehrmann                  Expires May 9, 2007                  [Page 3]

Internet-Draft           The 'javascript' scheme           November 2006

3.2.  In-context evaluation

   This operation defines a model under which applications may evaluate
   the source text included in a given 'javascript' resource identifier.

      1.  Retrieve the source text using the content retrieval

      2.  Determine a dereference context for further processing.

      3.  Evaluate the source text in this context and memorize the
          result as dereference by-product.

      4.  Process the dereference by-product as appropriate for the
          dereference context.

4.  Interoperability Considerations

   A common error in 'javascript' resource identifiers is incorrect use
   of fragment identifiers as in <javascript:_scrollTo('#example')>, and
   some applications might have to recover from such errors.  Designers
   of protocol elements that accept resource identifiers as defined in
   this document should consider this case and, where compatibility is a
   concern, define a pre-processing step that percent-encodes all '#'
   characters before the content of the protocol element is processed as
   'javascript' resource identifier.

   Authors should be aware that use of 'javascript' resource identifiers
   may have implications for the interoperability, accessibility, or
   usability of their documents and applications.  Applications may vary
   in whether and where they support it, and how they implement the in-
   context evaluation.  As an example, a user may ask a web browser to
   open a 'javascript' hyperlink included in a HTML document in a new
   browser window; in this case the web browser might establish the
   dereference context such that references to variables and functions
   defined elsewhere in the HTML document can no longer be resolved.

5.  Security Considerations

   For applications that rely only on the content retrieval operation as
   defined in this document, the security considerations are equivalent
   to those for 'data' resource identifiers and application/javascript
   as defined in their respective specifications.  In-context evaluation
   may introduce additional security issues, but these depend on the
   dereference context and how the dereference by-product is processed
   which is not defined by this specification; security considerations

Hoehrmann                  Expires May 9, 2007                  [Page 4]

Internet-Draft           The 'javascript' scheme           November 2006

   for this operation are consequently considered out of scope.

6.  Internationalization Considerations

   None beyond those inherent to resource identifiers and entities of
   type application/javascript.

7.  IANA Considerations

   This document registers the 'javascript' scheme as permanent scheme
   in the IANA Uniform Resource Identifier scheme registry per BCP 115.

8.  References

8.1.  Normative References

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC4329]  Hoehrmann, B., "Scripting Media Types", RFC 4329,
              April 2006.

8.2.  Informative References

   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
              August 1998.

Author's Address

   Bjoern Hoehrmann
   Weinheimer Strasse 22
   Mannheim  D-68309

   Email: mailto:bjoern@hoehrmann.de
   URI:   http://bjoern.hoehrmann.de

Hoehrmann                  Expires May 9, 2007                  [Page 5]

Internet-Draft           The 'javascript' scheme           November 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hoehrmann                  Expires May 9, 2007                  [Page 6]