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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf