From: Mike_Spreitzer.PARC@xerox.com Date: Thu, 17 Dec 1998 10:08:20 PST To: rohit@uci.EDU cc: firstname.lastname@example.org, email@example.com.EDU Message-Id: <98Dec17.100846pst."53441(5)"@alpha.xerox.com> Subject: Re: ORLANDO [HTTP-NG] BOF MINUTES OK, here's what I get after fixing a few glaring typos, errors, and omissions. I'd appreciate it if you could fill in the full names of the people in the audience, as I don't know many of them. HTTP-NG BOF ----------- Henrik Frystyk Nielsen, Mike Spreitzer, and Jim Gettys Recorded by Rohit Khare firstname.lastname@example.org will be the official list if there's a group chartered; open now for discussion. Today is a charter-bashing session Henrik opened with some early results on the Microscape and slimmed-down "mobile" test pages. Shows improvement vs. even a highly-optimized http/1.1 engine. Mike Spreitzer presented the draft motivation/charter/plan: draft-frystyk-httpng-overview-00.txt. "spurious diversity" amongst all the various extensions of http projects @@hey, isnt' DARPA paying good money for "artificial diversity" these days? Modularity, in this case, is factoring into three layers: transport, invocation, document exchange. Henrik: there are two dimensions of modularity: layering (extensions at a high semantic abstraction still have to worry about bits on wires) and interaction between extensions (arbitration between potentially conflicting modules). Gettys: even as simple as end-of-message: there are four or five varying techniques in HTTP/1.1 alone. Henrik:https:// is an example of layering failure. Just adding security now required changing entire namespaces w/o an upgrading facility. Mike is considering separating layer 2 into an invocation control and parameter-passing subparts. Transition: unlike IPv6, it should/can be deployed link-by-link rather than e2e. So adoption scenarios might be client-cache or wan-cache pairs or so on. Performance as the relative incentive to install these pairs, initially. Evolution, later: making it easier to churn out new protocols @@by analogy to how XML cleans up SGML to make it easier to churn out new tagsets Allaire's XML-over-HTTP code tree will go open source tomorrow. Jim called it a "train wreck": makes it impossible to allow firewalls to read inside envelopes. Hallam-Baker: train-wrecks are good things, motivating change. Of course, transparent replacement of HTTP/1.1 is a GWS (goes without saying). Transition also needs metadata about servers' version level from DNS or so. Jim Gettys presented the charter overview. The app and tsv ADs jointly decided this should be in Transport (under Vern Paxson). Proposed chair: Jim Gettys and Mike Spreitzer. Which of the three layers provides security? Certainly lowest; middle might get involved too; upper builds on the services of the lower two. The lower layers are more "baked". Open question: timelines and action items and milestones. Deliberately Excluded: language mappings, remote-invocation layer APIs, any enhancement of Web semantics, replacing TCP. Presented an 18-month plan. Yaron: "triple it". Huitema commented "either it's possible in 6 months or it's not" Mike: we have three overlapping 6-month plans, one for each layer. Touch: "where's minimalism, 'don't put it in if you don't need it'". Mike: "of course, there has to be conservatism to succeed". Huitema: "either you have a solution or a warplan -- committee hacking?" Henrik: HTTP/1.1 is getting more complex all the time, and the interactions are growing exponentially. We need to start over with something that will be simpler at the lower layers. Jim: the alternative -- today -- is very complicated indeed. Joe: work the goal "keep it simple" into the charter. True, it's "apple pie", but say it anyway. Lawrence: the new version of this document has been genericized to the point that everyone can agree with it without neccessarily agreeing with anyone else. As a rationale for chartering a WG, it's lack of concreteness and testable assertions is a weakness. Mike: we had a more specific document, a very specific charter that was thrown back at us. We wrote it to be "specifically vague" Hardie: something was lost in the round-trip, such as Janssen's design principles. One was "generic platform for services". The logic seems to go, people are tunnelling and layering every damn thing you can think of onto HTTP, so let's design something explicitly designed for tunnelling and layering every damn thing you can think of. Henrik: you can't start off a working group debating the problem itself... Yaron: I object to using HTTP in the name. It looks much more like lessons learned from HTTP, but it's not an evolutionary descendant. Second, there's a shooting war in D-O standards marketplace, and IETF should stay out at risk of its own credibility. Instead allow more time for 1.1 to be deployed, get experience with IPP, DAV, etc; and let the wars settle out. Mike: in fact, their war is elsewhere; we've been talking to some of them about providing the wire protocol. They're worried about the APIs. Phill: If the goal is to provide another resolution service for http:// urls, then this IS the natural successor transport and SHOULD be called HTTP-NG. It's a massive installed base. Too many WGs are reinventing HTTP as it is. If not one, we'll have fifty. Scott: I'd prefer fifty :-) First, there has been a great deal of private W3C discussion, but the public list is quiescent [it's now considered the main list]. Second, the charter is pretty broad. The separation in three is good, though I disagree significantly with the third. Negotiable muxing of stacks is a great idea. Out-of-order responses would be great. Compact-encoding is great -- but switching to an object framework seems, to me, to be neither necessary nor the most effective. Just re-encoding HTTP/1.1 would be a trivial, effective, and useful exercise that we should all do. Finally, the charter doesn't exclude things which could slow it down to 4+ years. Saying it's a full DO system and narrowing it to support TCWA only invites "experts." Split into subgroups... Jim: ADs discouraged that. Vern: I'm finding this discussion very helpful... Eliot (? AAA bof leader): After bashing out a requirements draft, the charter may have to be re-bashed. Second, enough work has been done to avoid being remanded to IRTF Mark Day: take away the letters HTTP and convince me you're still part of the solution. Mike: we need to reduce the number of these things. We want one thing, which replaces HTTP. Realign the Web application in this direction, and everything else will follow. Jim: if we can even develop recyclable parts from this effort, it will have been worthwhile Black WOMAD shirt: I'm worried there's running code. Even a prototype ends up constraining the requirement space. Mike: "I was not under the impression that the WG would see my code and roll over" :-) Jim: I am very tired of several years' worth of arguments with no data. I insist on data. [It's not just Mike's code alone, of course] Jim Whitehead: By focusing on just what the Web currently does, you could be risking a second system effect. I want to ask "Where's the Hypertext"? There are lots of ideas in the HT community that are not reflected in the charter Gettys: and deliberately so! JW: I'd at least like to see TCWA spun out, to reach beyond the classic apps, IPP, WebDAV, RDF metadata for links, alternative name resolution, caching, etc. Further out, I'd like to see some economics: integrating payment and security. [Note that a DAV-NG prototype was discussed by PARC in Chicago] Mike: we were nervous about calling out a set of applications, because they don't form success criteria. All the current IETF HTTP derivatives are on our radar; are in that set. But, App area is unenthusiastic about chartering a new Web group Rohit: well, several startup companies have been focused on 'fast http links' by cutting all kinds of corners and still haven't produced dramatic results -- what have they said during the W3C gestation of this project? A: none Scott: the secret of the Web is its anarchism. The loose coupling between data and serving process is extremely valuable. Henrik: lots of new restrictions on caches, rights mgmt, payment, etc. And if they're not going through extensible proxy caches, they'll be short-circuited. Scott: the notion that creating a better application framework will convert people from hiding their application data in an opaque media type is to get through firewalls. What you're doing, quite correctly, makes it easier to write more intelligent firewalls, but app developers will still hide out at the highest layer. Mike: distinguish between extensions of HTTP and of HTML. I see a lot of interest in a "pun". forms, which are simultaneouly an API and an interface. But that's not the end-all. Carl-Uno: your factoring is a fine idea. IPP would be interested in the two lower layers (Transport, to me). But the continuation of the HTTP is an Applications area project, in parallel with close interaction. If you think it's going to take 1.5 yrs, it'll be 3, but if you split it, maybe 2. Joe: put that performance chart back up... it's only a 5-10% performance difference. The big gain was from HTTP/1.0 to totally optimized HTTP/1.1. Show me 20-30-40% Gettys: cache-validation is already 4x faster Scott: but what if you just abbreviated 1.1 messages Gettys: that would be another valid approach. That knocked out the 1) perf argument 2) the generic app argument 3) tweak HTTP. You can't prevent programmers from 2), so you're either left with 3a) a 6-month 1.2 version, or 3b) an IRTF project to reinvent the Web. Henrik: people aren't evil, they just can't see how to do it easily Joe: so write a book instead :-) Henrik: you can't do it in 1.1: there's too many dependencies. Joe: and how will modularizing it solve the problem? Henrik: the interactions don't get simpler, but the 'vertical' ones will Greg Callahan (NFS4 on ONC RPC group chair): the transport area already has a single RPC layer project: why not use the ONC? Mike: our prototype does use ONC+XDR, with slight extensions. Mike: one clear difference is that ONC doesn't have objects at all. Huitema: good! it's simple enough it's picked up on an application-by-application basis. Mike: then why isn't it used for Internet-wide use? We belive there are fixable insufficiencies in existing solutions just as we found with Web over ILU a long time. We want to smooth out the warts that make it inadvisable for Internet-scale use. Huitema: then why not call it the Internet RPC WG? Mike: because you need to limit the scope to the Web to remove some complexity. Scott: that's no real limitation; you track every new application of the Web and you never close. Mike: yes, we'll eventually have to stop tracking and leave that to others; hopefully at that point the tracking we will have done will have given us a sufficiently robust system. Yaron: note that the lower you go on the stack the more excited people are here. I'd love to MUX straight HTTP/1.1. How about a group whose sole job was muxing, properly chartered in Transport. And THEN, open a new WG, and so on. Josh: "if they're trying to do HTTP then why are they doing a DO system?" is a fair charge. But it shouldn't be named HTTP. I also don't agree there's a terrible problem which merits rebuilding from scratch. You've said the fatals are lack of caching, error code limits, yada, yada, but they each seem fixable in increments. Why not patch ONC, or patch HTTP? The work effort needs to modularize. Huitema: the basis of your argument is that HTTP has been polluted by people using to all sorts of things. That's a fact of life. Our first Bellcore voicemail over ethernet in 1983 used FTP? In the late 80s, it was 822. Reuse someone else's infrastructure until you have critical mass to become your own application. It's like if I wanted to change email to make it easier to do transactions back then... Mike: resolved, people think the factoring is good; MUX has strong support. Yaron: "It's the MUX stupid!" Jim: I sense that we should 1) work on MUX and 2) and make requirements on HTTP-NG. No opinion on whether it's one group or two.