--On Friday, December 14, 2001 10:53 -0500 Patrick McManus
<mcmanus@appliedtheory.com> wrote:
> To this point webi has pursued topics that many perceive as busywork -
> known problems, taxonomies, and now requirements documents. Even one
> requirement gathering process (IDD) that was getting decent list
> interest was summarily shutdown in favor of RUP requirements - which
> has had interest only from a few parties.
>
> I, for one, diligently pounded away on all of them as pre-requisites
> until I realized that there was never any intention of allowing me to
> solve the problem that brought me here in the first place: "I have an
> HTTP client that would love to take advantage of enhancing services
> intermediaries might offer. How do I find out what/who is offering?"
> or even a watered down version of the same: "I'd like to stop
> hijacking traffic with L4/7 switches. My clients would use the damn
> intermediary if I could just find out about it without configs on each
> client."
Firstly, thanks to Patrick for the work he did on the IDD document (which I
note has now expired).
As chairs, it was our impression (from what we saw on the list and by
asking folks at meetings) that there wasn't sufficient interest in the IDD
work (particularly the user-agent to intermediary part) for us to use
cycles on it. If that was wrong then we goofed; I know that I've always
considered this to be the more interesting and useful part of WEBI's work.
As David Martin's email report of what was discussed at the lunch meeting
states, there *does* seem to be some interest in this area. As Patrick
points out above, there are some very good reasons why this group should be
looking at IDD.
My impression from reading "IAB Architectural and Policy Considerations for
OPES" is that IDD could be very useful in identifying intermediaries
offering particular services. While there is naturally a possibility under
some network architectures for OPES capability intermediaries to be
implemented with interception technology (and going against the intended
architecture), the requirement for intermediaries to be explicitly
addressed at the IP layer suggests to me that there is a necessary
requirement of a method to *find* those intermediaries in a reasonably
automated way. Step in IDD ???
While I believe there may be some scaling issues, I can also see ways in
which something IDD-like might be used at the access network level to
direct user agents to specific intermediaries to remove the necessity for
DNS based (for example) request routing. (And I should apologize for never
getting around to writing an I-D on this.)
For the record, while we're using the acronym "IDD" to refer to this work,
there was *never* an assumption that we had to create our own protocol. If
rescap, NAPTR or something else do what we need to do then we should
obviously use the appropriate technology.
It's unclear at this time whether there is sufficient interest or time to
investigate IDD as well as RUP within this working group. My suggestion is
that folks interested in doing work in this area send mail to the chairs
expressing that interest; I would envisage us setting up a "design" group
for this work so that we can at least present our understandings of what
might be useful to this and other appropriate groups in the form of an
Internet Draft.
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:23:00 MST