Subject: Re: OPES protocol, pre-draft

From: jfcm <[email-masked]>
Date: Wed, 19 Feb 2003 18:01:57 +0100

On 06:56 19/02/03, Alex Rousskov said:
>If there is a consensus that OPES server cannot modify source and
>destination info, then we can simplify the protocol a little bit.
>Is there a consensus regarding this design decision? Perhaps Abbie's
>poll will show...

No. The OPES can sub-delegate a task temporarily or permanently. The first 
task that a server must be able to do is to qualify a request as a 
dispatcher. We all know an application which is based on that thinking: the 
DNS.
jfc

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

---

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 19 Feb 2003 13:19:37 -0500

reinaldo,
see inline,
 
abbie

-----Original Message-----
From: Penno, Reinaldo [BL60:0430:EXCH] 
Sent: Wednesday, February 19, 2003 10:21 AM
To: 'Alex Rousskov'; [email-masked]
Subject: RE: OPES protocol, pre-draft

Before I make any comments, it seems to me this work has a lot of overlap
with things we already did. 

1. The examples are greatly covered in the use cases and deployment
scenarios 
2. Some other things seems to me that belong in the requirements draft. It
doesn't make any sense to have two drafts having requirements on the
protocol, moreover the sole purpose of one of them was to have all the
requirements. 

--- abbie

Yes, this is whay at some point i did state that 

3. The idea was to try to reuse a existing protocol instead of designing a
new one.  

well, this discussion will then lead to ok, what can we use if this is the
protocol that we have just designed. So, it does not hurt to do what we are
doing, actually it may be healthy. The best way to figure out if we can
reuse something is to design a protocol first and then say, woo it really
looks like ICAP or BEEP or ..... (SOAP)

4. There are two protocols for OPES, in-path and the callout. Are they going
to be the same, different?  

focus now on callout protocol.  

I guess what we need is to incorporate whatever requirements in a
bis/whatever version of the requirements draft, extend the use cases and
scenarios and for every protocol we think has a chance to be the OPES
protocol, match its semantics against the requirements draft, that's what a
requirement draft is for. 

If Alex's document is the bootstrap for the following deliverable 

"MAY 03 Initial protocol document for OPES services including their
authorization, invocation, tracking, and enforcement of authorization."

I guess it should be much more to the point and focused. Should we hold a
conf call to iron these things out? 

Chairs? 

I guess we should be also working on the rules specification?  

------abbie

why not?????? 

Regards, 

Reinaldo 

 SNIP

---

From: jfcm <[email-masked]>
Date: Wed, 19 Feb 2003 20:57:36 +0100

On 18:46 19/02/03, Alex Rousskov said:
>jfc,
>
>We are talking about two different things here. You are
>talking about directing application messages to appropriate callout
>servers. I am talking about [re]directing application messages to
>different data consumers.
>
>For example, an HTTP request for www.w3c.com can be redirected (by the
>callout server manipulations of HTTP headers and meta-information) to
>www.w3.org. Another example: an e-mail to [email-masked] can be
>redirected (by the callout server manipulations of SMTP headers and
>meta-information) to [email-masked] _and_ to [email-masked]
>(producing two application messages).

Oh! sorry. Just followed my own idea and I did not make it clear enough 
about transaction/cession. I do not make any difference between OPES 
processor and server and possibly clients. See my other mail. I consider 
dispatchers and services. I responded about the server changing or additing 
direction as simpler.

I am only cautious about telling I do want support your both cases, because 
I do not know which loop control you may have been discussed already. Also, 
I am glad you want to support smtp I was rebuked  not to consider http only.

Let assume that www.w3c.com says to redirect calls to www.w3.org and that 
www.w3.org says to redirect calls to www.w3c.com. What happens?

But I certainly want that that type of service (I am not really familliar 
with Internet protocols): is there a trick to achieve that today?

- I would love it for an application
- it would be a good case to say that OPES would make it a service rather 
than a trick.

My understanding of the client as part of the OPES system is because the 
client may interact with the OPES server. That traffic must be left open by 
the OPES processor and it muts have top priority.

Example: in this redirection case, the callout server sends back a question 
to the client: "this call will be rerouted are you OK?". The OPES may also 
be a gateway asking for an ID/password. Or a make a translation in an other 
language and to need some more information to perform (ex. the meaning of a 
word in a menu).

Thank you.
jfc

---

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 19 Feb 2003 13:37:16 -0700 (MST)

On Wed, 19 Feb 2003, jfcm wrote:

> Let assume that www.w3c.com says to redirect calls to www.w3.org and
> that www.w3.org says to redirect calls to www.w3c.com. What happens?

A loop detection code at the second hop would see its own Via: header
already in the HTTP headers of the request and would not forward the
request further, responding with an error. This is how redirections
(and loop detection) are supposed to work today.

This issue is not directly related to OPES except that OPES callout
server might participate in loop detection by adding its own Via
headers (or application-specific equivalent). I do not know whether
the current requirement/architecture drafts consider callout server a
"proxy hop" on the application protocol path. They probably should.

> But I certainly want that that type of service (I am not really
> familliar with Internet protocols): is there a trick to achieve that
> today?

You can certainly do the redirections today (any decent HTTP
intermediary can do that). Moreover, you can already do pretty much
anything on the traffic-modification level that OPES promises to
deliver! The reason we work on OPES is to provide a common interface
for "traffic modifiers" _and_ to address IAB concerns about them.

> My understanding of the client as part of the OPES system is because
> the client may interact with the OPES server. That traffic must be
> left open by the OPES processor and it muts have top priority.
>
> Example: in this redirection case, the callout server sends back a
> question to the client: "this call will be rerouted are you OK?".
> The OPES may also be a gateway asking for an ID/password. Or a make
> a translation in an other language and to need some more information
> to perform (ex. the meaning of a word in a menu).

My understanding is that OPES processor and callout server may
negotiate with each other, but may not negotiate with the data
producer or data consumer. Or, in other words, such "external"
negotiations are outside of OPES scope. However, OPES may document
application-protocol-specific(?) ways to [statically] specify data
producer's or data consumer's OPES preferences when making application
protocol transactions.

For example, a web browser may attach a "never translate the response"
OPES preference to an HTTP request, and that preference would get to
the OPES processor and/or callout server if they are in the path.

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

---

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 21 Feb 2003 10:29:10 -0500

see inline,

abbie

> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Wednesday, February 19, 2003 3:37 PM
> To: [email-masked]
> Subject: Re: OPES protocol, pre-draft
> 
> 
> 
> 
> A loop detection code at the second hop would see its own 
> Via: header already in the HTTP headers of the request and 
> would not forward the request further, responding with an 
> error. This is how redirections (and loop detection) are 
> supposed to work today.
> 
yes, in theory.

> This issue is not directly related to OPES except that OPES 
> callout server might participate in loop detection by adding 
> its own Via headers (or application-specific equivalent). I 
> do not know whether the current requirement/architecture 
> drafts consider callout server a "proxy hop" on the 
> application protocol path. They probably should.
> 

I think so, this should help in tracing/notification.

abbie

SNIP

abbie

---

From: "Martin Stecher" <[email-masked]>
Date: Fri, 21 Feb 2003 19:35:02 +0100

You are right.

Martin

> -----Ursprüngliche Nachricht-----
> Von: Alex Rousskov [mailto:[email-masked]]
> Gesendet: Freitag, 21. Februar 2003 19:23
> An: [email-masked]
> Betreff: RE: OPES protocol, pre-draft
> 
> 
> 
> On Fri, 21 Feb 2003, Abbie Barbir wrote:
> 
> > Let us be carefull here. So far my main concern with the proposed
> > protocol is that it looks a lot like ICAP.  The main scenarioes that
> > are solved so far are basically packaging (or passing )a request to
> > the callout server, with all the technicalities.
> >
> > We need to start thinking about scenarios that involves the user
> > preferences, that include the choice of obtaining a service from
> > more than one source etc..
> >
> > It is far too early to start even thinking about naming the OPES
> > callout protocol ICAP xxxx.
> 
> I agree with all of the above. The major challenges are still ahead.
> Message passing is just one (most performance-sensitive, but not the
> most difficult) part of the protocol.
> 
> Alex.
>

---

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 21 Feb 2003 14:34:17 -0500

Hi,
Thanks

abbie

> Sent: Friday, February 21, 2003 1:23 PM
> > preferences, that include the choice of obtaining a service 
> from more 
> > than one source etc..
> >
> I agree with all of the above. The major challenges are still 
> ahead. Message passing is just one (most 
> performance-sensitive, but not the most difficult) part of 
> the protocol.
> 
> Alex.
>

---

From: jfcm <[email-masked]>
Date: Sun, 23 Feb 2003 10:15:29 +0100

On 19:59 21/02/03, Alex Rousskov said:
>On Fri, 21 Feb 2003, jfcm wrote:
><offtopic>blame your mail agent instead, for not auto-filling both TO and 
>CC headers :-).
Sending at least one mail too much :-)

> > 2.  there is a smarter, pipe oriented, low cpu load approach with
> >      user interaction which corresponds to what I look for and which
> >      is actually like a network operating system.
>
>Perhaps it is just me, but I am still not quite sure what ONES is or
>should be. Could you please give two very specific, real-world ONES
>examples? Clearly, if there is a smarter, lower-load architecture we
>should at least consider it!

You ask two things.

- technical considerations: discussion about SOAP/noSOAP,
   redirecting or not. ICAP.2 etc. One vision is continuity with
   existing solutions, the other is a new vision related to a
   global optimisation..

- applications examples:
   - SMTP/FTP etc. support not HTTP to start with
   - redirects with request of agreement by the user
   - redirects/duplication upon thrid party decision (ex. write tapping)
    and all the interactions ONES/user/hosts/third parties.
    whicha re not from what I understand part of OPES.
jfc