wow...I'm not sure we fundamentally disagree about the outcome,
but this seems to contain several different kinds of confusion.
1. "intermediary": Lately it has become fashionable to use this term
as a catch-all to describe any network element between the endpoints,
acting at any layer of the protocol stack. Such usage tends to
gloss over several important issues, such as whether the intermediary
introduces layering violations (and the problems that come with doing so),
or whether the intermediary is acting with explicit consent of at least
one of the endpoints (and the associated issues with control of content).
So we shouldn't treat all intermediaries as if they are equally useful
or valid.
2. The fact that there are emerging standards (by IETF, w3c or anyone else)
emphatically does not demonstrate requirements. Old issues of trade
magazines are full of references to standardization efforts that went
nowhere - often they were trying to solve the wrong problem, because
their work was obsolete before they started, of simply because they
didn't understand the problem they were trying to solve.
3. Similarly, the fact that the "market" has chosen a particular path does
not justify that choice as good engineering, and the IETF does not have
a responsibility to endorse bad engineering. Deployment in some form
is a necessary condition for an engineering solution to be successful, but
"market acceptance" is not a sufficient condition for engineering success.
The market is quite often wrong.
I don't doubt that it would be useful to have a standard mechanism for
modifying content (even in fairly arbitrary ways) before it is transmitted
to an audience, or to modify it on receipt by a member of that audience.
And you cite a number of valuable services that could take advantage of
such a mechanism. But the charter currently under discussion is a lot
more open-ended than that, and that's part of why it's controversial.
Keith
> This debate over OPES appear sto have a blend of technology religion,
> business interest, and even some hand-waving or other failures to
> communicate at its core. I, too, can quibble with the proposed charter but
> there is a need for a standard mechanism for calling services that operate
> on http (and possibly rtp) messages at an [application-level] intermediary.
>
> In general, the technical and industry requirements can be demonstrated by
> the fact that there are emerging w3c standards and implementations for
> constructing distributed applications by calling web services and,
> specifically with respect to edge services, by the fact that there are
> edge-of-network implementations that provide various transform services,
> e.g., virus scan, language translation, and, yes, content adaptation based
> on device and network capabilities. These aren't layer violations, some of
> these applications are, however, aware of the protocol layers much the way a
> management application can be layer-aware. These intermediaries exist and
> they will continue to do so. The only question is are there standards.
>
> The requirement for doing this at an application intermediary in a standard
> way is the usual requirement for standards: the industry serves its
> customers best when products interoperate. Standards for selecting the
> services to be called (rules) and how to call them (service bindings and
> protocols) will provide interoperability in constructing those distributed
> applications. One of the areas for investigation in the working group
> (assuming it gets chartered) is whether we need something unique to edge
> services (a la icap) or whether something more general is appropriate (a la
> soap).
>
> I, personally, don't think the applications need to justify themselves
> against a model; rather, models may provide insights in the presence of
> reality. The problem is fundamentally one of scaling. How do we distribute
> the work load, provide an improved user experience and do so with an
> authenticated and authorized set of rules? If OPES can help answer those
> questions, I'm not sure what the problem is. There may well be "better"
> ways of building these distributed applications, but the market has chosen
> these application intermediaries as an evolutionary step. It would be a
> mistake for the IETF to abdicate its responsibility here.
>
