ietf-openproxy
[Top] [All Lists]

RE: Draft Agenda for IETF 56

2003-03-12 15:18:17

On Wed, 12 Mar 2003, Oskar Batuner wrote:

For that matter I'd suggest that callout processor should not be
able to communicate with OPES participant directly, only through
OPES server. This will provide the required level of isolation. OPES
processor may use callout protocol to communicate certain requests
to callout processor and send responses back to the user/server.

On the other hand, callout servers already communicate with ends, by
modifying application messages (which is their primary purpose)!

And they send these messages ONLY through the OPES processor. My point
is that as OPES processor is the principal point of contact between
OPES flow ends and the OPES application it should be the only
point exposed to the end user/server.

Two problems:

    - It looks like Markus (and others?) want callout servers and
      even services be traceable and, hence, exposed to the ends to a
      certain degree. We will need to get some consensus here.  What
      is exposed to ends? If something is exposed, does it communicate
      with ends? If it does, what "band" is used?

    - If callout servers communicate with ends via application
      protocol (by modifying application messages), then
      "communication through OPES processor" does not mean that the
      OPES processor actually understands what is going on. The OPES
      processor, in this case, may be a dumb relay. I think that
      contradicts your intention to have "required level of
      isolation". Dumb relay is a poor "isolator".

      If we do want to make OPES processor the only point of contact
      and truly remove callout servers from the end-visible picture,
      we need to do the following, at least:

        ~ adjust processor->callout server interface from current
          "do whatever you want with this message, I will just
           forward the result; and please obey OPES rules
           (e.g., add tracing)"
          to
          "do whatever you want, tell me what
           you did, I may apply more processor-specific modifications
           based on what you did (e.g., add tracing), and I will
           build and forward the final result"

        ~ prohibit delegation of callout services from
          callout servers; support such delegation from OPES processor
          only (the callout server would have to tell OPES processor
          to delegate)

      Is that something you are after? Do you want to limit
      callout server role to message adaptation only and have
      _all_ OPES-related features to be enforced by the OPES
      processor?

Distribution of OPES application functions between components may
even change dynamically as adaptation to the load conditions.

Yes, of course.

If you have a single user contact point this may scale pretty well,
otherwise the user has to be involved in the process in which he/she
is not interested at all - function distribution between OPES
components.

The user does not have to be involved in the process if her
preferences remain constant. It is the role of the OPES system to
correctly react to dynamic changes within the OPES system. Are you
implying that the user may have different preferences depending
on the actual OPES system in use?

Thanks,

Alex.


<Prev in Thread] Current Thread [Next in Thread>