Mike Spreitzer: OVerview of HTTP-NG proposal Outline: - Motivating problems and opportunities - Suggested Requirements - Transition Outline Movitivating problems and opportunities - Network load & performance - Transport flexibility - HTTP/1.1 didn't have an independant transport - NG should have this flexibility - HTTP/1.1 Complexity - Very hard to evolve protocol - people tunnelling through it in incompatible ways - Useless diversity in object systems Suggested Requirements - Modularity - Support for "mandatory" extensions - Scalability - Transport flexibility Sugested Solution: 3 Layers - Message Transport - Remote Invocation Layer - Web application Example from Henrik: Moving to SSL requires changing locations. It would be nice to fix this Spreitzer: Maybe Remote Invocation Layer should be split into two. Control protocol and actual remote invocation? Transition - Easier than IPv6, because HTTP-NG doesn't have to be available end-to-end - can do link-by-link (proxies?) Transition: Incentives - Start with a few popular WWW agents - origin severs - browsers - proxies and caches - Improve their performance, etc., and incent others to hop on the bandwagon - performance, mangeability, scalability, etc. - break the catch-22 cycle There will be a "train wreck" because of all the various activities all going on on top of HTTP. Gettys thinks the train wreck is unavoidable, but can be mitigated with HTTP-NG. e.g., Allaire (of Cold Fusion fame) will release XML-over-HTTP source on Tuesday Transition: Technology - HTTP/1.1 Upgrade Header - HTTP/1.1 Extension framework - Protocol conversion gateways - Directory, DHCP, DNS services for meta-information on servers - new URI scheme(s) Gettys: HTTP-NG Charter ----------------------- Area - Transport Mailing List: ietf-http-ng@w3.org Description of Working Group - Leverage experience gained from HTTP and how it's used - proxies, caches, and firewalls - explicit layering and modularity - How HTTP is actually being used. Not just browsers, but extensions and apps tunnelling through HTTP - Goals - Improving basic application functionality - ? Requirements Documents - Current proposal is 3-layer architecture - Lower layers are farther along Deliberate Exclusions - Definitions of language mappings - MetaAPIs for the remote invocation layer - Significantl advancing the functionality of web apps - Development of new base transport protocols (i.e. TCP replacements) Goals slide: - end goal, 18 months to completion There are complaints that this may be too broad and/or too ambitious. Henrik: goal is to stay simple over time, unlike HTTP. Layering will help Gettys: Everyone is layering on top of HTTP. This has "undesirable properties." So NG will actually be simpler. (Later) We really shouldn't support everybody and everything. Joe?: we should add a specific line to the document saying "keep things simple Lawrence?: we should be more concrete. Each point listed is desirable, but it's too generic to to really judge any faults Mike?: we had something more specific in the charter, but this was taken out to be acceptable ?: maybe something was lost. There were more design points in the original Yaron: HTTP-NG is a bad name. This has nothing to do with HTTP. Also, there's a shooting war going on for solutions like this (object systems). Maybe IETF shouldn't get in the middle of this fight. Let's let the fight settle down to standardized. Mike?: the hot war is *really* over APIs. The players in the war are flexible on protocols Yaron: What will the players say about something named "HTTP"? This is good for IRTF, not IETF (unknown): If the URL schme will be http://, then we should call this HTTP-NG. We need a common layer because many in the IETF are already trying to reinvent HTTP. "If we don't have one group, we'll have 50." Scott Lawrence: Everybody should switch from private w3 mailing list to the new list. And, the proposed charter tries to bite off too much. Some things are good. Factoring out transport pieces from HTTP, compact encoding is good. All this object protocol stuff may not be. We should exclude work that will strech things out, such as calling this a general object framework. Mike?: applications will be a filter for rejecting ideas S.Le: maybe split into multiple working groups people at front: IESG wanted one group IESG person in back: we want this to focus on transport more. ?: It would be interesting to just take WebMUX and factor out this kind of piece from HTTP/1.1 Mark Day: Prove that this is a solution, not a problem, when you take "HTTP" out of the name black Womad shirt guy: There seems to be an emphasis on flexibility and not looking at applications other than the Web. The danger with having code before requirements is that the former too strongly affects the latter. Mike?: I don't think the group will roll over too easily at our suggestions. Gettys: It's a pain to argue without data. with code, we get data Whitehead: we are risking a second system effect. And this has nothing to do with Hypertext. Also suggests splitting into multiple groups. Also, build some sort of economics into it maybe, so that things can be paid for. Mike?: we don't want to make the success of all apps running on this a crieterionBut we will be drawing requirements from specific apps Rohit: Transition strategies. Performance may not be its own reward. How are companies that are trying to improve performance actually doing? (Sitara, etc.) S.L.: Characterizing HTTP as a distributed object system is a strech. Everything can be a D.O.S. One of the reasons HTTP has evolved so successfully is that it is anarchic. Plugins, etc. succeed or fail on their own merits. Tighter coupling would be bad if that's what is happening. Panel: It's not Henrik: Caches may get in the way of advances. As soon as higher layers start interacting directly and closely wiht HTTP, a decent coupling would be useful S.L: better app framework may not be preferred over HTTP tunnelling and the like. Maybe people are tunnelling to get around firewalls, a completely contrary goal to HTTP-NG, which tries to help with intelligent firewalls. Mike?: People will try to work around firewalls no matter what's going on. Gettys: And better specification of what is being done allows firewall admins to loosen up restrictions, since they understand more of what's happening Chair of IPP group: IPP would probably like to be one of the modules that can use HTTP-NG. And if you think HTTP-NG will take 18 months, it will take 3 years. Split the group up and it might take 2 instead. Joe?: 5-10% performance improvement is not enough for a working group. There should be a better improvement or other reasons. And, if we think this is HTTP/1.1 cleaned up, it should take 6 months and should be HTTP/1.2. If it is a total redesign from scratch, it should be IRTF. Gettys: For cache validation, NG is 4x faster Henrik: Extension is hard with 1.1 Joe: Then write a book about how to do it. Don't write a new spec Henrik: We are making it possible, not necessarily easier Joe: how does modularizing 25 extensions make them simpler Henrik: The modules can reuse pieces (e.g., marshalling) NFSv4 person: NFSv4 has layering too (ONC RPC). Why start over? just use ONC RPC. Gettys: the prototype does this. Mike?: we should look at requirements before deciding what we use/reuse. One difference is that ONC RPC doesn't use objets random mumblings in the crowd: Good! Mike?: We are trying to look at existing systems and rubbing off the warts that we don't like. S.L: Once we start rubbing off warts, we'll be doing this forever Mike?: That's why we have scoping and time limits Yaron: I'd love to see MUXing. THen we can put HTTP/1.1 on top of it. After that succeeds. Then we can start a new working group that deals with the other stuff. Josh?: HTTP is an object system now. HTTP-NG just admits it. But this scope is still too wide. The problem isn't bad enough to rebuild from scratch. (caching, tunnelling through POST, etc.) These problems can be fixed incrementally. Mark Day: We still don't quite understand what problems are being solved Christian Huitema: pollution of the protocol is normal. the whole story of application development is to reuse another protocol to start out. Trying to change it to make it easier to write apps is wrong. Just like trying to change e-mail for transaction app support. Gettys: Consensus is that WebMUX is ready to start on. The rest is still half-baked Henrik: We are trying to get input on requirements AAA person: you'll have no problem with getting input on requirements. ?: We could take HTTP/1.1, and wedge MUX into it really hard. Then later, switch MUX to a binary protocol. Panel: it is a binary protocol already ?: NFS is already using a great MUX protocol RFC 1822 Jim: We should have one working group for Requirements, and for MUX work