<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc strict="no"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>

<rfc category="info" ipr="trust200902" docName="draft-tschofenig-post-standardization-02.txt">

  <front>
  <title abbrev="Web Applications: Trends and Implications">Trends in Web Applications and the Implications on Standardization</title>   
    
        <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>

   <author initials="B." surname="Aboba" fullname="Bernard Aboba">
      <organization>Microsoft Corporation</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>
          <country>US</country>
        </postal>
        <email>bernarda@microsoft.com</email>
      </address>
    </author>

        <author initials="J." surname="Peterson" fullname="Jon Peterson">
            <organization abbrev="NeuStar, Inc.">NeuStar, Inc.</organization>
            <address>
                <postal>
                    <street>1800 Sutter St Suite 570</street>
                    <city>Concord</city>
                    <region>CA</region>
                    <code>94520</code>
                    <country>US</country>
                </postal>
                <email>jon.peterson@neustar.biz</email>
            </address>
        </author>

	       <author initials="D." surname="McPherson" fullname="Danny McPherson">
            <organization>Verisign</organization>
            <address>
                <postal>
                    <street></street>
                    <city></city>
                    <region></region>
                    <code></code>
                    <country>US</country>
                </postal>
                <email>danny@tcb.net</email>
            </address>
        </author>
    <date year="2012"/>
    <keyword>Internet-Draft</keyword>
    <keyword>Web Applications</keyword>
    <keyword>Post Standardization</keyword>
    <abstract>
    <t>Advancements in the design of web browsers have introduced fundamental
changes to the architecture of application protocols. The widespread
availability and growing sophistication of JavaScript interpreters in
browsers enables web servers to push to browsers all of the
application logic required to implement a client-server
protocol. Consequently, many client-server applications that once
required an installed client on a host computer now can rely simply on
a modern browser to act as a client for the purposes of a particular
application. For example, where once email clients required a custom
application to access an inbox, increasingly a web browser can serve
this purpose as well as the purpose-built applications of the
past. Similarly, HTTP with the assistance of JavaScript can subsume
the functions performed by the protocols like POP3 and IMAP. The need
for Internet standards beyond HTTP to implement an email inbox
application consequently diminishes - why author standards and worry
about interoperability of clients and servers when the server can
simply push to the client all the code it needs to be interoperable?
</t>
<t>
Many client-server applications on the Internet could potential
migrate to this code distribution methodology. 
</t>

<t>[Note: A separate mailing list has been created for discussions related to this document 
and it can be found here: https://www.ietf.org/mailman/listinfo/webapps ]</t>
</abstract>

  </front>
  <middle>

    <!-- ====================================================================== -->

    <section anchor="introduction" title="Introduction">

<t>The generic nature of the personal computer has enabled application providers to write general purpose programs and to make it available for download. This flexibility has lead to lots of innovation on the Internet but has also introduced security challenges since it is difficult for end users to judge the trustworthiness of downloaded programs in any reasonable way. Consequently, many users are very suspicious about any download they are asked to accept. An important goal of those deploying applications is to reach a widespread deployment as fast as possible and to react to changing needs as quickly as possible, which to a large extent requires the ability to continously update code on end devices. With operating system updates happening less frequently and the acceptance for software downloads decreasing the browser was seen by many as an ideal platform for dynamically downloaded running code. JavaScript was initially perceived as being quite limited in functionality but has been supported by all browsers. This perception has changed over the last couple of years when it became the scripting language implemented in the majority of browsers, also referred as the 'assembly language of the Internet'.</t> 
<t>
For application developers writing code running on Web servers as well as for applications that are downloaded to the end device the desire was always to develop the application once without having to consider all the different runtimes (operating systems or browsers). Now, with the PC and the cellular phone segments getting increasingly blurry this desire is stronger than ever considering the increased number of obstacles that have to be dealt with. For example, it is highly unlikely that an application will work on various different devices even if all the devices were produced by a single mobile phone vendor.  Getting users to download new applications, and to install software updates also leaves software developers in a difficult situation. 
</t>
<t>
How can software be developed so that it can (1) be updated instantly when a new version becomes available, (2) be used across a wide range of devices, and (3) be as powerful as regular desktop applications? This sounds almost impossible but with the increased capabilities of Web browsers, and JavaScript in particular, it seems that the Internet community has gotten a couple of steps closer to achieve this goal.  
</t>
<t>This document describes these developments, highlights impacts for the standardization community, and provides recommendations for those developing applications.</t>

<t>Note that the writeup heavily refers to JavaScript as a mechanism for mobile code distribution. There is, however, nothing special about JavaScript as a language by itself and it may well be possible that other languages will be developed for usage in other environments offering similar or even superior capabilities.</t>

</section> 

<section title="Impact for the Standardization Community">

<t>In the application area communication protocols often follow the pattern where an end host utilizes some application service provider for communication setup and sometimes also for message routing towards the other communication end point. Examples of such a standardized communication protocols are the Post Office Protocol (POP) <xref target="RFC1939"/>, the Internet Message Access Protocol (IMAP) <xref target="RFC3501"/>, as well as the Session Initiation Protocol (SIP) <xref target="RFC3261"/> and the Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC3920"/>.
</t>
<t>
<xref target="single-domain"/> shows a typical scenario where two hosts, Alice and Bob, interact with an application provider. A desired interoperability goal often has been to let a software vendor develop the software clients at the end hosts to interact with a random application provider offering the specific protocol implementation. </t>
        <t>
          <figure anchor="single-domain" title="Communication Partners from a Single Domain">
            <artwork>
              <![CDATA[
          .................
          |               |
          |  Application  |
          |  Service      |
          |  Provice      |
          |  Example.com  |
          |_______________|
              _,   .
            ,'      `.
         _,'          `.
       ,'               `._
     -'                    -
  ,''''''''|           ,''''''''|
  |  End   |           |  End   |
  |  Host  |           |  Host  |
  |  Alice |           |  Bob   |
  |........'           |........'
           ]]></artwork>
          </figure>
        </t>
<t>Many protocols developed in the IETF also offer the ability to let users from different application service providers (via their end hosts) to communicate. <xref target="cross-domain"/> shows this architecture graphically, where additional interoperability needs are created between the application service provider domains.</t> 
        <t>
          <figure anchor="cross-domain" title="Communication Partners from Multiple Domains">
            <artwork>
              <![CDATA[
           .................              .................
           |               |              |               |
           |  Application  |              |  Application  |
           |  Service      |--------------|  Service      |
           |  Provider     |              |  Provider     |
           |  Example.com  |              |  Example.org  |
           |_______________|              |_______________|
               _,                                .
             ,'                                   `.
          _,'                                       `.
        ,'                                            `._
      -'                                                 -
   ,''''''''|                                        ,''''''''|
   |  End   |                                        |  End   |
   |  Host  |                                        |  Host  |
   |  Alice |                                        |  Bob   |
   |........'                                        |........'
           ]]></artwork>
          </figure>
        </t>

<t>These two figures did not make the attempt to differentiate signaling message exchanges from the actual data traffic exchange. The data traffic may be exchanged directly between the end hosts themselves and therefore creates additional interoperability requirements when those software clients shall be developed by independent parties.</t>


<t>While many standardization efforts in the IETF have considered the possibility for using proprietary protocols along the end host to application service provider leg, this has usually been considered as exception or a transition case. It is typically assumed that the desired end state of standardization is to move from a proprietary protocol to the standardized alternative in the long run, which allows client software vendors to interact with all forms of application service providers. Such an approach increases the need for standardization and requires far more interoperable network elements to exist.</t>

<t>With a mobile code distribution platform as the Web with JavaScript offers it is possible to leave the end host to application service provider interaction largely non-standardized. Only very few standardization actions are required, to for example, enhance the capability of JavaScript to perform additional functions, such as the access to underlying hardware functions (e.g., microphone, GPS module or a camera).</t>

<t>Quite clearly applications can be designed in a way that fewer standardized client-server protocols are needed. The question therefore remains for those actively pursuing standardization as to where the limitations of the JavaScript-based mobile code distribution approach is. <xref target="challenges"/> tries to explore this aspect in more detail. </t>

</section> 

<section anchor="challenges" title="Limitations of Mobile Code Distribution">
<t>The usage of JavaScript is, however, not always the right choice for application developers and even though a number of new building blocks are being made available, such as HTML5 <xref target="html5"/> and various JavaScript extensions, there are still a number of limitations in today's browser environment. We list a couple of those challenges, some of which will be resolved in the near future as standardization and deployment progresses, while others will remain a challenge for a long time. 
</t> 

<section title="Performance Limitations"> 

<t>Early JavaScript implementations did not offer high performance. Over many years very little attention was paid to boost the performance until recently when the Google JavaScript engine V8 <xref target="v8"/> started to compile JavaScript code directly into machine code when it is first executed. More details about the design can be found at <xref target="v8-design"/>.</t>

<t>A more serious limitation is the graphics capabilities in browsers. Efforts are under way to enhance the API capabilities, for example WebGL <xref target="WebGL"/> bringing 3D graphics to the browser with features similar to OpenGL ES 2.0 that can be used in HTML5 canvas elements but expensive computations on the end host need to migrate from the Central Processing Unit (CPU) to the Graphics Processing Unit (GPU) for proper performance. Simple 3D games (similar to the recently demonstrated Quake II port to HTML5 <xref target="Quake2"/> utilizing JavaScript, the WebSocket API <xref target="WebSockets"/> and the Web Storage API <xref target="WebStorage"/>) can now be implemented but state-of-the-art games and virtual worlds are out of reach. The problem is with the number of polygons that many games and virtual worlds need to process and display. Games, like Quake, use a limited number of textures, and the complexity of the scene graph is small.</t>

<t>In comparison to virtual worlds where the content is put together by users, in many games the playing field is carefully designed by experts. This has implications for the complexity of the scene graph. On the other hand, most virtual worlds do not rely on rapid communication updates in the same way that many action and tactic games do. Joshua Bell illustrated this with an example of 'a quiet scene with a single user running around in SecondLife <xref target="SecondLife"/>. A teleport to a region can easily have a scene graph with 2000 nodes, a couple hundred 3D textures, 4000 vertexes, and 20 MByte of vertex data. This corresponds to the maximum a graphics developer would typically like to have in a state-of-the-art game. In a busy scene with lot of user generated content and avatars the volume easily jumps up by a factor of five.' <xref target="joshua"/>. The size of the game itself (often due to the high quality textures) and software updates is impressive; often reaching beyond several 100 Mbytes. Utilizing persistent storage and caching in combination with more aggressive client-server interactions demands a different style of programming and therefore also puts different constraints on the protocol design. This might also stress the current Mbyte limits for Web storage.</t>

<t>Initial work to deal with more sophisticated graphics computation has started already, as described in the recently published article <xref target="performance"/> about elevating JavaScript performance through offloading processing to the GPU. As stated in the announcement of the Jetpack 0.5 contest <xref target="winner"/>: 'By giving webpages and add-ons easy access to the raw processing power available on most computers, the range of abilities that the web can have greatly increases.'.</t> 

</section> 

<section title="Transport Protocol Limitations">

<t>In <xref target="I-D.rosenberg-internet-waist-hourglass"/> Jonathan Rosenberg argued that the new waist of the Internet hourglass is UDP and TCP, rather than IP as in the initial design. Today, application protocol designers may, however, get the impression that tunneling inside HTTP or even HTTPS is required to get an application running in a large number of environments, especially to reach a customer base that is connected to the Internet through an enterprise network. Needless to say that more complex tunneling leads to more complexity, the data transport adds overhead and the initial environment sensing phase adds delays. This is certainly true for the VoIP context where the payload data is comparatively small to the overall header size (including the TCP/HTTP headers). The work on Interactive Connectivity Establishment (ICE) <xref target="RFC5245"/> is relevant for the sensing phase and this functionality may need to be replicated in the browser environment. For this purpose   it is more and more common to limit the number of individual connections and to instead multiplex them over a single transport connection. See, for example, SPDY <xref target="SPDY"/> and developments in the VoIP context <xref target="I-D.westerlund-avtcore-multiplex-architecture"/>. Worse than inefficiency is that some real-time applications do not behave well with the retransmission behavior of TCP. For real-time voice and video applications, for virtual worlds, and for many games it is acceptable to loose video and voice frames from time to time without waiting for retransmission.</t>

<t>Adding the support for UDP to browsers again adds complexity, as the experience with Voice over IP showed, particularly when the protocols are not multiplexed together, so that it is necessary to identify multiple working end-to-end paths for the traversal of Network Address Translators (NATs) and firewalls. With the transition to IPv6 the number of NATs is likely to increase. Furthermore, in many cases it might be desired to perform route optimization for data traffic and to exchange it directly between the two endpoints whenever possible to reduce the financial costs and the added delay of using an anchor point. For example, Google Talk only requires the involvement of relays for 8% of their calls, as reported in <xref target="googletalk"/> by utilizing ICE.</t>

<t>It should be noted that audio and video streaming capabilities have been available in the browser for a while with plug-in support. More sophisticated audio support, such as tagging audio with x/y positions for 3D audio, is not even possible with the Adobe Flash application today. The challenge with video support in browsers is based on the lack of universal support of a specific video codec. The lack of hardware support is secondary although relevant for increased performance and lower energy consumption. Naturally, supporting different codecs makes the work of web developers and content distributors difficult. </t>

</section>

<section title="Security, Privacy, and Cryptographic Processing Limitations">

<t>Many protocol mechanisms have several built-in cryptographic primitives and and the same capabilities must be available in the browser 
in order to migrate applications that use these capabilities. For example, JavaScript allows cryptographic operations to be implemented (see <xref target="aes"/> for a JavaScript AES or other cryptographic functions <xref target="crypto-js"/> implementation) but access to hardware crypto-processors, smart cards <xref target="mozilla-crypto"/> or to key storages from JavaScript is still at an early stage and, at the time of writing, not available as a standardized JavaScript API. <!-- The authors are also not aware of a shared authorization policy store that allows a number of websites to benefit from a central user preferences store, such as settings regarding the distribution of location information. It is quite likely that users might prefer to control their privacy settings in one location, given a specific context, and have those settings applied to all running Web applications to avoid private information leakage.  --> 
</t>
<t>The security model of JavaScript is different than the one offered by Widgets <xref target="widget"/> (available with different platforms/operating systems, such as Mac OS X (via the dashboard), Windows 7, Opera, etc.) or classical operating systems. JavaScript code does not declare what operations it is intended to perform. Even with Widgets there is the question of who verifies any of these privileges. It can hardly be assumed that the end user will be bothered with such a responsibility (due to the lack of his or her expertise. Furthermore, the semantic of end-to-end security is challenged when the distinct communication legs support protocols with different semantics, and dissimilar encodings. Imagine a browser that sends location data encoded in JSON <xref target="json"/>, for example using <xref target="geojson"/>, to a web server, which converts it to XML, for example into the PIDF-LO format <xref target="RFC4119"/> to interoperate with another application service provider. Consequently, this server then uses XMPP to deliver notifications to its users, for example using <xref target="xep80"/>. No two of these encodings offer the same privacy mechanisms nor security properties.  
</t>
<!-- 
<t>From the work in the W3C Geolocation <xref target="w3c-geolocation"/> and the W3C Device API and Policy <xref target="w3c-dap"/> working group it was observable in recent years that attempts to incorporate privacy mechanisms beyond notice and choice are hard to accomplish with community consensus. While many of these user-interface indications barely work on a PC with a large screen, keyboard and mouse, it remains to be seen how successful they will be on devices with display and input constraints. For a more detailed discussion of privacy challenges related to initial implementations of the Geolocation API see <xref target="berkeley-location"/>. Further privacy related information can be found with the recent 'W3C Workshop on Privacy for Advanced Web APIs' <xref target="deviceAPI"/>. 
</t>
--> 

<t>The privacy implications of a heavily JavaScript-centered Web environment are not yet well understood. For example, the SIP privacy mechanisms, described in <xref target="RFC3323"/>, <xref target="RFC5379"/>, and <xref target="RFC5767"/>) rely to a large degree on the end point to select independent RTP/SRTP relays, and to obfuscate important header fields based on the context provided by the user. One could argue that these standardized SIP privacy extensions represent a community design even though those who deploy ultimately make the final decisions about what policies to use. When the executable code itself is provided by the application service provider then the privacy functionality for data minimization can change at any point in time with little possibility that the user will notice. Only the application service provider makes decisions about what functionality it desires without having to consult or agree with anyone else.</t>

</section>

<section title="Source Code Hiding Limitations">

<t>In many commercial environments it is not desirable to make source code available to the public. With JavaScript the source code is sent from the server to the browser and only compression and obfuscation tools are available <xref target="hiding"/>. However, the only way to protect code is to not expose it to observers, instead leaving the important code on the server-side and have a minimal public Javascript code segment use asynchronous message exchanges with the server.</t>

</section>
</section>

<section title="Recommendations">

<t>This section lists a few basic questions for protocol authors. We hope that in answering these questions honestly a thought process will be triggered that may lead you to re-consider your design before starting the standardization effort that may not lead to successful deployment. Note: We use the term 'protocol' below to refer to a protocol extension, a single protocol, or to a complete protocol suite, or an entire architecture.</t>
 
<t><list style="numbers">
<t>Does your standardization effort fall priminarily into the client-to-server interaction described in this document? If the answer is "yes", is there a story how the involved stakeholders can innovate at a high speed?</t>
<t>Are you attempting to offer functionality typically found at the application layer at the lower layers? If so, have you carefully investigated the cost vs. benefit tradeoff?</t>
<t>Does your protocol design involve other stakeholders whoes goals are either not known or potentially not aligned with the goals of your envisioned deployment, i.e. for successful deployment do you require cooperation of stakeholders who may have disincentives (or unclear incentives) to deploy your protocol?</t>
<t>When designing your protocol have you considered the Web application environment? Do you understand Web development yourself or do you have experts from the Web development community involved in your work?</t>
<t>Does your protocol design offer the ability to carry payloads on HTTP/HTTPS?</t>
<t>Why is the current Web framework unable to meet your application requirements? Have you documented the reasons?</t>
<t>Have you implemented your protocol in a tyipcal Web development programming language? Hands-on experience may help you to detect problems with using your application design in a Web context in early stages of the design.</t>
<t>Is your protocol deployed already? If not, who do you envision to implement and deploy it?</t>
</list>
</t>
</section>

<section title="Conclusions">
<t>This document aims to highlight recent trends in Web application development with impact to Internet standardization. In a nutshell, there is a certain class of applications for which the standardization need is diminishing: chances are good that your standardization work will not be relevant relevant in such an environment.</t>

<t>A lot of this change is driven by mobile code distribution using JavaScript executed on the end host (typically in the Web browser) while server-to-server communication is not yet impacted. 

<list style="empty"> 
<t>We are, however, already seeing server-side JavaScript implementations. NodeJS <xref target="nodeJS"/> is such an example that is built on top of the V8 JavaScript engine. It runs multiple concurrent JavaScript execution engines in one thread allowing to develop a massively concurrent Web server in JavaScript, addressing a typical pain point for server developers when implementing distributed systems. As another example, CommonJS <xref target="commonjs"/> defines APIs that handle many common application needs, including those that go beyond the usage in Web browsers (such as regular command line programs).
</t>
</list> 
</t> 

<t>Hence, just as the barriers for rapidly deploying code have dropped on the client side; the server side will likely follow.</t>

<t>Even if there are challenges for standardization there are other areas where work is needed: 
<list style="symbols">
<t>The development of of protocol mechanisms to support a larger range of applications will have an important role to play in the future. Examples of such efforts include the currenly ongoing work on 'BiDirectional or Server-Initiated HTTP' in the HYBI working group <xref target="hybi"/>. For future work on improving the performance of the Web, for example <xref target="speed"/>, improvements in HTTP, or common security functionality for the Web as standardized in the Web Security working group <xref target="websec"/>.</t> 
<t>In those areas where application islands want to interact with larger eco-systems the need for cross-domain communication arises. Often, this is done in a proprietary way but for larger distributed systems and for common functions standardized solutions are valuable. This can be observed today within the VoIP environment, although much slower than expected, in the case of Voice over IP peering but also in the Internet identity management community under the umbrella of 'data portability' <xref target="data-portability"/>. As recent IETF work in this area the Open Authentication Protocol (oauth) <xref target="oauth"/> working group could be referenced. OAuth deals with more sophisticated security protocol interactions that require multiple parties to participate in an interoperable way.</t>
<t>Everyone knows that protocol design is hard regardless whether it happens inside a standards developing organization, like the IETF or W3C, or in some other less structured community. For Web developers the standardization results are often only visible if they appear in form of rich JavaScript libraries and development frameworks, such as JQuery <xref target="jquery"/>, the Prototype JavaScript Framework <xref target="prototype"/>, MooTools <xref target="mootools"/>, YUI <xref target="yui"/> and Narwahl <xref target="narwhal"/>. In order to have an impact in the Web community it is essential for working groups participants to think about how to their protocols can be deployed in a Web environment, for by making JavaScript implementations available. The desire in the standards developing community, including the IETF, to be programming language agnostic and to avoid API standardization may need to be re-visited in light of these recent developments. Extending JavaScript may, for example, require new Document Object Models (DOMs) <xref target="dom"/> and these could serve as a valuable contribution.</t>
</list> 
</t>
<t>
Offering almost unlimited capabilities to JavaScript/HTML running in a browser (in the same style as native applications run in an operating system environment) will raise security concerns and will consequently require countermeasures (such as 'deep inspection' and blocking). This in turn will sparkle new ideas to bypass limitations introduced, for example by utilizing new scripting languages with different capabilities, etc. This is an arms race that the IT industry is already able to observe already with deep packet inspection firewalls and peer-to-peer networks during the last few years.
</t>
<t>
It is unavoidable to get the impression that the hard problems, particularly to security concerns regarding the distribution of new software in whatever form, have not been tackled. Instead, the browser becomes the new operating system, inherits the same weaknesses and is likely to share the same fate.  
</t>
</section>


    <!-- ====================================================================== -->

    <section anchor="SecurityConsiderations" title="Security Considerations">
<t>
This document includes discussions related to security.</t>
</section>

    <!-- ====================================================================== -->

    <section anchor="iana" title="IANA Considerations">
	<t>
This document does not require actions by IANA. </t>
    </section>

    <!-- ====================================================================== -->
	
    <section title="Acknowledgements">
      <t>The authors would like to thank Gonzalo Camarillo, Robert Sparks, Alissa Cooper, Blaine Cook, Alexey Melnikov, Peter Saint-Andre, Jonathan Rosenberg, Lisa Dusseault, Joshua Bell, John Hurliman, Meadhbh Hamrick, Mark Nottingham, Anders Rundgren, Markus Isomaki, Spencer Dawkins, Jan Kall, Jan Ignatius and Thomas Roessler.</t>
      
      <t>An early version of this document was written to provide additional background for the IETF#80 IAB technical plenary discussion in Prague, March 2011. A number of persons provided their feedback, including Dave Crocker, Pete Resnick, Leslie Daigle, Harald Alvestrand, Jonathan Rosenberg, Dave Cridland, Nico Williams, Peter Saint-Andre, Graham Klyne, 
      Philip Hallam-Baker, Scott Brim, Henry Sinnreich, Eliot Lear, Mark Nottingham, 
      Paul Hoffman, Ted Hardie, Cyrus Daboo, Claudio Allocchio, and Sam Hartman. We thank them for the lively discussion.</t> 
    </section>
  </middle>
  <!-- ====================================================================== -->
  <back>
  

    <references title="Informative References"> 
	          
     	<?rfc include="reference.I-D.rosenberg-internet-waist-hourglass"?>
     	<?rfc include="reference.I-D.westerlund-avtcore-multiplex-architecture"?>
		<?rfc include="reference.RFC.4119"?>
		<?rfc include="reference.RFC.3323"?>
		<?rfc include="reference.RFC.5379"?>
		<?rfc include="reference.RFC.5767"?>
		<?rfc include="reference.RFC.3261"?>
		<?rfc include="reference.RFC.3920"?>
		<?rfc include="reference.RFC.5245"?>
		<?rfc include="reference.RFC.1939"?>
		<?rfc include="reference.RFC.3501"?>



      <reference anchor="SPDY">
        <front>
          <title>SPDY: An experimental protocol for a faster web</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Oct"year="2011"/>
        </front>
        <format type='HTML'
        target='http://www.chromium.org/spdy' />
      </reference>

      <reference anchor="v8">
        <front>
          <title>V8 JavaScript Engine</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://code.google.com/apis/v8/' />
      </reference>
 
 

      <reference anchor="jquery">
        <front>
          <title>jQuery: The Write Less, Do More, JavaScript Library</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://jquery.com/' />
      </reference>


      <reference anchor="googletalk">
        <front>
          <title>Google Talk for Developers: Important Concepts</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://code.google.com/intl/de-AT/apis/talk/libjingle/important_concepts.html' />
      </reference>

      <reference anchor="hiding">
        <front>
          <title>(JavaScript) Minification v Obfuscation</title>
          <author fullname="D. Crockford" initials="D." surname="Crockford">
            <organization></organization> 
          </author>
          <date month="Mar"year="2006"/>
        </front>
        <format type='HTML'
        target='http://yuiblog.com/blog/2006/03/06/minification-v-obfuscation/' />
      </reference>

      <reference anchor="SecondLife">
        <front>
          <title>Second Life</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://secondlife.com/' />
      </reference>

      <reference anchor="mozilla-crypto">
        <front>
          <title>JavaScript Crypto</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://tinyurl.com/dx4x5w' />
      </reference>

      <reference anchor="crypto-js">
        <front>
          <title>crypto-js: JavaScript implementations of standard and secure cryptographic algorithms</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://code.google.com/p/crypto-js/' />
      </reference>


      <reference anchor="joshua">
        <front>
          <title>Private communication between Joshua Bell, Hannes Tschofenig and Jon Peterson about browser performance limitations</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Aug"year="2010"/>
        </front>
      </reference>

      <reference anchor="v8-design">
        <front>
          <title>V8 JavaScript Engine - Design Elements</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://code.google.com/apis/v8/design.html' />
      </reference>

      <reference anchor="WebGL">
        <front>
          <title>WebGL</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='https://developer.mozilla.org/en/WebGL' />
      </reference>

      <reference anchor="Quake2">
        <front>
          <title>Quake II Google Web Toolkit (GWT) Port</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://code.google.com/p/quake2-gwt-port/' />
      </reference>

      <reference anchor="WebSockets">
        <front>
          <title>The WebSocket API</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://dev.w3.org/html5/websockets/' />
      </reference>

      <reference anchor="WebStorage">
        <front>
          <title>Web Storage</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Aug"year="2010"/>
        </front>
        <format type='HTML'
        target='http://dev.w3.org/html5/webstorage/' />
      </reference>


      <reference anchor="performance">
        <front>
          <title>Elevating JavaScript Performance Through GPU Power</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Jan"year="2010"/>
        </front>
        <format type='HTML'
        target='http://mozillalabs.com/jetpack/2010/01/25/elevating-javascript-performance-through-gpu-power/' />
      </reference>

      <reference anchor="winner">
        <front>
          <title>Jetpack 0.5 Contest: A Winner</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Nov"year="2009"/>
        </front>
        <format type='HTML'
        target='http://mozillalabs.com/jetpack/2009/11/10/jetpack-0-5-contest-a-winner/' />
      </reference>

      <reference anchor="data-portability">
        <front>
          <title>Data Portability Project: Share and Remix Data using Open Standards</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://dataportability.org/' />
      </reference>

      <reference anchor="aes">
        <front>
          <title>JavaScript Implementation of AES Advanced Encryption Standard in Counter Mode</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.movable-type.co.uk/scripts/aes.html' />
      </reference>

      <reference anchor="deviceAPI">
        <front>
          <title>W3C Workshop on Privacy for Advanced Web APIs</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Jul"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.w3.org/2010/api-privacy-ws/' />
      </reference>

      <reference anchor="nodeJS">
        <front>
          <title>nodeJS</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://nodejs.org/' />
      </reference>

      <reference anchor="json">
        <front>
          <title>JavaScript Object Notation (JSON)</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://en.wikipedia.org/wiki/JSON' />
      </reference>

      <reference anchor="geojson">
        <front>
          <title>The GeoJSON Format Specification</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Jun"year="2008"/>
        </front>
        <format type='HTML'
        target='http://geojson.org/geojson-spec.html' />
      </reference>


      <reference anchor="xep80">
        <front>
          <title>XEP-0080: User Location</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2009"/>
        </front>
        <format type='HTML'
        target='http://xmpp.org/extensions/xep-0080.html' />
      </reference>

    <reference anchor="speed">
        <front>
          <title>Let's make the web faster</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://code.google.com/speed/' />
      </reference>

    <reference anchor="websec">
        <front>
          <title>IETF Web Security (websec) Working Group Charter</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Mar"year="2011"/>
        </front>
        <format type='HTML'
        target='http://datatracker.ietf.org/wg/websec/charter/' />
      </reference>


    <reference anchor="prototype">
        <front>
          <title>Prototype JavaScript framework: Easy Ajax and DOM anipultion for dynamic web applications</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.prototypejs.org' />
      </reference>


    <reference anchor="mootools">
        <front>
          <title>MooTools - a compact javascript framework</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://mootools.net' />
      </reference>

    <reference anchor="yui">
        <front>
          <title>Yahoo! User Interface Library 3</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://developer.yahoo.com/yui/3/' />
      </reference>

    <reference anchor="widget">
        <front>
          <title>W3C Web Applications (WebApps) Working Group</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.w3.org/2008/webapps/' />
      </reference>

    <reference anchor="commonjs">
        <front>
          <title>CommonJS</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.commonjs.org/' />
      </reference>

    <reference anchor="w3c-geolocation">
        <front>
          <title>W3C Geolocation Working Group</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.w3.org/2008/geolocation' />
      </reference>


    <reference anchor="dom">
        <front>
          <title>Document Object Model</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://en.wikipedia.org/wiki/Document_Object_Model' />
      </reference>

    <reference anchor="Ajax">
        <front>
          <title>Ajax (programming)</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://en.wikipedia.org/wiki/Ajax_%28programming%29' />
      </reference>

    <reference anchor="w3c-dap">
        <front>
          <title>Device APIs and Policy Working Group</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.w3.org/2009/dap/' />
      </reference>

    <reference anchor="berkeley-location">
        <front>
          <title>Privacy Issues of the W3C Geolocation API, UC Berkeley School of Information Report 2010-038</title>
           <author fullname="N. Doty" initials="N." surname="Doty">
            <organization></organization> 
           </author>
           <author fullname="D. Mulligan" initials="D." surname="Mulligan">
            <organization></organization> 
           </author>
           <author fullname="E. Wilde" initials="E." surname="Wilde">
            <organization></organization> 
           </author>
          <date month="Feb"year="2010"/>
        </front>
        <format type='HTML'
        target='http://escholarship.org/uc/item/0rp834wf' />
      </reference>
      

    <reference anchor="narwhal">
        <front>
          <title>Narwhal - A general purpose JavaScript platform</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://narwhaljs.org' />
      </reference>
      
    <reference anchor="oauth">
        <front>
          <title>IETF Open Authentication Protocol (oauth) Working Group Charter</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='https://datatracker.ietf.org/wg/oauth/charter/' />
      </reference>

    <reference anchor="hybi">
        <front>
          <title>IETF BiDirectional or Server-Initiated HTTP (hybi) Working Group Charter</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Mar"year="2011"/>
        </front>
        <format type='HTML'
        target='https://datatracker.ietf.org/wg/hybi/charter/' />
      </reference>

    <reference anchor="flash">
        <front>
          <title>Adobe Flash Player</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.adobe.com/products/flashplayer/' />
      </reference>

    <reference anchor="silverlight">
        <front>
          <title>Microsoft Silverlight</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.microsoft.com/silverlight/' />
      </reference>


    <reference anchor="html5">
        <front>
          <title>W3C HTML Working Group Charter</title>
          <author> 
            <organization></organization> 
          </author>
          <date month="Sep"year="2010"/>
        </front>
        <format type='HTML'
        target='http://www.w3.org/2007/03/HTML-WG-charter.html' />
      </reference>

	</references>
  </back>
</rfc>
