At 23:26 07/03/03, bindignavile(_dot_)srinivas(_at_)nokia(_dot_)com 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