Hi Alex,
Here are some comments:
0. Introduction
draft-ietf-opes-protocol-reqs-03.txt defines the following
information flow:
data provider --(original application message)-->
-- [ OPES magic ] -->
--(produced application messages)--> data consumers
I think both protocol requirements and architecture support OPES
processing in bi-directional message flow, both for data consumer
requests and data producer responses. This means that this diagram
and subsequent association of incoming message with the data producer
and outgoing message with the data consumer should be changed to
reflect the bi-directional nature of the OPES flow.
OPES processor and callout server exchange messages. The
exchange is bi-directional. There is no clear client or
server role. There is no clear request/response message
category either.
I do not agree with that. Per OPES architecture processing is initiating
by rules that are triggered by some event in the OPES flow (arrival of
request or response). As a result of some rule evaluation OPES processor
can make a request to OPES application (either in the same box or a callout
server). This creates a clear client-server roles: OPES processor makes a
request and callout server produces response.
OPES callout protocol should reflect these roles. Each transaction is
initiated by the client (OPES processor) and executed by the server
(callout server). There are certain message types that are produced by the
client and other (different) types produced by the server. Protocol state
transitions also should clearly reflect these roles. For example each
transaction starts from <xaction-start> message from the transaction client
and is terminated by <xaction-end> from the transaction server. BTW, my
initial
confusion was due to the absence of transaction roles. In bi-directional
exchange
without defined roles each side has to specify transaction boundaries, but
with predefined client-server roles it is enough to have one open and one
close message, as in your example.
Note that protocol requires definite roles only per transaction. Roles are set
by the opening message and may be different for different transactions.
For the OPES architecture when processing is initiated by incoming OPES
processor
messages (from producer or from consumer) OPES processor is always a client.
These
roles may be different only for metadata requests (e.g. callout server
requests
about consumer or provider preferences). But again each transaction has client
and server.
The question is: do we allow such requests in-band?
- Oskar