-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Wednesday, March 12, 2003 11:33 AM
To: OPES Group
Subject: Re: Draft Agenda for IETF 56
Reinaldo Penno wrote:
I guess there are two approaches here:
1) Making extensions for every single application protocol
that might
use OPES.
...Although some people that in realitly we will have
maybe 4 (HTTP,
RTP, SMTP, FTP).
Just a reminder - although we've a SHOULD requirement that
states that
our solutions should be protocol agnostic (and I think we all
agree on
that), our charter is focused on HTTP (and RTP, although we
agreed the
main focus being on HTTP).
Yes, I was pointing out some issues that could influence the protocol choice
(in vs out of band). Although we can make HTTP work, it *might* be waste of
cycles if we foresee the use of other protocols in the future and
using/designing a general out of band protocol is not that much extra
effort.
This is the kind of tradeoffs we should discuss before actually making a
choice of in vs out of band. And I agree we should discuss
functionality/requirements wihthout a specific solution in mind.
2) Developing an out of band protocol to signal such preferences.
That's why I said in the past looking at NSIS could be
interesting if
we feel the list in 1) is already big/complicated enough or might
grow.
There is also the practical uses of either approaches. Certainly,
negotiating with the OPES processor what will/not receive treatment
every single HTTP session could add a lot of overhead.
Although HTTP
could be used to negotiate, I guess we should have
provisions to say
"bypass OPES for all HTTP sessions, until I say otherwise", or
vice-versa.
I'd suggest we go down a similar path as we currently do with the
callout protocol, namely discussing required functionality
and general
design issues, first (rather than starting to discuss how and
in which
specific form to do it). I.e. what exactly do we need to signal (one
example is the "OPES bypass"), what are the interaction schemes, what
needs to be signaled, etc. Then we can discuss what's the best way to
do this (e.g. "in-band" vs. "out-of-band") etc. [Note: Just to avoid
confustion - this is *not* about the callout protocol, this is about
the application protocl path).
Maybe Abbie and Reinaldo you want to take a first shot, since
you seem
to look at this from slightly different perspectives. Of course,
anyone else should feel free to take a first step as well...
Okay. Abbie and I will take a first shot on this...
-Markus