Stechter,
Thanks for the followup.
Stecher,Martin wrote:
This will allow to create such a separate filter box that you mentioned
but have it negotiate with different proxies and gateways what kind of
protocol/data it can handle.
Given what you say at the end of this sentence, I assume this is for the purpose
of adaptation, for example to permit data to travel through proxies and gateways
that can support the correct set.
As has been clear for some time, the OPES topic is both important and difficult.
That sort of combination always makes want to look for some history of
exerience with ways to solve the current problem.
In the case of OPES, I do not know of a qualifying history, nor do I see the
effort to build something based on such experience.
In any event, I am still not understanding how something like this SMTP draft
can say much that is of use, absent a meaningful OPES architecture specification
and, preferably, protocol specifications.
If the current document is intended as a case analysis for a particular
application -- namely email -- to serve as *input* to the design of the OPES
architecture and protocols, then I do not see how the current document achieves
that.
Today a protocol such as ICAP is hacked and misued to work with other
protocols than HTTP.
As you decsribe it, this sounds more like the challenge of adapting a protocol
at one layer to different types of transport at the layer below. How is that an
OPES task?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf