I would like to suggest that we need general framework(s) for tracing
and user preferences processing before we go into designing specific
protocols, especially if we want to add extensions to [many] existing
protocols. We must document what needs to be passed around and what
the reaction on that information should be. Given such a framework,
implementation in any specific protocol (new or old) would be a
mundane task:
- what is addressable?
- what is traceable?
- can tracing info be aggregated/modified?
- do we need information authentication?
- can end-point affect the extent of tracing?
- what is the default behavior?
- etc.
All of the above has little dependency on the application protocols
and, IMO, should be decided/documented first. The existings drafts do
not cover these decisions well enough.
Specific remarks are below.
On Wed, 12 Mar 2003, 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).
That seems like the right way to proceed given that many protocols use
similar extension mechanism (e.g. MIME or XML). One does not need to
start from scratch for every new application protocol, just for every
new extension scheme.
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.
Synchronization issues with out-of-band and application protocol may
prohibit you from supporting (2) efficiently. Also, it is usually
easier in practice to add support for an extension than for a new
protocol.
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.
This is debatable and probably protocol-specific. For example, it is
usually _more_ overhead to supply state in HTTP because HTTP is
stateless and can be proxied. Parsing a couple of simple extension
headers with every transaction is much simpler and robust approach
with HTTP, without noticeable performance penalties.
Are there any application protocols that natively support "state
management" on the intermediaries, across isolated transactions?
Alex.
-----Original Message-----
From: Barbir, Abbie [CAR:1A00:EXCH]
Sent: Wednesday, March 12, 2003 9:06 AM
To: Markus Hofmann; OPES Group
Subject: RE: Draft Agenda for IETF 56
Markus,
it all do with HTTP extension etc.
I will detail later,
abbie
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Wednesday, March 12, 2003 8:28 AM
To: OPES Group
Subject: Re: Draft Agenda for IETF 56
Abbie Barbir wrote:
At this point, the issues of notification/tracing have not been
brought up (yet?).
Absolutley correct and an important point!! Is there anything me must
consider in the callout protocl design for tracing and
notification? I
would assume so... Any thoughts?
While probably separate from the callout protocol design, we
also need
to discuss possible impact on the application message protocol, for
example for an "OPES bypass" mechanism. This refers to the
requirement
that a user must be able to signal an OPES processor that (s)he wants
to bypass any OPES service (one of the IAB requirements) -
as briefly
discussed some time earlier, using (user-defined?) HTTP headers might
be an option.... So we also need to consider possible
impact/extensions on the application message protocol. Anyone some
thoughts on this one?
-Markus