Subject: RE: is IDNA an OPES?

From: jfcm <[email-masked]>
Date: Sat, 08 Mar 2003 01:40:35 +0100

At 23:26 07/03/03, [email-masked] wrote:
>Alex,
>I was a little behind in reading the various threads in this group! I 
>wanted to clarify some terminology with you. When you referred to OPES 
>agents, you meant any OPES device, OPES processors or callout server, 
>right? I agree with you that raw IDNA ML messages cannot be conveyed to 
>even the OPES processor (or, the callout processor too) from the content 
>producer, using HTTP!

I asked a question because I have very hard time understanding  what is an 
OPES according to the IAB and this group's definitions I found sometimes 
contradicting. Just want a clear list. To try to have the debate to help, I 
picked another case where I have very hard time to understand what it is 
and where it fits which is IDNA. (I feel the standard does not match all 
the user needs, and because testings are under way).  And I asked if IDNA 
was OPES to try to better understand from the responses.

Responses have helped a lot to see that the situation is more confuse on 
both aspects. Let drop IDNA. 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.

- I gave an example talking of SMTP. Some objected it iwas not HTT¨P, but 
most accepted SMTP.
- there was then a debate over redirection: can an OPES redirect or not. 
Seems controverted too.
- there was a debate on one way or two way? Two ways seems accepted?
- 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)
- 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.

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. 
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. 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.
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....

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.

I question that and I say that what qualified the OPES is that the (2) 
filter may apply and that (5) is in an appropriate http/smtp format.
jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 7 Mar 2003 22:37:12 -0700 (MST)

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?).

> related to a channel (a set of channels - from dispatcher to
> dispatcher being allocated to a transaction).

> 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,

> This means (to me) that we have a network of dispatchers with the
> following functions
>

or other application protocols

> 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.