From: Mark Day (mday@sightpath.com)
Date: Mon Mar 06 2000 - 08:08:25 PST
Since there's supposed to be a new press release on ICAP Real Soon Now, and
since I don't want to have Rohit complaining again, here's my personal take
on the protocol. Usual disclaimers: not a SightPath position, my opinion
only, etc.
Executive summary: Spec good, process bad.
Elevator summary: The protocol is a nicely-done piece of work that solves a
modest problem. It doesn't really merit the associated hype. There is
supposed to be an "open" process, but the reality is that the "hosts" of the
ICAP Forum (Akamai and Network Appliance) control it: on open process, they
talk the talk but have yet to walk the walk. The future of the protocol is
pretty fuzzy at this point, since it arguably belongs in the WREC working
group of the IETF but it's not yet clear that the group can or wants to take
it up.
Gory details:
Suppose that you want to be able to intercept an HTTP request or response,
pass it off to some other service, and get back a modified version of that
request or response. That's the problem that ICAP solves. So if that's what
you need an agreed-on mechanism for, you're all set.
The trouble is that this communication is necessary, but not sufficient, for
the kinds of applications that are mentioned in the ICAP
introduction/presentation/web site. There's nothing about ICAP that helps
you know when to send something off to the other service, or what
constitutes a good or interoperable implementation of such a service. So
when you hear or read about how ICAP enables (say) ad insertion in the edge
network, or dynamic adaptation of HTML content to handheld devices, take
that with a large pile of salt. ICAP can be a useful component of such
things, but it's not the whole solution itself.
In particular, the ad-insertion scenario appears to be a fantasy. The client
can deliver up cookies for the origin server that is the apparent
destination of its original request, but there is no means identified for
the adapting server to get its cookies. It's hard to do a decent job of ad
selection (a big part of what the ad networks get paid for) if you don't
know who the viewer is.
The spec seems fairly tight and well-written. The primary authors (Alberto
Cerpa and Jeremy Elson) are grad students at USC who were hired as
consultants by the sponsor companies. [Rohit, if you quit the startup trail
and go back to consulting on protocols and standards, these two would likely
make good 4K associates (I've also told them as much).] They previously
worked on NECP with many of the same players, and that spec is also a fairly
nice piece of work.
The real drawback to the protocol is the associated process. ICAP was
press-released into existence well before there was any spec that the
"hosts" were willing to show anyone. The initial terms of participation in
the "open" process were that one had to "endorse" the protocol before one
could see it (this has since been fixed). The terms of governance continue
to be extremely unclear -- the inaugural meeting of the ICAP Forum was
somewhat spoiled by the realization that the people in the room were not in
fact empowered to make any decisions. There was an initial claim that WREC
would take up ICAP at Adelaide, which was tempered when people realized (a)
that WREC isn't yet chartered to do any such thing, and (b) that WREC seems
not to be meeting at Adelaide. So now the claim appears to be that WREC will
be chartered appropriately by the next IETF meeting, and ICAP will be
submitted there.
It was remarkable to see the way in which this process worked (or, rather,
failed to work) on the ad-serving/cookies concern:
Here's the problem.
Yes, that's a problem.
Will it be fixed?
No, but here's a hack.
That hack doesn't really work for the ad-serving application.
Yes, you're right.
So will you stop saying that this works for ad insertion?
<No response -- at least none that I saw>
I was relatively lucky -- many of my comments were incorporated into the
draft. I think I would be pretty angry if I were the person who tried to
point out this severe problem around cookies, especially since the "hosts"
asked that comments focus on problems that would really stop the service
from being usable at all. So then you bring up such an issue and they
(basically) ignore it. Or that's the way it looked.
In summary, the ICAP spec seems it could be a pretty solid base for
implementation and further refinement, for some applications. The ICAP Forum
seems like a pretty poor structure for carrying any of that work forward,
and I worry that the "hosts" will undo the good they have done so far by
holding onto too much control. Then again, maybe the lesson to learn from
Sun and Java is that it's a good idea to talk about open processes but not
take them too seriously.
--Mark
Mark Day
Senior Scientist
SightPath
mday@sightpath.com
+1 (781) 663-8310
This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 08:06:25 PST