Subject: RE: Draft Agenda for IETF 56

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 11 Mar 2003 10:22:16 -0800

If I remember correctly the decision reached some time ago during a
conference call was that the callout transport protocol would be the same
one used between user<----...OPES box....--->consumer

Not sure if we updated the protocol requirements draft accordingly. Actually
there was a section on transport negotiation that we took out because some
believed it had too many borderline cases. Because there is no transport
negotiation anymore we decided to go with the approach I described earlier.

Regards,

Reinaldo

-----Original Message-----
From: Alex Rousskov [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2003 12:06 PM
To: OPES Group
Subject: Re: Draft Agenda for IETF 56

On Mon, 10 Mar 2003, jfcm wrote:

> My main question is about the entry and the ending points of the OPES 
> concept. If it is accepted that not only HTTP but any protocol is OK, 
> and that alternatively both end points can be user/producer or that we 
> may have a peer to peer support, it will mean that any entry/output 
> protocol is OK, including a keyboard/user file/application etc, 
> towards a screen, a file, etc.
>
> This means there is no pseudo-synchoronous (like in hhtp) obligation 
> (or as options). This means that we have a general purpose concept of 
> a filter/transformer system on a flow. Which will standardize 
> everywhere.
>
> This means that, the filter/transformer relation (callout protocol) 
> can be anything from realtime to soap. Am I correct?

I doubt we can design a good OPES system that can support adaptation of
anything from highly optimized realtime protocols to structure-rich, super
extensible XML protocols. There will be tradeoffs that we will have to
resolve one way or the other. That is why it is important to agree on scope
and use cases up-front.

> Because this means that we will have a good general framework for a 
> protected/acked balanced protocol able to support one to many or even 
> many to many relations.

We should strive for that, but IMO we will come short as things get more
specific.

> Then the next question will be: will it always be under TCP?

Transport protocol binding wise, TCP is probably not the only option. We do
need a reliable, order-preserving, congestion-aware protocol though (see
protocol requirements draft for details). These features may already exclude
certain realtime optimizations where losing packets is not only acceptable
but desirable in the presence of unexpected delays or congestion.

An important design question is whether the OPES protocol should allow
multiple transport bindings/encodings or just one.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 11 Mar 2003 11:31:24 -0700 (MST)

On Tue, 11 Mar 2003, Reinaldo Penno wrote:

> conference call was that the callout transport protocol would be the
> same one used between user<----...OPES box....--->consumer

Reinaldo,

	I am confused: Callout protocol is the one OPES dispatcher
uses to talk to the callout server. Why do you have "user", "OPES
box", and "consumer" in your picture if you are talking about the
callout protocol? The callout protocol is used _inside_ the OPES box,
not outside it, AFAIK.

Did you mean application protocol instead? If so, would it be accurate
to say that the conference call resulted in a decision to prohibit
application protocol conversion by OPES (e.g., converting HTTP to
FTP)?

Please clarify or point to the relevant documents. BTW, were the
conference call minutes posted on the list?

Thank you,

Alex.