idnits 2.17.1 draft-tschofenig-post-standardization-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 date (May 9, 2012) is 4370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '46' is defined on line 683, but no explicit reference was found in the text == Unused Reference: '47' is defined on line 685, but no explicit reference was found in the text == Unused Reference: '48' is defined on line 687, but no explicit reference was found in the text == Unused Reference: '49' is defined on line 689, but no explicit reference was found in the text == Unused Reference: '50' is defined on line 691, but no explicit reference was found in the text == Unused Reference: '51' is defined on line 695, but no explicit reference was found in the text == Unused Reference: '52' is defined on line 697, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. '2') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. '4') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 5245 (ref. '17') (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-03) exists of draft-westerlund-avtcore-multiplex-architecture-01 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational B. Aboba 5 Expires: November 10, 2012 Microsoft Corporation 6 J. Peterson 7 NeuStar, Inc. 8 D. McPherson 9 Verisign 10 May 9, 2012 12 Trends in Web Applications and the Implications on Standardization 13 draft-tschofenig-post-standardization-02.txt 15 Abstract 17 Advancements in the design of web browsers have introduced 18 fundamental changes to the architecture of application protocols. 19 The widespread availability and growing sophistication of JavaScript 20 interpreters in browsers enables web servers to push to browsers all 21 of the application logic required to implement a client-server 22 protocol. Consequently, many client-server applications that once 23 required an installed client on a host computer now can rely simply 24 on a modern browser to act as a client for the purposes of a 25 particular application. For example, where once email clients 26 required a custom application to access an inbox, increasingly a web 27 browser can serve this purpose as well as the purpose-built 28 applications of the past. Similarly, HTTP with the assistance of 29 JavaScript can subsume the functions performed by the protocols like 30 POP3 and IMAP. The need for Internet standards beyond HTTP to 31 implement an email inbox application consequently diminishes - why 32 author standards and worry about interoperability of clients and 33 servers when the server can simply push to the client all the code it 34 needs to be interoperable? 36 Many client-server applications on the Internet could potential 37 migrate to this code distribution methodology. 39 [Note: A separate mailing list has been created for discussions 40 related to this document and it can be found here: 41 https://www.ietf.org/mailman/listinfo/webapps ] 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on November 10, 2012. 60 Copyright Notice 62 Copyright (c) 2012 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Impact for the Standardization Community . . . . . . . . . . . 6 79 3. Limitations of Mobile Code Distribution . . . . . . . . . . . 9 80 3.1. Performance Limitations . . . . . . . . . . . . . . . . . 9 81 3.2. Transport Protocol Limitations . . . . . . . . . . . . . . 10 82 3.3. Security, Privacy, and Cryptographic Processing 83 Limitations . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.4. Source Code Hiding Limitations . . . . . . . . . . . . . . 12 85 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13 86 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 90 9. Informative References . . . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 The generic nature of the personal computer has enabled application 96 providers to write general purpose programs and to make it available 97 for download. This flexibility has lead to lots of innovation on the 98 Internet but has also introduced security challenges since it is 99 difficult for end users to judge the trustworthiness of downloaded 100 programs in any reasonable way. Consequently, many users are very 101 suspicious about any download they are asked to accept. An important 102 goal of those deploying applications is to reach a widespread 103 deployment as fast as possible and to react to changing needs as 104 quickly as possible, which to a large extent requires the ability to 105 continously update code on end devices. With operating system 106 updates happening less frequently and the acceptance for software 107 downloads decreasing the browser was seen by many as an ideal 108 platform for dynamically downloaded running code. JavaScript was 109 initially perceived as being quite limited in functionality but has 110 been supported by all browsers. This perception has changed over the 111 last couple of years when it became the scripting language 112 implemented in the majority of browsers, also referred as the 113 'assembly language of the Internet'. 115 For application developers writing code running on Web servers as 116 well as for applications that are downloaded to the end device the 117 desire was always to develop the application once without having to 118 consider all the different runtimes (operating systems or browsers). 119 Now, with the PC and the cellular phone segments getting increasingly 120 blurry this desire is stronger than ever considering the increased 121 number of obstacles that have to be dealt with. For example, it is 122 highly unlikely that an application will work on various different 123 devices even if all the devices were produced by a single mobile 124 phone vendor. Getting users to download new applications, and to 125 install software updates also leaves software developers in a 126 difficult situation. 128 How can software be developed so that it can (1) be updated instantly 129 when a new version becomes available, (2) be used across a wide range 130 of devices, and (3) be as powerful as regular desktop applications? 131 This sounds almost impossible but with the increased capabilities of 132 Web browsers, and JavaScript in particular, it seems that the 133 Internet community has gotten a couple of steps closer to achieve 134 this goal. 136 This document describes these developments, highlights impacts for 137 the standardization community, and provides recommendations for those 138 developing applications. 140 Note that the writeup heavily refers to JavaScript as a mechanism for 141 mobile code distribution. There is, however, nothing special about 142 JavaScript as a language by itself and it may well be possible that 143 other languages will be developed for usage in other environments 144 offering similar or even superior capabilities. 146 2. Impact for the Standardization Community 148 In the application area communication protocols often follow the 149 pattern where an end host utilizes some application service provider 150 for communication setup and sometimes also for message routing 151 towards the other communication end point. Examples of such a 152 standardized communication protocols are the Post Office Protocol 153 (POP) [1], the Internet Message Access Protocol (IMAP) [2], as well 154 as the Session Initiation Protocol (SIP) [3] and the Extensible 155 Messaging and Presence Protocol (XMPP) [4]. 157 Figure 1 shows a typical scenario where two hosts, Alice and Bob, 158 interact with an application provider. A desired interoperability 159 goal often has been to let a software vendor develop the software 160 clients at the end hosts to interact with a random application 161 provider offering the specific protocol implementation. 163 ................. 164 | | 165 | Application | 166 | Service | 167 | Provice | 168 | Example.com | 169 |_______________| 170 _, . 171 ,' `. 172 _,' `. 173 ,' `._ 174 -' - 175 ,''''''''| ,''''''''| 176 | End | | End | 177 | Host | | Host | 178 | Alice | | Bob | 179 |........' |........' 181 Figure 1: Communication Partners from a Single Domain 183 Many protocols developed in the IETF also offer the ability to let 184 users from different application service providers (via their end 185 hosts) to communicate. Figure 2 shows this architecture graphically, 186 where additional interoperability needs are created between the 187 application service provider domains. 189 ................. ................. 190 | | | | 191 | Application | | Application | 192 | Service |--------------| Service | 193 | Provider | | Provider | 194 | Example.com | | Example.org | 195 |_______________| |_______________| 196 _, . 197 ,' `. 198 _,' `. 199 ,' `._ 200 -' - 201 ,''''''''| ,''''''''| 202 | End | | End | 203 | Host | | Host | 204 | Alice | | Bob | 205 |........' |........' 207 Figure 2: Communication Partners from Multiple Domains 209 These two figures did not make the attempt to differentiate signaling 210 message exchanges from the actual data traffic exchange. The data 211 traffic may be exchanged directly between the end hosts themselves 212 and therefore creates additional interoperability requirements when 213 those software clients shall be developed by independent parties. 215 While many standardization efforts in the IETF have considered the 216 possibility for using proprietary protocols along the end host to 217 application service provider leg, this has usually been considered as 218 exception or a transition case. It is typically assumed that the 219 desired end state of standardization is to move from a proprietary 220 protocol to the standardized alternative in the long run, which 221 allows client software vendors to interact with all forms of 222 application service providers. Such an approach increases the need 223 for standardization and requires far more interoperable network 224 elements to exist. 226 With a mobile code distribution platform as the Web with JavaScript 227 offers it is possible to leave the end host to application service 228 provider interaction largely non-standardized. Only very few 229 standardization actions are required, to for example, enhance the 230 capability of JavaScript to perform additional functions, such as the 231 access to underlying hardware functions (e.g., microphone, GPS module 232 or a camera). 234 Quite clearly applications can be designed in a way that fewer 235 standardized client-server protocols are needed. The question 236 therefore remains for those actively pursuing standardization as to 237 where the limitations of the JavaScript-based mobile code 238 distribution approach is. Section 3 tries to explore this aspect in 239 more detail. 241 3. Limitations of Mobile Code Distribution 243 The usage of JavaScript is, however, not always the right choice for 244 application developers and even though a number of new building 245 blocks are being made available, such as HTML5 [5] and various 246 JavaScript extensions, there are still a number of limitations in 247 today's browser environment. We list a couple of those challenges, 248 some of which will be resolved in the near future as standardization 249 and deployment progresses, while others will remain a challenge for a 250 long time. 252 3.1. Performance Limitations 254 Early JavaScript implementations did not offer high performance. 255 Over many years very little attention was paid to boost the 256 performance until recently when the Google JavaScript engine V8 [6] 257 started to compile JavaScript code directly into machine code when it 258 is first executed. More details about the design can be found at 259 [7]. 261 A more serious limitation is the graphics capabilities in browsers. 262 Efforts are under way to enhance the API capabilities, for example 263 WebGL [8] bringing 3D graphics to the browser with features similar 264 to OpenGL ES 2.0 that can be used in HTML5 canvas elements but 265 expensive computations on the end host need to migrate from the 266 Central Processing Unit (CPU) to the Graphics Processing Unit (GPU) 267 for proper performance. Simple 3D games (similar to the recently 268 demonstrated Quake II port to HTML5 [9] utilizing JavaScript, the 269 WebSocket API [10] and the Web Storage API [11]) can now be 270 implemented but state-of-the-art games and virtual worlds are out of 271 reach. The problem is with the number of polygons that many games 272 and virtual worlds need to process and display. Games, like Quake, 273 use a limited number of textures, and the complexity of the scene 274 graph is small. 276 In comparison to virtual worlds where the content is put together by 277 users, in many games the playing field is carefully designed by 278 experts. This has implications for the complexity of the scene 279 graph. On the other hand, most virtual worlds do not rely on rapid 280 communication updates in the same way that many action and tactic 281 games do. Joshua Bell illustrated this with an example of 'a quiet 282 scene with a single user running around in SecondLife [12]. A 283 teleport to a region can easily have a scene graph with 2000 nodes, a 284 couple hundred 3D textures, 4000 vertexes, and 20 MByte of vertex 285 data. This corresponds to the maximum a graphics developer would 286 typically like to have in a state-of-the-art game. In a busy scene 287 with lot of user generated content and avatars the volume easily 288 jumps up by a factor of five.' [13]. The size of the game itself 289 (often due to the high quality textures) and software updates is 290 impressive; often reaching beyond several 100 Mbytes. Utilizing 291 persistent storage and caching in combination with more aggressive 292 client-server interactions demands a different style of programming 293 and therefore also puts different constraints on the protocol design. 294 This might also stress the current Mbyte limits for Web storage. 296 Initial work to deal with more sophisticated graphics computation has 297 started already, as described in the recently published article [14] 298 about elevating JavaScript performance through offloading processing 299 to the GPU. As stated in the announcement of the Jetpack 0.5 contest 300 [15]: 'By giving webpages and add-ons easy access to the raw 301 processing power available on most computers, the range of abilities 302 that the web can have greatly increases.'. 304 3.2. Transport Protocol Limitations 306 In [16] Jonathan Rosenberg argued that the new waist of the Internet 307 hourglass is UDP and TCP, rather than IP as in the initial design. 308 Today, application protocol designers may, however, get the 309 impression that tunneling inside HTTP or even HTTPS is required to 310 get an application running in a large number of environments, 311 especially to reach a customer base that is connected to the Internet 312 through an enterprise network. Needless to say that more complex 313 tunneling leads to more complexity, the data transport adds overhead 314 and the initial environment sensing phase adds delays. This is 315 certainly true for the VoIP context where the payload data is 316 comparatively small to the overall header size (including the TCP/ 317 HTTP headers). The work on Interactive Connectivity Establishment 318 (ICE) [17] is relevant for the sensing phase and this functionality 319 may need to be replicated in the browser environment. For this 320 purpose it is more and more common to limit the number of individual 321 connections and to instead multiplex them over a single transport 322 connection. See, for example, SPDY [18] and developments in the VoIP 323 context [19]. Worse than inefficiency is that some real-time 324 applications do not behave well with the retransmission behavior of 325 TCP. For real-time voice and video applications, for virtual worlds, 326 and for many games it is acceptable to loose video and voice frames 327 from time to time without waiting for retransmission. 329 Adding the support for UDP to browsers again adds complexity, as the 330 experience with Voice over IP showed, particularly when the protocols 331 are not multiplexed together, so that it is necessary to identify 332 multiple working end-to-end paths for the traversal of Network 333 Address Translators (NATs) and firewalls. With the transition to 334 IPv6 the number of NATs is likely to increase. Furthermore, in many 335 cases it might be desired to perform route optimization for data 336 traffic and to exchange it directly between the two endpoints 337 whenever possible to reduce the financial costs and the added delay 338 of using an anchor point. For example, Google Talk only requires the 339 involvement of relays for 8% of their calls, as reported in [20] by 340 utilizing ICE. 342 It should be noted that audio and video streaming capabilities have 343 been available in the browser for a while with plug-in support. More 344 sophisticated audio support, such as tagging audio with x/y positions 345 for 3D audio, is not even possible with the Adobe Flash application 346 today. The challenge with video support in browsers is based on the 347 lack of universal support of a specific video codec. The lack of 348 hardware support is secondary although relevant for increased 349 performance and lower energy consumption. Naturally, supporting 350 different codecs makes the work of web developers and content 351 distributors difficult. 353 3.3. Security, Privacy, and Cryptographic Processing Limitations 355 Many protocol mechanisms have several built-in cryptographic 356 primitives and and the same capabilities must be available in the 357 browser in order to migrate applications that use these capabilities. 358 For example, JavaScript allows cryptographic operations to be 359 implemented (see [21] for a JavaScript AES or other cryptographic 360 functions [22] implementation) but access to hardware crypto- 361 processors, smart cards [23] or to key storages from JavaScript is 362 still at an early stage and, at the time of writing, not available as 363 a standardized JavaScript API. 365 The security model of JavaScript is different than the one offered by 366 Widgets [24] (available with different platforms/operating systems, 367 such as Mac OS X (via the dashboard), Windows 7, Opera, etc.) or 368 classical operating systems. JavaScript code does not declare what 369 operations it is intended to perform. Even with Widgets there is the 370 question of who verifies any of these privileges. It can hardly be 371 assumed that the end user will be bothered with such a responsibility 372 (due to the lack of his or her expertise. Furthermore, the semantic 373 of end-to-end security is challenged when the distinct communication 374 legs support protocols with different semantics, and dissimilar 375 encodings. Imagine a browser that sends location data encoded in 376 JSON [25], for example using [26], to a web server, which converts it 377 to XML, for example into the PIDF-LO format [27] to interoperate with 378 another application service provider. Consequently, this server then 379 uses XMPP to deliver notifications to its users, for example using 380 [28]. No two of these encodings offer the same privacy mechanisms 381 nor security properties. 383 The privacy implications of a heavily JavaScript-centered Web 384 environment are not yet well understood. For example, the SIP 385 privacy mechanisms, described in [29], [30], and [31]) rely to a 386 large degree on the end point to select independent RTP/SRTP relays, 387 and to obfuscate important header fields based on the context 388 provided by the user. One could argue that these standardized SIP 389 privacy extensions represent a community design even though those who 390 deploy ultimately make the final decisions about what policies to 391 use. When the executable code itself is provided by the application 392 service provider then the privacy functionality for data minimization 393 can change at any point in time with little possibility that the user 394 will notice. Only the application service provider makes decisions 395 about what functionality it desires without having to consult or 396 agree with anyone else. 398 3.4. Source Code Hiding Limitations 400 In many commercial environments it is not desirable to make source 401 code available to the public. With JavaScript the source code is 402 sent from the server to the browser and only compression and 403 obfuscation tools are available [32]. However, the only way to 404 protect code is to not expose it to observers, instead leaving the 405 important code on the server-side and have a minimal public 406 Javascript code segment use asynchronous message exchanges with the 407 server. 409 4. Recommendations 411 This section lists a few basic questions for protocol authors. We 412 hope that in answering these questions honestly a thought process 413 will be triggered that may lead you to re-consider your design before 414 starting the standardization effort that may not lead to successful 415 deployment. Note: We use the term 'protocol' below to refer to a 416 protocol extension, a single protocol, or to a complete protocol 417 suite, or an entire architecture. 419 1. Does your standardization effort fall priminarily into the 420 client-to-server interaction described in this document? If the 421 answer is "yes", is there a story how the involved stakeholders 422 can innovate at a high speed? 424 2. Are you attempting to offer functionality typically found at the 425 application layer at the lower layers? If so, have you carefully 426 investigated the cost vs. benefit tradeoff? 428 3. Does your protocol design involve other stakeholders whoes goals 429 are either not known or potentially not aligned with the goals of 430 your envisioned deployment, i.e. for successful deployment do you 431 require cooperation of stakeholders who may have disincentives 432 (or unclear incentives) to deploy your protocol? 434 4. When designing your protocol have you considered the Web 435 application environment? Do you understand Web development 436 yourself or do you have experts from the Web development 437 community involved in your work? 439 5. Does your protocol design offer the ability to carry payloads on 440 HTTP/HTTPS? 442 6. Why is the current Web framework unable to meet your application 443 requirements? Have you documented the reasons? 445 7. Have you implemented your protocol in a tyipcal Web development 446 programming language? Hands-on experience may help you to detect 447 problems with using your application design in a Web context in 448 early stages of the design. 450 8. Is your protocol deployed already? If not, who do you envision 451 to implement and deploy it? 453 5. Conclusions 455 This document aims to highlight recent trends in Web application 456 development with impact to Internet standardization. In a nutshell, 457 there is a certain class of applications for which the 458 standardization need is diminishing: chances are good that your 459 standardization work will not be relevant relevant in such an 460 environment. 462 A lot of this change is driven by mobile code distribution using 463 JavaScript executed on the end host (typically in the Web browser) 464 while server-to-server communication is not yet impacted. 466 We are, however, already seeing server-side JavaScript 467 implementations. NodeJS [33] is such an example that is built on 468 top of the V8 JavaScript engine. It runs multiple concurrent 469 JavaScript execution engines in one thread allowing to develop a 470 massively concurrent Web server in JavaScript, addressing a 471 typical pain point for server developers when implementing 472 distributed systems. As another example, CommonJS [34] defines 473 APIs that handle many common application needs, including those 474 that go beyond the usage in Web browsers (such as regular command 475 line programs). 477 Hence, just as the barriers for rapidly deploying code have dropped 478 on the client side; the server side will likely follow. 480 Even if there are challenges for standardization there are other 481 areas where work is needed: 483 o The development of of protocol mechanisms to support a larger 484 range of applications will have an important role to play in the 485 future. Examples of such efforts include the currenly ongoing 486 work on 'BiDirectional or Server-Initiated HTTP' in the HYBI 487 working group [35]. For future work on improving the performance 488 of the Web, for example [36], improvements in HTTP, or common 489 security functionality for the Web as standardized in the Web 490 Security working group [37]. 492 o In those areas where application islands want to interact with 493 larger eco-systems the need for cross-domain communication arises. 494 Often, this is done in a proprietary way but for larger 495 distributed systems and for common functions standardized 496 solutions are valuable. This can be observed today within the 497 VoIP environment, although much slower than expected, in the case 498 of Voice over IP peering but also in the Internet identity 499 management community under the umbrella of 'data portability' 500 [38]. As recent IETF work in this area the Open Authentication 501 Protocol (oauth) [39] working group could be referenced. OAuth 502 deals with more sophisticated security protocol interactions that 503 require multiple parties to participate in an interoperable way. 505 o Everyone knows that protocol design is hard regardless whether it 506 happens inside a standards developing organization, like the IETF 507 or W3C, or in some other less structured community. For Web 508 developers the standardization results are often only visible if 509 they appear in form of rich JavaScript libraries and development 510 frameworks, such as JQuery [40], the Prototype JavaScript 511 Framework [41], MooTools [42], YUI [43] and Narwahl [44]. In 512 order to have an impact in the Web community it is essential for 513 working groups participants to think about how to their protocols 514 can be deployed in a Web environment, for by making JavaScript 515 implementations available. The desire in the standards developing 516 community, including the IETF, to be programming language agnostic 517 and to avoid API standardization may need to be re-visited in 518 light of these recent developments. Extending JavaScript may, for 519 example, require new Document Object Models (DOMs) [45] and these 520 could serve as a valuable contribution. 522 Offering almost unlimited capabilities to JavaScript/HTML running in 523 a browser (in the same style as native applications run in an 524 operating system environment) will raise security concerns and will 525 consequently require countermeasures (such as 'deep inspection' and 526 blocking). This in turn will sparkle new ideas to bypass limitations 527 introduced, for example by utilizing new scripting languages with 528 different capabilities, etc. This is an arms race that the IT 529 industry is already able to observe already with deep packet 530 inspection firewalls and peer-to-peer networks during the last few 531 years. 533 It is unavoidable to get the impression that the hard problems, 534 particularly to security concerns regarding the distribution of new 535 software in whatever form, have not been tackled. Instead, the 536 browser becomes the new operating system, inherits the same 537 weaknesses and is likely to share the same fate. 539 6. Security Considerations 541 This document includes discussions related to security. 543 7. IANA Considerations 545 This document does not require actions by IANA. 547 8. Acknowledgements 549 The authors would like to thank Gonzalo Camarillo, Robert Sparks, 550 Alissa Cooper, Blaine Cook, Alexey Melnikov, Peter Saint-Andre, 551 Jonathan Rosenberg, Lisa Dusseault, Joshua Bell, John Hurliman, 552 Meadhbh Hamrick, Mark Nottingham, Anders Rundgren, Markus Isomaki, 553 Spencer Dawkins, Jan Kall, Jan Ignatius and Thomas Roessler. 555 An early version of this document was written to provide additional 556 background for the IETF#80 IAB technical plenary discussion in 557 Prague, March 2011. A number of persons provided their feedback, 558 including Dave Crocker, Pete Resnick, Leslie Daigle, Harald 559 Alvestrand, Jonathan Rosenberg, Dave Cridland, Nico Williams, Peter 560 Saint-Andre, Graham Klyne, Philip Hallam-Baker, Scott Brim, Henry 561 Sinnreich, Eliot Lear, Mark Nottingham, Paul Hoffman, Ted Hardie, 562 Cyrus Daboo, Claudio Allocchio, and Sam Hartman. We thank them for 563 the lively discussion. 565 9. Informative References 567 [1] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 568 STD 53, RFC 1939, May 1996. 570 [2] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 571 4rev1", RFC 3501, March 2003. 573 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 574 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 575 Session Initiation Protocol", RFC 3261, June 2002. 577 [4] Saint-Andre, P., Ed., "Extensible Messaging and Presence 578 Protocol (XMPP): Core", RFC 3920, October 2004. 580 [5] "W3C HTML Working Group Charter", Sep 2010. 582 [6] "V8 JavaScript Engine", Sep 2010. 584 [7] "V8 JavaScript Engine - Design Elements", Sep 2010. 586 [8] "WebGL", Sep 2010. 588 [9] "Quake II Google Web Toolkit (GWT) Port", Sep 2010. 590 [10] "The WebSocket API", Sep 2010. 592 [11] "Web Storage", Aug 2010. 594 [12] "Second Life", Sep 2010. 596 [13] "Private communication between Joshua Bell, Hannes Tschofenig 597 and Jon Peterson about browser performance limitations", 598 Aug 2010. 600 [14] "Elevating JavaScript Performance Through GPU Power", Jan 2010. 602 [15] "Jetpack 0.5 Contest: A Winner", Nov 2009. 604 [16] Rosenberg, J., "UDP and TCP as the New Waist of the Internet 605 Hourglass", draft-rosenberg-internet-waist-hourglass-00 (work 606 in progress), February 2008. 608 [17] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 609 Protocol for Network Address Translator (NAT) Traversal for 610 Offer/Answer Protocols", RFC 5245, April 2010. 612 [18] "SPDY: An experimental protocol for a faster web", Oct 2011. 614 [19] Westerlund, M., Burman, B., and C. Perkins, "RTP Multiplexing 615 Architecture", 616 draft-westerlund-avtcore-multiplex-architecture-01 (work in 617 progress), March 2012. 619 [20] "Google Talk for Developers: Important Concepts", Sep 2010. 621 [21] "JavaScript Implementation of AES Advanced Encryption Standard 622 in Counter Mode", Sep 2010. 624 [22] "crypto-js: JavaScript implementations of standard and secure 625 cryptographic algorithms", Sep 2010. 627 [23] "JavaScript Crypto", Sep 2010. 629 [24] "W3C Web Applications (WebApps) Working Group", Sep 2010. 631 [25] "JavaScript Object Notation (JSON)", Sep 2010. 633 [26] "The GeoJSON Format Specification", Jun 2008. 635 [27] Peterson, J., "A Presence-based GEOPRIV Location Object 636 Format", RFC 4119, December 2005. 638 [28] "XEP-0080: User Location", Sep 2009. 640 [29] Peterson, J., "A Privacy Mechanism for the Session Initiation 641 Protocol (SIP)", RFC 3323, November 2002. 643 [30] Munakata, M., Schubert, S., and T. Ohba, "Guidelines for Using 644 the Privacy Mechanism for SIP", RFC 5379, February 2010. 646 [31] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven 647 Privacy Mechanism for SIP", RFC 5767, April 2010. 649 [32] Crockford, D., "(JavaScript) Minification v Obfuscation", 650 Mar 2006. 652 [33] "nodeJS", Sep 2010. 654 [34] "CommonJS", Sep 2010. 656 [35] "IETF BiDirectional or Server-Initiated HTTP (hybi) Working 657 Group Charter", Mar 2011. 659 [36] "Let's make the web faster", Sep 2010. 661 [37] "IETF Web Security (websec) Working Group Charter", Mar 2011. 663 [38] "Data Portability Project: Share and Remix Data using Open 664 Standards", Sep 2010. 666 [39] "IETF Open Authentication Protocol (oauth) Working Group 667 Charter", Sep 2010. 669 [40] "jQuery: The Write Less, Do More, JavaScript Library", 670 Sep 2010. 672 [41] "Prototype JavaScript framework: Easy Ajax and DOM anipultion 673 for dynamic web applications", Sep 2010. 675 [42] "MooTools - a compact javascript framework", Sep 2010. 677 [43] "Yahoo! User Interface Library 3", Sep 2010. 679 [44] "Narwhal - A general purpose JavaScript platform", Sep 2010. 681 [45] "Document Object Model", Sep 2010. 683 [46] "W3C Workshop on Privacy for Advanced Web APIs", Jul 2010. 685 [47] "W3C Geolocation Working Group", Sep 2010. 687 [48] "Ajax (programming)", Sep 2010. 689 [49] "Device APIs and Policy Working Group", Sep 2010. 691 [50] Doty, N., Mulligan, D., and E. Wilde, "Privacy Issues of the 692 W3C Geolocation API, UC Berkeley School of Information Report 693 2010-038", Feb 2010. 695 [51] "Adobe Flash Player", Sep 2010. 697 [52] "Microsoft Silverlight", Sep 2010. 699 Authors' Addresses 701 Hannes Tschofenig 702 Nokia Siemens Networks 703 Linnoitustie 6 704 Espoo 02600 705 Finland 707 Phone: +358 (50) 4871445 708 Email: Hannes.Tschofenig@gmx.net 709 URI: http://www.tschofenig.priv.at 711 Bernard Aboba 712 Microsoft Corporation 713 One Microsoft Way 714 Redmond, WA 98052 715 US 717 Email: bernarda@microsoft.com 719 Jon Peterson 720 NeuStar, Inc. 721 1800 Sutter St Suite 570 722 Concord, CA 94520 723 US 725 Email: jon.peterson@neustar.biz 727 Danny McPherson 728 Verisign 729 US 731 Email: danny@tcb.net