ORLANDO BOF MINUTES

HTTP-NG BOF
-----------
Henrik, Mike, and Jim

ietf-http-ng@w3.org will be the official list if there's a group chartered.
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 semnatic 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: JG.

Which of the three layers provides security? any? all?

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
its possible in 6 months or it's not"  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 switchin got 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.

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.

Received on Monday, 7 December 1998 16:28:47 UTC