This is a never finished Internet Draft with my thoughts about the HTTP/2.0 protocol. :: Network Working Group P. Kamp Internet-Draft Den Andensidste Viking Intended status: Informational April 2, 2012 Expires: October 4, 2012 An architectural vision for HTTP/2.0 draft-phk-http-architecture-httpbis-01 Abstract The HTTP protocol is undoubtedly one of the biggest successes of the Internet family of protocols, and the world has changed a lot under the architectural assumptions it was built on. Before rushing into standardization of HTTP/2.0 based on past experience and grievances with HTTP/1.1, we should examine what the architecture underlying the next 10-20 years of web-browsing must do for us. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 4, 2012. Copyright Notice Copyright (C) The Internet Society (2012). All Rights Reserved. Kamp Expires October 4, 2012 [Page 1] Internet-Draft An architectural vision for HTTP/2.0 April 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. When I'm sixty-four: What are we looking at . . . . . . . . . 4 3. New Kid on the Block: HTTP routers . . . . . . . . . . . . . . 5 3.1. Taking care of business: What a HTTP router does . . . . . 5 3.2. I got 99 problems: Trouble for HTTP routers . . . . . . . 6 3.3. When I wish upon a star: What we can do for HTTP routers . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Everybody's Got Something to Hide Except Me and My Monkey . . 8 5. Return to sender: The client-server model . . . . . . . . . . 10 6. Route sixty-six: Getting there . . . . . . . . . . . . . . . . 11 7. Little Deuce Coupe: Smarter rides than TCP . . . . . . . . . . 12 8. Counting the Cattle: A more efficient protocol . . . . . . . . 13 9. Under Wraps: What to protect . . . . . . . . . . . . . . . . . 15 9.1. The envelope . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. The metadata . . . . . . . . . . . . . . . . . . . . . . . 15 9.3. The body . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Headbanging The Piano: Bringing it all together. . . . . . . . 17 10.1. Container level . . . . . . . . . . . . . . . . . . . . . 17 10.2. Message Level . . . . . . . . . . . . . . . . . . . . . . 18 10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Kamp Expires October 4, 2012 [Page 2] Internet-Draft An architectural vision for HTTP/2.0 April 2012 1. Introduction HTTP is not what it used to be, and although the protocol has scaled remarkably well, the current level of performance seems insufficient for even the very short term growth of the internet. Efforts have been made to find optimizations and improvements But usually in a frame of mind of incremental improvement, rather than architectual review. This document is a loose architectural sketch of how HTTP/2.0 could look, more or less based on a single persons random sketchings and ideas. The intention is not that the bits and pieces of this document should be polished and ratified as a protocol, but to present some ideas and observations for discussion. Kamp Expires October 4, 2012 [Page 3] Internet-Draft An architectural vision for HTTP/2.0 April 2012 2. When I'm sixty-four: What are we looking at Jim Gettys long time ago warned the X11 project that "The only thing worse than generalizing from one example is generalizing from no examples at all." Far too many standardization efforts neglegt this sage wisdom. But in one area we will have to extrapolate from just one example: What is the probably lifetime of HTTP/2.0 going to be ? HTTP/1.1 was first standardized in 1997 and there is no credible reason to belive we will get rid of it for at least another five years, so assuming and aiming for a 20 year lifetime of HTTP/2.0 is reasonable. What computing will look like in 20 years time is anyones guess, but we do have some clues to the near term developments: Computers won't run faster. The current solid-state and process technologies have hit a clock speed barrier around 3-5 GHz which shows no signs of being radically breached in the near term. What we see instead of higher clock speed, is inceasingly imperfect parallelism (NUMA), increasingly complex instruction sets and attempts to offload processing to dedicated hardware. For instance most network cards already have support for calculating TCP/IP checksums. With respect to bandwidth, there does not seem to be any similar restrictions, although the technological problems of extending beyond 10 and 40 Gbit/s are not trivial. I think it is fully reasonable to expect transmission media with 1 Tbit/s capacity in the next 20 years. I think that given HTTP's central role in mass communication, being able to deal with HTTP/2.0 at that speed, either in hardware or software is a goal in its own right. Kamp Expires October 4, 2012 [Page 4] Internet-Draft An architectural vision for HTTP/2.0 April 2012 3. New Kid on the Block: HTTP routers Probably the most radical change in the HTTP ecosystem is the appearance of a new role in addition to the client, proxy & server triad. For reasons of scalability and redundancy, most larger websites today deploy light-weight proxies with load-balancing and load-directing facilities. In terms of RFC standardization, these boxes are clearly proxies, and as such they have been treated until now. But these boxes occupy a very special role, because they sit where the traffic is most densely concentrated, and they usually take almost no notice of the semantic meaning of the HTTP messages they handle. I propose we introduce a new role for these boxes, and name them "HTTP routers", since their role is much closer to that of a packet router, than of a webserver. 3.1. Taking care of business: What a HTTP router does In a typical large-ish web-site, the HTTP router is responsible for directing incoming HTTP requests to HTTP servers based on simple criteria, and to direct the reponse from the HTTP server back to the client. Because of this central position in the HTTP message path the HTTP router is where the traffic concentration is highest, and where both intentional and malicious traffic must be handled somehow. The HTTP router seldom terminates the HTTP path in any meaningful way, it simply picks it off one TCP connection and places it on another, pretty much like a packet router will shuffle packets between its interfaces. A very common routing criteria is "does the HTTP server work ?" With two or more equally capable HTTP servers to choose from, the HTTP router will route requests only to those HTTP servers which seem to actually work. This simple routing policy allows HTTP servers to crash, to be taken down for maintenance or to be moved, without taking the entire website offline as a result. Other more involved criteria might be to send requests for images and Kamp Expires October 4, 2012 [Page 5] Internet-Draft An architectural vision for HTTP/2.0 April 2012 other static elements to one set of servers and requests relating to dynamic content to another set of servers, based on pattern-matching the URI. 3.2. I got 99 problems: Trouble for HTTP routers HTTP routers run into some deficiences of the HTTP/1.1 definition, which seriously cramp their style. Some of these problems are at a functional level and some are purely performance. An example of a functional problem is the lack of a session concept in HTTP. A that a very common routing criteria is session-stability. The clients first request is routed to a web-server using some random criteria, but subsequent requests from that same client should be routed to the same backend, even if that criteria changes, because the client and/or backend maintains state, for instance the contents of a shopping basket, of relevance to the "session". Most often this session concept is simulated with Cookies, but amongst other sideeffects, this makes objects which would otherwise be perfectly cacheable impossible to cache in shared proxies. In the performance class of problems, the most prominent is the indeterminacy of HTTP/1.1 message length: Only once we encouter the end do we know where to find it. Implementation wise, things would be so much easier, if the length were sent up front, so that memory allocation and socket-API paramters can be chosen intelligently. 3.3. When I wish upon a star: What we can do for HTTP routers If a HTTP/2.0 router should be able to deal with 1Tbit/s of traffic, we need to avoid complicated encodings or transformations for the fields it must examine. We should probably adopt how other routable protocols have a clear distinction between the "envelope" and "the contents" and designate a small subset of the HTTP message attributes as part of the envelope and make them convenient for HTTP routers to work with. Given how almost universal the "session" concept on the Internet we should add it to the HTTP/2.0 standard, and make it available for HTTP routers to use as a "flow-label" for routing. At the byte-serialization level, we should also try to the extent possible, to use prefix coding to make available information about what will happen next. For instance HTTP messages should state Kamp Expires October 4, 2012 [Page 6] Internet-Draft An architectural vision for HTTP/2.0 April 2012 clearly, with one single bit, if there they have a body/entity coming or not, so that the HTTP router does not have to investigate three different HTTP headers to make this determination. Kamp Expires October 4, 2012 [Page 7] Internet-Draft An architectural vision for HTTP/2.0 April 2012 4. Everybody's Got Something to Hide Except Me and My Monkey Cryptographic services is a minefield, but we have to navigate it. On all sides of this issue are strong desires to try to advance political and rights agendas by technical means, and as we have seen countless times before, getting tangled up in OSI layer 8 can doom any standard. In the FreeBSD project the admonition "We deliver tools, not policies" has been used to capture this attitude to political and emotional subjects, and I would recommend the HTTPbis WG adopts it as well. One of the most controversial subjects are proxies which interfere with free speech, either by preventing, modifying or by deanonymizing it. But we cannot escape however, that there are legitimate situations for proxies interfering with trafic, from preventing malware infection and leakage of sensitive documents over parental controls of minors web-browsing, to legal requirements to record all communications. Similarly, while most users have a right to privacy of communication, some users specifically do not, for instance inmates in jails. Implementing cryptographic policies is hard, the inmate with privacy restriction can trivially implement a covert channel by surfing an webpage in a particular pattern and it has been shown that the interval between packets can leak information about a password typed over a protected connection. Neither HTTP/2.0 nor any other protocol can do anything about situations like that, such is the nature of secrecy. What we can do with HTTP/2.0 is support legitimate cryptographic functionalities and be fair about it, by provide precise and correct information about the actual cryptographic situation, to all parties in a HTTP exchange, so that both clients and servers know if they are subject to meddling proxies or if they have end to end privacy and integrity. In HTTP/1.1 the choice to do cryptographic protection is almost universally for the server to make, typically in the form of a mandatory redirect from unprotected to protected pages. It might be worth considering if clients should have a way of Kamp Expires October 4, 2012 [Page 8] Internet-Draft An architectural vision for HTTP/2.0 April 2012 requesting cryptographic protection in cases where the server does not by default demand it, but obviously subject to the servers willingness to engage. One particular aspect of cryptography is efficiency, and it would be very desirable if the upgrade from unprotected to crypto-protected communications did not require a new TCP connection to be established. It would also be an performance advantage, if protected and unprotected messages can share the same TCP connection, for instance on the multiplexed path between a proxy and a server. Kamp Expires October 4, 2012 [Page 9] Internet-Draft An architectural vision for HTTP/2.0 April 2012 5. Return to sender: The client-server model Very fundamental to the HTTP protocol, is the strict client-server model of interaction, but the increasingly interactive webapplications have indicated a need for "server-push" or "reverse transactions". Breaking the conceptually simple client-server model should not be done lightly, doing so requires a lot of hard questions about command and control of the client computer. At the same time it would be foolish to rule out extensions to the client-server model in the next 20 years, so HTTP/2.0 should not be designed to rely on the "ping-pong" aspect of current HTTP traffic, even if that is all it is going to allow initially. Sticking to the client-server model does not preclude supporting multiplexing and pipelining of request, in fact HTTP/2.0 should most certainly do so, simply for reasons of speed and resource conservation. Kamp Expires October 4, 2012 [Page 10] Internet-Draft An architectural vision for HTTP/2.0 April 2012 6. Route sixty-six: Getting there Today the almost universal carrier of HTTP is the TCP protocol, and the entrenched infrastructure of firewalls and gateways on the internet makes it foolish to even imagine that HTTP/2.0 could be deployed rapidly if it required new TCP ports to be opened. This means that coexistence with HTTP/1.1 and possibly HTTPS on a single TCP port is an inescapeable requirement for HTTP/2.0. Initially it is to be expected that most servers will only offer HTTP/1.1 and therefore clients will send a HTTP/1.1 request with some kind of hint that they are willing to do HTTP/2.0 also. If the server bites, the protocol is upgraded and HTTP/2.0 happiness spreads. At some point, hopefully, a critical mass of HTTP/2.0 servers is reached, and it makes sense for clients to attempt to go directly on HTTP/2.0 right away, and suffer the cost of a retry if the server does not support HTTP/2.0. This situation can be significantly optimized, if the HTTP/2.0 protocol allows a client to send an optional "magic string" on a newly opened connection to detect non HTTP/2.0 servers. This string should be designed to be as short as possible, while still producing a error message from HTTP/1.1 servers which does not result in the TCP connection being closed, while at the same time being clearly distinct from any legal HTTP/2.0 message. One possible way would be to "wrap" the HTTP/2.0 request in an almost legitimate HTTP/1.1 operation: "X / HTTP/1.1" CRNL "Content-Length: 48" CRNL CRNL [48 bytes of HTTP/2.0 request] A HTTP/1.1 server will return an error, which can be recognized because it starts with "HTTP..." whereas the a HTTP/2.0 server would send a HTTP/2.0 reponse to the request, ignoring the HTTP/1.1 "bogo- header". For something like this to work, it is imperative that the HTTP/2.0 serialization of a response can never start with the bytevalue 'H' and it may be advisable to also "blacklist" certain other characters, CR and NL for instance. Kamp Expires October 4, 2012 [Page 11] Internet-Draft An architectural vision for HTTP/2.0 April 2012 7. Little Deuce Coupe: Smarter rides than TCP A surprising large fraction of todays webtraffic could fit into UDP packets, one for the request and one for the reponse. This idea is not without problems however, there is a significant potential for Dos-amplification in any UDP protocol where the reponse is larger than the request, But there are many closed domains where such risks may have no relevance, and the benefit of using UDP might be very high in terms of time and cost. I will not advocate that HTTP/2.0 standardize HTTP over UDP, but neither should it be prevented. One of the biggest factors in the IP protocols success is that the packet were defined independent of the underlying transmission media, allowing IP packets to spread from 56kbit leased lines to norwegian carrier pigeons without any need to reopen RFC 791. When finalizing the serialization of HTTP/2.0 messages onto bytestreams, we should focus on such "portability" rather than assume that HTTP/2.0 is a TCP-only protocol. Kamp Expires October 4, 2012 [Page 12] Internet-Draft An architectural vision for HTTP/2.0 April 2012 8. Counting the Cattle: A more efficient protocol HTTP/1.1 was designed in an era where things were very different, and as much help as it was to be able to TELNET to pretty much any server and "do a hand-job", the number of bytes and cpu-cycles wasted in HTTP/1.1 is simply monumental. There are many ways reduce the size of HTTP messages and they should all be considered in turn. At the most fundamental level, is not sending stuff to begin with. For instance a credible case can be made that the "Date:" header is surplus to requirements in a majority of circumstances. The next level is to send less, for instance sending the allowable cache time of an object as a number of seconds ("300") takes up a lot less space than sending the time it expires ("Mon, 02 Apr 2012 19:10:42 GMT") Next up is sending things less often, for instance if HTTP/2.0 has a functional session-mechanism, it would be enough for the client to send "User-Agent" and most cookies to the server only on the first HTTP message on the connection, for all subsequent messages a "ditto" would suffice. And finally we get to sending data more efficiently. Many cookies have cryptographic content which are ASCII encoded using base64 or HEX encoding. HTTP never has and never will run over transmission paths which are not 8-bit clean, and allowing cookies to have binary content would reduce their size by 25 to 50%. If properly designed, a moving from ASCII to a binary protocol may save further bytes. Finally, it is possible to resort to general purpose compression, but a well designed protocol encoding may give the good old LZW a run for the money, both in terms of simplicity and memory requirements. But bytes is not the only cost we care about and all bytes are not created equal. The byte that causes a HTTP message to spill into the next packet is much more expensive than one which merely adds a byte to the current packet. Any attempt to design a serialization needs to to seriously study the tradeoff between bytes scavenged and bytes well spent to improve protocol implementation. One example would be to prefix a HTTP message with the number of bytes in it. In HTTP/1.1 one reads until a [CR]NL[CR]NL sequence appears, but unless the client is a keyboard and TELNET it knows full Kamp Expires October 4, 2012 [Page 13] Internet-Draft An architectural vision for HTTP/2.0 April 2012 well up front, or could easily find out up front, how many bytes it is going to send to the server. Announcing what is to follow in the serialization is a significant optimization for the receiver, which can select and prepare sufficient storage, and minimize the number of context-switches, while still getting optimal memory layout. Kamp Expires October 4, 2012 [Page 14] Internet-Draft An architectural vision for HTTP/2.0 April 2012 9. Under Wraps: What to protect The new role of HTTP routers makes a compelling reason to subdivide a HTTP/2.0 message further than the 2 and a bit parts we have operated with in HTTP/1.1. I would split it in three parts 9.1. The envelope The envelope is the information necessary to route the HTTP message to the right place, and I would propose that it consist of the following parts of a HTTP message: Request: URI, less the query part. Host: header A server assigned session number (or zero) The length of the metadata. The length of the body (or zero) Reponse: Status (200/305/502 etc) Session number (or zero) The length of the metadata. The length of the body (or zero) I will go a step further and claim that we can live without cryptographic protection of this envelope. There are trivial workarounds to obfuscate all of these fields for purposes of privacy, and their integrity can be ensured by signing them in the protected part of the message. Taking the envelope out of the cryptographically protected part of messages, means that HTTP routers can route protected traffic, without terminating the TLS sessions. The envelope should be byteserialized with an eye to maximum procesing efficiency in HTTP routers, possibly at the expense of some bytes which could theoretically be saved. All fields should have length prefixes and the fixed sized fields be clustered at the front. 9.2. The metadata Metadata are the bits of the HTTP message which are necessary for correct semantic interpretation of the message. This is pretty much everything else we have in the HTTP/1.1 message which not related to transport or connection management. Kamp Expires October 4, 2012 [Page 15] Internet-Draft An architectural vision for HTTP/2.0 April 2012 HTTP routers will not need to examine this part of the message, if they do, they are not HTTP routers but HTTP proxies. The metadata should be byteserialized to minimize both size and processing overhead. 9.3. The body The body is an opaque sequence of bytes, but it it may be relevant to do transport level compression on it, even if it has already close to optimal entropy. One example where this could make sense is a non-caching proxy repeatedly requesting an image file on behalf of different clients. Kamp Expires October 4, 2012 [Page 16] Internet-Draft An architectural vision for HTTP/2.0 April 2012 10. Headbanging The Piano: Bringing it all together. Bringing all these strands together, here is my strawman proposal for what a HTTP/2.0 protocol could look like. 10.1. Container level At the bottom most level we have a level which is responsible for efficient transmission, multiplexing, and negotiation of connection parameters. uint8_t type; uint8_t flags; uint16_t channel; uint32_t length; uint8_t[$length] message; The type field, tells what kind of contents is being sent. Being the first field, type can trivially be subject to the 'H'/CR/NL restriction. Two types should be allocated for tunneling HTTP/1.1 request and reponses transparently. If container-level compression is negotiated/available the HTTP/1.1 messages can be compressed, cookies and all. The exact allocation policy for further types is up for grabs. It may make sense to encode the request (GET/PUT/POST) at this level, to get better utilization of this field. The flags can indicate if this particular container is subject to TLS and/or if it has been compressed at the container level. The exact parameters of the TLS or compression are subject to negotiation. It may make sense to define a "final" flag bit, to indicate the last chunk of a progressively delivered HTTP object body, similar to the "0 length chunk" used for chunked encoding in HTTP/1.1. Channel indicates which logical channel the container belongs to. A default maximum number of available channels is subject to negotiation. A client can use the available channels to send multiple requests at one time, a proxy could dedicate a channel to each client to maximize compression efficiency of metadata blocks. Channel zero is "magic" and is used for negotiation of parameters and for the TLS handshake if protection is called for. The length field is big enough to transfer well sized chunks of data, Kamp Expires October 4, 2012 [Page 17] Internet-Draft An architectural vision for HTTP/2.0 April 2012 but still of a fixed size which will make it easier to implement HTTP routing at high speeds, in hardware or software. 10.2. Message Level The message level is for transferring the envelope and metadata of a HTTP message in a container. If the metadata is cryptographically protected it may make sense to use one container for the envelope and one for the metadata, but in the case where neither envelope nor metadata is protected, a single container should be used. The envelope fields should be serialized in a length prefixed efficient format, the metadata should follow it, in whatever highly efficent serialization we find best. 10.3. Examples The above structure is deliberately very flexible and therefore hopefully powerfull enough to absorb the next two decades of whacky ideas. Such general constructs can be very hard to fully grasp without some examples, so here are some of the ones I thought about along the way. "//" marks the start of comments. Kamp Expires October 4, 2012 [Page 18] Internet-Draft An architectural vision for HTTP/2.0 April 2012 The canonical HTTP/1.1 to HTTP/2.0 upgrade C->S GET /foo HTTP/1.1 CRNL Host: example.com CRNL Upgrade: http20-gzip-tls CRNL // Client can do HTTP/2.0 // + gzip container compr. // + TLS support CRNL S->C 101 Switching Protocols CRNL CRNL {type=HTTP20-Response,chan=1,len=A} [{envelope}{metadata}] {type=HTTP20-Body,chan=1,len=B} [Hello World...] {type=CAN-DO,chan=0,len=D} [maxchan=6,gzip=0,tls=0] // Server will service channels 1...6 // Server does not offer gzip c-compr. // Server does not offer TLS service. {type=HTTP20-Body,chan=1,flag=final,len=C} [...] C->S {type=HTTP20-Request,chan=2,len=E} [{envelope}{metadata}] C->S {type=HTTP20-Request,chan=3,len=F} [{envelope}{metadata}] S->C {type=HTTP20-Response,chan=2,len=G} [{envelope}{metadata}] C->S {type=HTTP20-Request,chan=4,len=H} [{envelope}{metadata}] S->C {type=HTTP20-Body,chan=2,flag=final,len=I} [JPEG image] S->C {type=HTTP20-Response,chan=3,len=J} [{envelope}{metadata}] ... The canonical HTTP/2.0 to HTTP/1.1 downgrade C->S X / HTTP/1.1 CRNL Content-Length: XX CRNL CRNL {type=HTTP20-Request,chan=1,len=A} [{envelope}{metadata}] S->C HTTP/1.1 501 Not Implemented CRNL Content-Length: XX CRNl (grumble grumble grumble) CRNL CRNL NL

Grumble grumble grumble

NL C->S GET /foobar.html CRNL Host: fogey.example.com CRNL Yadda: yadda, yadda, yadda CRNL CRNL S->C HTTP/1.1 200 Ok Content-length: 12323 ... Kamp Expires October 4, 2012 [Page 19] Internet-Draft An architectural vision for HTTP/2.0 April 2012 The HTTP/2.0 response to HTTP/1.1 Hedging C->S X / HTTP/1.1 CRNL Content-Length: XX CRNL CRNL {type=HTTP20-Request,chan=1,len=A} [{envelope}{metadata}] S->C {type=HTTP20-Reponse,chan=1,len=B} [{envelope}{metadata}] {type=HTTP20-Body,chan=1,flags=final,len=B} [{rickroll.wav}] {type=HTTP20-Body,chan=1,flags=final,len=B} [{rickroll.wav}] {type=CAN-DO,chan=0,len=D} [maxchan=10,gzip=1,tls=0] ... Kamp Expires October 4, 2012 [Page 20] Internet-Draft An architectural vision for HTTP/2.0 April 2012 11. Security Considerations Several, read the text. Kamp Expires October 4, 2012 [Page 21] Internet-Draft An architectural vision for HTTP/2.0 April 2012 Author's Address Poul-Henning Kamp Den Andensidste Viking Herluf Trollesvej 3 Slagelse DK-4200 Denmark Kamp Expires October 4, 2012 [Page 22] Internet-Draft An architectural vision for HTTP/2.0 April 2012 Full Copyright Statement Copyright (C) The Internet Society (2012). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice Kamp Expires October 4, 2012 [Page 23] Internet-Draft An architectural vision for HTTP/2.0 April 2012 this standard. Please address the information to the IETF Executive Director. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kamp Expires October 4, 2012 [Page 24]