ietf-openproxy
[Top] [All Lists]

RE: OPES protocol, pre-draft 01

2003-02-24 14:53:30



-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex 
Rousskov
Sent: Monday, February 24, 2003 1:23 PM
To: OPES WG
Subject: RE: OPES protocol, pre-draft 01



On Sat, 22 Feb 2003, Oskar Batuner wrote:

[skip]

For example each transaction starts from <xaction-start> message
from the transaction client

Yes.

and is terminated by <xaction-end> from the transaction server.

This restriction is unnecessary and cannot be derived from the
client-server model. It is perfectly normal for a client-server
protocol to allow either side to terminate the transaction. Usually,
the transaction will be terminated once one party signals the "end"
and the other side receives that signal. In some protocols (e.g.,
SSL/TLS) the end of a transaction is a much more complex event.

In OPES context, the client (OPES processor), may terminate the
transaction by sending a <xaction-end> message to the callout server.
The callout server might send that message first (probably only under
unusual conditions like overload). The two sides might even send
<xaction-end> concurrently!

Also, please note that OPES protocol has to deal with three kinds of
"end" messages:
      - end-of-data from the data source
        (does not imply that the work on the application message is
        done)
      - end-of-work for the application message
        (implies end-of-data but does not imply that the work on the
        application transaction is done)
      - end-of-work for the application transaction
        (implies end-of-data and end-of-message)


Here I'm looking at transaction boundaries that are defined by
<xaction-start> and <xaction-end>. You are right that in general
it is not necessary to limit the right to terminate transactions to
the server. But in the OPES case

... processing is initiated by incoming
OPES processor messages (from producer or from consumer) ...

In such context OPES server has no apparent reason to terminate message
processing - there are no possible events associated with this transaction
coming from the OPES flow. After initial message is received and service
is initiated only service application (in this case callout server) knows
that transaction processing is finished. At least for the normal processing.
There may be abnormal situations (e.g. OPES data consumer has closed the
connection) when OPES processor becomes not interested in processing results
and may wish to stop request processing to avoid resource wasting.

Maybe we should have a special message for abnormal transaction termination?

The question is: do we allow such requests in-band?

If I understand the question correctly, this is purely an OPES
connection management issue. We can, for example, mark some
connections "for management messages only" by sending a special
message on that connection once the connection is open by the OPES
processor. Does anybody have a preference/recommendation? Should
transaction-independent messages be isolated to their own OPES
transport connections? If yes, should this be a MAY for OPES processor
to decide or a MUST that all processors will follow?

In the architecture draft we are always separating OPES flow from
the metadata exchange. We state that metadata transfers are out-of-scope
for the OPES architecture. Of cause this statement does not preclude
using the same callout protocol - or any other - for the metadata
transfer. But if we permit mixing OPES data and metadata (like
preferences, etc.) on the same channel - well, this looks at least
inconsistent.


My suggestion is that it make it a MAY. I do not see a reason to
mandate presence of control-only (out-of-band) connections, but I can
see a reason to have such connections for priority message handling.


Oskar