On Sat, 8 Mar 2003, jfcm wrote:
Initially I understood the OPES was an HTTP oriented filter sitting
on one side proxy and possibly calling on servers through a callout
protocol to modify the transiting data.
Sounds accurate enough for a brief summary, except OPES is not
HTTP-oriented or HTTP-specific. HTTP is just one of the protocols that
OPES must support. OPES is application protocol agnostic. Does any of
the drafts/RFCs say that OPES is HTTP-oriented?
- I gave an example talking of SMTP. Some objected it iwas not HTTP, but
most accepted SMTP.
I may have missed that discussion, but I do not recall any recent
objections to SMTP. Why object to one of the most popular applications
on the Internet that can definitely benefit from OPES?
- there was then a debate over redirection: can an OPES redirect or
not. Seems controverted too.
There was a discussion what OPES agents can redirect. I do not recall
any opinions that OPES (as a whole) cannot redirect. In fact, since
OPES can both generate application responses and use external
services, it is clear that it can redirect (by superposition)!
- there was a debate on one way or two way? Two ways seems accepted?
I do not think there was any real debate, just some wording
confusion/improvements. OPES can support both uni- and bidirectional
(and many-directional) application protocols.
- there was a debate on the fact that an OPES server may not call
the user for a direct confirmation: the response seems odd to me
(through the application - I am not sure about hwt it means)
It simply means that the user cannot communicate with OPES agents
using OPES protocols. If OPES agents can get confirmation using
application protocols, then direct confirmation is possible (for those
application protocols). This rule preserves OPES scope as an
application proxy service. What is odd about it?
- I generalized the concepts as ONES and tried to see the boarder
between ONES and OPES, with some difficulty to understand where OPES
end. A difference seem that the OPES is not chosen or even ignored
by the user, while the ONES are organized/selected in cooperation by
the user/producer.
OPES most certainly can be selected by the user (by selecting an
appropriate protocol proxy). Moreover, OPES services may be affected
by user preferences that are, for example, communicated over
application protocols and/or stored at the proxy.
This generalized architecture of mine made me to analyze that the
semantic could be clarified. That we had a more balanced end to end
vision (and wording) of the system. Also that the protocol was an
inter-dispatcher protocol with a possible command channel 0,
triggering server applications.
I assume the above paragraph is not about OPES, but ONES or something
else, right? Not sure what it is, so I cannot say whether it is indeed
"more balanced" (than OPES?).
The discussion went on the need or not to swallow the data/processes
related to a channel (a set of channels - from dispatcher to
dispatcher being allocated to a transaction).
Then the callout protocol was discussed and it style. Soap or not,
inter-active on blunt stop, bandwidth consuming, etc. I tried to see
where we could have good specifications and examples of that
protocol; in total or in part.
OPES WG drafts contain architecture and protocol requirements. If you
need an example of an OPES-like protocol, ICAP is a good candidate.
There is even an ID that compares OPES and ICAP. The OPES predraft
defines some parts of the OPES protocol.
The IDNA discussion has identified that the browser could use it to
interact with an IDNA server. Other examples (EDI, translations,
airlines, visa etc) were investigated/alluded to.
This means (to me) that we have a network of dispatchers with the
following functions
1. entry in the dispatcher in http, smtp.
or other application protocols
2. filtering a according rules
3. filtered objects are sent to the server
4. the objects come back from the server
5. they are sent in http or smtp or....
Sounds about right for a brief summary. Note that the above 5 items do
not include anything related to the "network of dispatchers" you
mentioned above. All these items describe one OPES processor. There
can be many OPES processors, and some might cooperate, but such
cooperation is not covered by the above items. I am not sure whether
it would in OPES scope beyond things like enforcing user preferences
and tracing when several OPES processors modify a message.
Also, IMO, the above items can be derived directly from the published
OPES architecture. I am not sure how this long email thread is related
to them.
Your position says (1) does not use http or smtp or another IETF
protocol, so the concerned system is not an OPES, so the (3)/(4)
protocol is not a callout protocol.
What position are you talking about? OPES is application agnostic and,
hence, is not limited to IETF protocols. HTTP and SMTP are just
well-known examples.
Alex.