idnits 2.17.00 (12 Aug 2021) /tmp/idnits22430/draft-tschofenig-post-standardization-00.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 (March 8, 2011) is 4091 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. '5') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. '7') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 5245 (ref. '20') (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: September 9, 2011 Microsoft Corporation 6 J. Peterson 7 NeuStar, Inc. 8 D. McPherson 9 Verisign 10 March 8, 2011 12 Trends in Web Applications and the Implications on Standardization 13 draft-tschofenig-post-standardization-00.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 post-standardization environment. In this 38 environment, there is of course still a role for the IETF to play: 39 existing working groups like HyBi and OAuth are examples of areas 40 where standards work is still required to support this application 41 development paradigm. Collectively, we need to identify areas where 42 the standardization is unlikely to be relevant in the future, and 43 focus our efforts on those areas where our application designs will 44 remain impactful. 46 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on September 9, 2011. 63 Copyright Notice 65 Copyright (c) 2011 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Impact for the Standardization Community . . . . . . . . . . . 6 82 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.1. Performance Limitations . . . . . . . . . . . . . . . . . 8 84 3.2. Transport Protocol Limitations . . . . . . . . . . . . . . 9 85 3.3. Security, Privacy, and Cryptographic Processing 86 Limitations . . . . . . . . . . . . . . . . . . . . . . . 10 87 3.4. Source Code Hiding Limitations . . . . . . . . . . . . . . 11 88 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 89 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 93 9. Informative References . . . . . . . . . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 The generic nature of the personal computer has enabled the 99 information technology community to develop applications that move 100 functionality available in the offline world into the digital world. 101 This flexibility has introduced security issues, since it is 102 difficult for end users to judge the trustworthiness of downloaded 103 programs in any reasonable way. Consequently, many users are very 104 suspicious about any download they are asked to accept. However, an 105 important aspect for ensuring speed of innovation is to reach 106 widespread deployment of a new technology, which to a large extent 107 requires the ability to run new code on end devices. With operating 108 system updates happening less frequently and the acceptance for 109 software downloads decreasing the browser with its limited 110 capabilities was seen by many as an ideal platform for running code 111 that could not cause harm. In particular, JavaScript has found 112 widespread deployment in browsers 'under the radar' of many companies 113 and is now referred as the 'assembly language of the Internet'. 114 JavaScript was initially perceived as being quite limited in 115 functionality. This perception has changed over the last couple of 116 years when it became the scripting language implemented in the 117 majority of browsers. 119 For application developers writing code running on Web servers as 120 well as for applications that are downloaded to the end device the 121 desire was always to develop the application once without having to 122 consider all the different runtimes (operating systems or browsers). 123 Now, with the PC and the cellular phone segments getting increasingly 124 blurry this desire is stronger than ever considering the increased 125 number of obstacles that have to be dealt with. For example, it is 126 highly unlikely that an application will work on various different 127 devices even if all the devices were produced by a single mobile 128 phone vendor. As a consequence, writing cross-platform applications 129 that can be deployed on a variety of target devices has always been 130 difficult. Getting users to download new applications, and to 131 install software updates also leaves software developers in a 132 difficult situation. 134 How can software be developed so that it can (1) be updated instantly 135 when a new version becomes available, (2) be used across a wide range 136 of devices, and (3) be as powerful as regular desktop applications? 137 This sounds almost impossible but with the increased capabilities of 138 Web browsers and in particular JavaScript it seems that the Internet 139 community has gotten a couple of steps closer to achieve this goal. 141 User experience has changed largely due to global coverage of high 142 speed cellular networks, a range of new end devices (such as 143 netbooks, smart phones, and Internet tablets), lower costs for 144 Internet access (often bundled with flatrate tariffs), and the shift 145 of the industry towards moving storage and computation into the 146 network. The younger generation of Internet users today has a very 147 different Internet experience than users 10 years ago. They just 148 click to a Web page of an application service provider and let the 149 browser execute JavaScript without any need to install new 150 applications. A positive side effect is that lower configuration 151 requirements are imposed on the user. 153 Today, many of the features previously available only with dedicated 154 browser plugins, such as Adobe Flash [1] and Microsoft's Silverlight 155 [2], will become widely available as standardized versions with HTML5 156 [3]. The expectation therefore is that new versions of browsers will 157 be shipped with these increased functionalities, thereby empowering 158 Web application developers. 160 This document focuses on the impact for the standardization 161 community, and to provide some recommendations. 163 2. Impact for the Standardization Community 165 In the application area communication protocols often follow the 166 pattern where an end host utilizes some application service provider 167 for communication setup and sometimes also for message routing 168 towards the other communication end point. In this article we call 169 this communication legs, or legs for short. This is true for the 170 Post Office Protocol (POP) [4] and for the Internet Message Access 171 Protocol (IMAP) [5], as well as for real-time communication protocols 172 like the Session Initiation Protocol (SIP) [6] and the Extensible 173 Messaging and Presence Protocol (XMPP) [7]. The same can be observed 174 also at lower layers in the protocol stack, such as in various 175 tunneling and mobility protocols where the 'rendezvous service' 176 provides the initial contact point for communication (and may even 177 remain on the end-to-end communication path for the duration of the 178 communication). Standardization efforts often assume a model where 179 all legs should or need to be standardized, namely the end host to 180 application service provider and the cross domain interaction. 182 While many standardization efforts in the IETF have considered the 183 possibility for using proprietary protocols along the end host to 184 application service provider leg, this has usually been considered as 185 exception or a transition case. With few exceptions it was assumed 186 that the desired end state is to move from a proprietary protocol to 187 the standardized alternative in the long run, which allows client 188 software vendors to interact with all forms of application service 189 providers. Such an approach increases the need for standardization 190 considerably and requires far more interoperable network elements to 191 exist. This attitude is not particularly surprising given that many 192 standardization participants in the real-time communication area look 193 back to a regime that exactly follows a highly standardised eco- 194 system, namely the telecommunication business. 196 Email functionality offered by IMAP4 and POP3 is already being 197 replaced by an Ajax-based browser experience. Asynchronous 198 JavaScript and XML (Ajax) [8] is usually referred to as a combination 199 of tools that allows a developer to retrieve data from a Web server 200 in real-time. Interactions demanding real-time communication, such 201 as instant messaging and chat, are possible without any additional 202 plug-ins. Voice over IP and video support that requires access to 203 microphone and cameras is available in browsers but still requires 204 plug-in support today. 206 Allowing application developers to write code that is downloaded to 207 the end host when a user initially accesses the application service 208 is attractive and allows for fast innovation cycles. Within the IETF 209 the areas that are most impacted by this trend in the Web application 210 domain are quite naturally the 'Applications Area' as well as the 211 'Real-Time Applications and Infrastructure Area'. Implications for 212 security and transport layer mechanisms are to be expected as this 213 possibility becomes a reality. 215 Inevitably, the functions of many real-time communications protocols 216 will migrate to web browsers, for the simple reason that they match 217 the modalities of web communication: the Session Initiation Protocol, 218 for example, is essentially a rendezvous protocol implemented over an 219 interactive messaging layer, and the flows of that messaging layer 220 are easily replicated by web sockets. The challenge, however, is 221 that real-time communications protocols do not map onto the client/ 222 server paradigm as easily as POP3 or IMAP. Email relies on client/ 223 server protocols that allow users to interact with their local 224 domain, but uses SMTP, a separate interdomain protocol, to send mail 225 between domains. Similarly, real-time communications protocols tend 226 to have a client/server component that interacts with the local 227 domain and a server-to-server component n in the case of SIP, the 228 same protocol serves both functions. While it is clear that the web 229 can subsume the client/server function, could mail delivery similarly 230 move to some sort of interdomain server-to-server variant of HTTP? 231 Thusfar, that has prevailed in the mail world. When examining real- 232 time communications protocols, one must similarly ask what protocols 233 will be used to cross domain boundaries outside of the client/server 234 realm, and what are the implications for security, capability 235 negotiation, and similar core protocol functions when one introduces 236 interworking at the domain boundary. 238 3. Challenges 240 Even though a number of new building blocks are being made available 241 at rapid speed, such as HTML5 and various JavaScript extensions, 242 there are still a number of limitations in today's browser 243 environment that prevent a broad range of applications from being 244 executed in the browser. We list a couple of those challenges, some 245 of which will be resolved in a year or two, while others will remain 246 a challenge for a long time. 248 3.1. Performance Limitations 250 JavaScript was not designed with high-performance in mind. Indeed, 251 over many years very little attention was paid to boost the 252 performance until recently when the Google JavaScript engine V8 [9] 253 started to compile JavaScript code directly into machine code when it 254 is first executed. More details about the design can be found at 255 [10]. 257 A more serious limitation is the graphics capabilities in browsers. 258 Efforts are under way to enhance the API capabilities, for example 259 WebGL [11] bringing 3D graphics to the browser with features similar 260 to OpenGL ES 2.0 that can be used in HTML5 canvas elements but 261 expensive computations on the end host need to migrate from the 262 Central Processing Unit (CPU) to the Graphics Processing Unit (GPU) 263 for proper performance. Simple 3D games (similar to the recently 264 demonstrated Quake II port to HTML5 [12] utilizing JavaScript, the 265 WebSocket API [13] and the Web Storage API [14]) can now be 266 implemented but state-of-the-art games and virtual worlds are out of 267 reach. The problem is with the number of polygons that many games 268 and virtual worlds need to process and display. Games, like Quake, 269 use a limited number of textures, and the complexity of the scene 270 graph is small. 272 In comparison to virtual worlds where the content is put together by 273 users, in many games the playing field is carefully designed by 274 experts. This has implications for the complexity of the scene 275 graph. On the other hand, most virtual worlds do not rely on rapid 276 communication updates in the same way that many action and tactic 277 games do. Joshua Bell illustrated this with an example of 'a quiet 278 scene with a single user running around in SecondLife [15]. A 279 teleport to a region can easily have a scene graph with 2000 nodes, a 280 couple hundred 3D textures, 4000 vertexes, and 20 MByte of vertex 281 data. This corresponds to the maximum a graphics developer would 282 typically like to have in a state-of-the-art game. In a busy scene 283 with lot of user generated content and avatars the volume easily 284 jumps up by a factor of five.' [16]. The size of the game itself 285 (often due to the high quality textures) and software updates is 286 impressive; often reaching beyond several 100 Mbytes. Utilizing 287 persistent storage and caching in combination with more aggressive 288 client-server interactions demands a different style of programming 289 and therefore also puts different constraints on the protocol design. 290 This might also stress the current Mbyte limits for Web storage. 292 Initial work to deal with more sophisticated graphics computation has 293 started already, as described in the recently published article [17] 294 about elevating JavaScript performance through offloading processing 295 to the GPU. As stated in the announcement of the Jetpack 0.5 contest 296 [18]: 'By giving webpages and add-ons easy access to the raw 297 processing power available on most computers, the range of abilities 298 that the web can have greatly increases.'. 300 3.2. Transport Protocol Limitations 302 In [19] Jonathan Rosenberg argued that the new waist of the Internet 303 hourglass is UDP and TCP, rather than IP as in the initial design. 304 Today, application protocol designers may, however, get the 305 impression that tunneling inside HTTP or even HTTPS is required to 306 get an application running in a large number of environments, 307 especially to reach a customer base that is connected to the Internet 308 through an enterprise network. Needless to say that more complex 309 tunneling leads to more complexity, the data transport adds overhead 310 and the initial environment sensing phase adds delays. This is 311 certainly true for the VoIP context where the payload data is 312 comparatively small to the overall header size (including the TCP/ 313 HTTP headers). The work on Interactive Connectivity Establishment 314 (ICE) [20] is relevant for the sensing phase and this functionality 315 may need to be replicated in the browser environment. Worse than 316 inefficiency is that some real-time applications do not behave well 317 with the retransmission behavior of TCP. For real-time voice and 318 video applications, for virtual worlds, and for many games it is 319 acceptable to loose video and voice frames from time to time without 320 waiting for retransmission. 322 Adding the support for UDP to browsers again adds complexity, as the 323 experience with Voice over IP showed, particularly when the protocols 324 are not multiplexed together, so that it is necessary to identify 325 multiple working end-to-end paths for the traversal of Network 326 Address Translators (NATs) and firewalls. With the increased IPv6 327 usage the number of NATs is likely to increase during a long 328 transition period. Furthermore, in many cases it might be desired to 329 perform route optimization for data traffic and to exchange it 330 directly between the two endpoints whenever possible to reduce the 331 financial costs and the added delay of using an anchor point. For 332 example, Google Talk only requires the involvement of relays for 8% 333 of their calls, as reported in [21] by utilizing ICE. 335 It should be noted that audio and video streaming capabilities have 336 been available in the browser for a while with plug-in support. More 337 sophisticated audio support, such as tagging audio with x/y positions 338 for 3D audio, is not even possible with the Adobe Flash application 339 today. The challenge with video support in browsers is based on the 340 lack of universal support of a specific video codec. The lack of 341 hardware support is secondary although relevant for increased 342 performance and lower energy consumption. Naturally, supporting 343 different codecs makes the work of web developers and content 344 distributors difficult. 346 3.3. Security, Privacy, and Cryptographic Processing Limitations 348 Many protocol mechanisms have several built-in cryptographic 349 primitives and and the same capabilities must be available in the 350 browser in order to move migrate applications that use these 351 capabilities. For example, JavaScript allows cryptographic 352 operations to be implemented (see [22] for a JavaScript AES or other 353 cryptographic functions [23] implementation) but access to hardware 354 crypto-processors, smart cards [24] or to key storages from 355 JavaScript is still at an early stage. The authors are also not 356 aware of a shared authorization policy store that allows a number of 357 websites to benefit from a central user preferences store, such as 358 settings regarding the distribution of location information. It is 359 quite likely that users might prefer to control their privacy 360 settings in one location, given a specific context, and have those 361 settings applied to all running Web applications to avoid private 362 information leakage. 364 The security model of JavaScript is rather weak in comparison to 365 those of Widgets [25] (available with different platforms/operating 366 systems, such as Mac OS X (via the dashboard), Windows 7, Opera, 367 etc.). JavaScript code does not declare what operations it is 368 intended to perform. Even with Widgets the question is who will 369 verify any of these privileges. It can hardly be assumed that the 370 end user will be bothered with such a responsibility (due to the lack 371 of his or her expertise in making reasonable decisions). 372 Furthermore, the semantic of end-to-end security is challenged when 373 the distinct communication legs support protocols with different 374 semantics, and dissimilar encodings. Imagine a browser that sends 375 location data encoded in JSON [26], for example using [27], to a web 376 server, which converts it to XML, for example into the PIDF-LO format 377 [28] to interoperate with another application service provider. 378 Consequently, this server then uses XMPP to deliver notifications to 379 its users, for example using [29]. No two of these encodings offer 380 the same privacy mechanisms nor security properties. 382 From the work in the W3C Geolocation [30] and the W3C Device API and 383 Policy [31] working group it was observable in recent years that 384 attempts to incorporate privacy mechanisms beyond notice and choice 385 are hard to accomplish with community consensus. While many of these 386 user-interface indications barely work on a PC with a large screen, 387 keyboard and mouse, it remains to be seen how successful they will be 388 on devices with display and input constraints. For a more detailed 389 discussion of privacy challenges related to initial implementations 390 of the Geolocation API see [32].. Further privacy related 391 information can be found with the recent 'W3C Workshop on Privacy for 392 Advanced Web APIs' [33]. 394 The privacy implications of a heavily JavaScript-centered Web 395 environment are not yet well understood. For example, the SIP 396 privacy mechanisms, described in [34], [35], and [36]) rely to a 397 large degree on the end point to select independent RTP/SRTP relays, 398 and to obfuscate important header fields based on the context 399 provided by the user. When the executable code itself is provided by 400 the application service provider (rather than an independent software 401 client vendor) then the privacy functionality for data minimization 402 can change at any point in time with little possibility that the user 403 will notice. 405 3.4. Source Code Hiding Limitations 407 In many commercial environments it is not desirable to make source 408 code available to the public. With JavaScript the source code is 409 sent from the server to the browser and only compression and 410 obfuscation tools are available [37]. However, the only way to 411 protect code is to not expose it to observers, instead leaving the 412 important code on the server-side and have a minimal public 413 Javascript code segment use asynchronous message exchanges with the 414 server. Developers in the past rarely had to worry about such a 415 design criteria; how it will impact protocol design? 417 4. Recommendations 419 This section lists a couple of questions for protocol authors. We 420 hope that in answering these questions honestly a thought process 421 will be triggered that may lead you to re-consider your design before 422 starting a year-long standardization effort that may not lead to 423 successful deployment. Note: We use the term 'protocol' below to 424 refer to a protocol extension, a protocol, or to a complete protocol 425 suite, or an entire architecture. 427 1. Does your standardization effort fall priminarily into the 428 client-to-server interaction described in this document? If the 429 answer is "yes", is there a story how the involved stakeholders 430 can innovate at the same speed as in the architecture described 431 in this document? If you do not have a credible answer to the 432 latter question you will run into trouble. If your answer is 433 "no", then you may skip the rest of the questions. Your protocol 434 may, for example, focus on backend server interactions or dealing 435 with lower-layer interactions. 437 2. Are you attempting to offer functionality typically found at the 438 application layer at the lower layers (such as network layer)? 439 If so, have you carefully investigated the cost vs. benefit 440 tradeoff? 442 3. Does your protocol design involve stakeholders who are not 443 aligned with the goals of your envisioned deployment, i.e. for 444 successful deployment do you require cooperation of stakeholders 445 who may have disincentives (or unclear incentives) to deploy your 446 protocol? Are there other architectural variants that allow 447 innovation to happen at a higher speed? 449 4. When designing your protocol have you considered the Web 450 application environment? Do you understand Web development or do 451 you have experts from the Web development community involved in 452 your work? If the answer to this question is "no" then might 453 miss some important concepts. 455 5. Are there ways for your protocol to be carried on top of HTTP/ 456 HTTPS? If the answer is "no", do you understand that a certain 457 user class will not be able to use your protocol? 459 6. Are your protocol requirements not met by the current Web 460 framework? (For the limits of the current Web framework see 461 Section 3?) If the answer is "no" then you may have a few years 462 time before the functionality is available even thought plug-ins 463 would allow your desired functionality to be deployed today 464 already. Since your requirements may be special already you are 465 targeting a small community. Is a several year standardization 466 effort justified to satisfy the need of that community or are 467 there other ways to serve your user base? 469 7. Have you implemented your protocol in a tyipcal Web development 470 programming langage? If the answer is "no" then you might not 471 know whether there are challenges with the usage in a Web 472 context. You may be using, for example, an encoding that is 473 foreign to Web application developers or you may demand 474 functionality that requires browser extensions. 476 8. Is your protocol deployed already? If the answer is "no", who is 477 going to deploy it? Particularly interesting is the case when 478 none of the standardization participants have a substantial 479 impact on deployment. In that case you are hoping that someone 480 else finds it useful and you could as well publish an academic 481 paper instead. 483 5. Conclusions 485 This document to highlight recent trends in Web application 486 communities with impact to Internet standardization. In a nutshell, 487 there is a certain class of applications for which the 488 standardization need is diminishing: chances are good that your 489 standardization work will not be relevant relevant in such an 490 environment. 492 A lot of this change is driven by JavaScript and HTML5 executed on 493 the end host (typically in the Web browser) while server-to-server 494 communication is not yet impacted. We are, however, already seeing 495 server-side JavaScript implementations. NodeJS [38] is such an 496 example that is built on top of the V8 JavaScript engine. It runs 497 multiple concurrent JavaScript execution engines in one thread 498 allowing to develop a massively concurrent Web server in JavaScript, 499 addressing a typical pain point for server developers when 500 implementing distributed systems. As another example, CommonJS [39] 501 defines APIs that handle many common application needs, including 502 those that go beyond the usage in Web browsers (such as regular 503 command line programs). 505 Hence, just as the barriers for rapidly deploying code have dropped 506 on the client side; the server side will likely follow. 508 Even if there are challenges for standardization there are other 509 areas where work is needed: 511 o The development of of protocol mechanisms to support a larger 512 range of applications will have an important role to play in the 513 future. Examples of such efforts include the currenly ongoing 514 work on 'BiDirectional or Server-Initiated HTTP' in the HYBI 515 working group [40]. For future work on improving the performance 516 of the Web, for example [41], improvements in HTTP, or common 517 security functionality for the Web as standardized in the Web 518 Security working group [42]. 520 o In those areas where application islands want to interact with 521 larger eco-systems the need for cross-domain communication arises. 522 Often, this is done in a proprietary way but for larger 523 distributed systems and for common functions standardized 524 solutions are valuable. This can be observed today within the 525 VoIP environment, although much slower than expected, in the case 526 of Voice over IP peering but also in the Internet identity 527 management community under the umbrella of 'data portability' 528 [43]. As recent IETF work in this area the Open Authentication 529 Protocol (oauth) [44] working group could be referenced. OAuth 530 deals with more sophisticated security protocol interactions that 531 require multiple parties to participate in an interoperable way. 533 o Everyone knows that protocol design is hard regardless whether it 534 happens inside a standards developing organization, like the IETF 535 or W3C, or in some other less structured community. For Web 536 developers the standardization results are often only visible if 537 they appear in form of rich JavaScript libraries and development 538 frameworks, such as JQuery [45], the Prototype JavaScript 539 Framework [46], MooTools [47], YUI [48] and Narwahl [49]. In 540 order to have an impact in the Web community it is essential for 541 working groups participants to think about how to their protocols 542 can be deployed in a Web environment, for by making JavaScript 543 implementations available. The desire in the standards developing 544 community, including the IETF, to be programming language agnostic 545 and to avoid API standardization may need to be re-visited in 546 light of these recent developments. Extending JavaScript may, for 547 example, require new Document Object Models (DOMs) [50] and these 548 could serve as a valuable contribution. 550 Offering almost unlimited capabilities to JavaScript/HTML running in 551 a browser (in the same style as native applications run in an 552 operating system environment) will raise security concerns and will 553 consequently require countermeasures (such as 'deep inspection' and 554 blocking). This in turn will sparkle new ideas to bypass limitations 555 introduced, for example by utilizing new scripting languages with 556 different capabilities, etc. This is an arms race that the IT 557 industry is already able to observe already with deep packet 558 inspection firewalls and peer-to-peer networks during the last few 559 years. 561 It is unavoidable to get the impression that the hard problems, 562 particularly to security concerns regarding the distribution of new 563 software in whatever form, have not been tackled. Instead, the 564 browser becomes the new operating system, inherits the same 565 weaknesses and is likely to share the same fate. 567 6. Security Considerations 569 This document includes discussions related to security. 571 7. IANA Considerations 573 This document does not require actions by IANA. 575 8. Acknowledgements 577 The authors would like to thank Gonzalo Camarillo, Robert Sparks, 578 Alissa Cooper, Blaine Cook, Alexey Melnikov, Peter Saint-Andre, 579 Jonathan Rosenberg, Lisa Dusseault, Joshua Bell, John Hurliman, 580 Meadhbh Hamrick, Mark Nottingham, Anders Rundgren, Markus Isom[/ 581 1000]ki, Spencer Dawkins, Jan Kall, Jan Ignatius and Thomas Roessler. 583 9. Informative References 585 [1] "Adobe Flash Player", Sep 2010. 587 [2] "Microsoft Silverlight", Sep 2010. 589 [3] "W3C HTML Working Group Charter", Sep 2010. 591 [4] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 592 STD 53, RFC 1939, May 1996. 594 [5] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 595 4rev1", RFC 3501, March 2003. 597 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 598 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 599 Session Initiation Protocol", RFC 3261, June 2002. 601 [7] Saint-Andre, P., Ed., "Extensible Messaging and Presence 602 Protocol (XMPP): Core", RFC 3920, October 2004. 604 [8] "Ajax (programming)", Sep 2010. 606 [9] "V8 JavaScript Engine", Sep 2010. 608 [10] "V8 JavaScript Engine - Design Elements", Sep 2010. 610 [11] "WebGL", Sep 2010. 612 [12] "Quake II Google Web Toolkit (GWT) Port", Sep 2010. 614 [13] "The WebSocket API", Sep 2010. 616 [14] "Web Storage", Aug 2010. 618 [15] "Second Life", Sep 2010. 620 [16] "Private communication between Joshua Bell, Hannes Tschofenig 621 and Jon Peterson about browser performance limitations", 622 Aug 2010. 624 [17] "Elevating JavaScript Performance Through GPU Power", Jan 2010. 626 [18] "Jetpack 0.5 Contest: A Winner", Nov 2009. 628 [19] Rosenberg, J., "UDP and TCP as the New Waist of the Internet 629 Hourglass", draft-rosenberg-internet-waist-hourglass-00 (work 630 in progress), February 2008. 632 [20] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 633 Protocol for Network Address Translator (NAT) Traversal for 634 Offer/Answer Protocols", RFC 5245, April 2010. 636 [21] "Google Talk for Developers: Important Concepts", Sep 2010. 638 [22] "JavaScript Implementation of AES Advanced Encryption Standard 639 in Counter Mode", Sep 2010. 641 [23] "crypto-js: JavaScript implementations of standard and secure 642 cryptographic algorithms", Sep 2010. 644 [24] "JavaScript Crypto", Sep 2010. 646 [25] "W3C Web Applications (WebApps) Working Group", Sep 2010. 648 [26] "JavaScript Object Notation (JSON)", Sep 2010. 650 [27] "The GeoJSON Format Specification", Jun 2008. 652 [28] Peterson, J., "A Presence-based GEOPRIV Location Object 653 Format", RFC 4119, December 2005. 655 [29] "XEP-0080: User Location", Sep 2009. 657 [30] "W3C Geolocation Working Group", Sep 2010. 659 [31] "Device APIs and Policy Working Group", Sep 2010. 661 [32] Doty, N., Mulligan, D., and E. Wilde, "Privacy Issues of the 662 W3C Geolocation API, UC Berkeley School of Information Report 663 2010-038", Feb 2010. 665 [33] "W3C Workshop on Privacy for Advanced Web APIs", Jul 2010. 667 [34] Peterson, J., "A Privacy Mechanism for the Session Initiation 668 Protocol (SIP)", RFC 3323, November 2002. 670 [35] Munakata, M., Schubert, S., and T. Ohba, "Guidelines for Using 671 the Privacy Mechanism for SIP", RFC 5379, February 2010. 673 [36] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven 674 Privacy Mechanism for SIP", RFC 5767, April 2010. 676 [37] Crockford, D., "(JavaScript) Minification v Obfuscation", 677 Mar 2006. 679 [38] "nodeJS", Sep 2010. 681 [39] "CommonJS", Sep 2010. 683 [40] "IETF BiDirectional or Server-Initiated HTTP (hybi) Working 684 Group Charter", Mar 2011. 686 [41] "Let's make the web faster", Sep 2010. 688 [42] "IETF Web Security (websec) Working Group Charter", Mar 2011. 690 [43] "Data Portability Project: Share and Remix Data using Open 691 Standards", Sep 2010. 693 [44] "IETF Open Authentication Protocol (oauth) Working Group 694 Charter", Sep 2010. 696 [45] "jQuery: The Write Less, Do More, JavaScript Library", 697 Sep 2010. 699 [46] "Prototype JavaScript framework: Easy Ajax and DOM anipultion 700 for dynamic web applications", Sep 2010. 702 [47] "MooTools - a compact javascript framework", Sep 2010. 704 [48] "Yahoo! User Interface Library 3", Sep 2010. 706 [49] "Narwhal - A general purpose JavaScript platform", Sep 2010. 708 [50] "Document Object Model", Sep 2010. 710 Authors' Addresses 712 Hannes Tschofenig 713 Nokia Siemens Networks 714 Linnoitustie 6 715 Espoo 02600 716 Finland 718 Phone: +358 (50) 4871445 719 Email: Hannes.Tschofenig@gmx.net 720 URI: http://www.tschofenig.priv.at 722 Bernard Aboba 723 Microsoft Corporation 724 One Microsoft Way 725 Redmond, WA 98052 726 US 728 Email: bernarda@microsoft.com 730 Jon Peterson 731 NeuStar, Inc. 732 1800 Sutter St Suite 570 733 Concord, CA 94520 734 US 736 Email: jon.peterson@neustar.biz 738 Danny McPherson 739 Verisign 740 US 742 Email: danny@tcb.net