On Sun, 6 Apr 2003, Abbie Barbir wrote:
my feed back on the draft attached
Thank you! I am incorporating the changes for the next release. Below
are questions/clarifications about the questionable items.
+---------+ [Abbie:or partially adapted] +-------+
| OPES | == (original data flow) ==> |callout|
|processor| <== (adapted data flow) === |server |
+---------+ +-------+
"Or partially adapted" is not necessary; the "original" term
definition already covers the "preprocessing" case:
original: Referring to application data or meta-data flowing from
the OPES processor to an OPES callout server.
adapted: Referring to application data or meta-data flowing from
an OPES callout server to the OPES processor.
That is, whatever OPES processor is sending is considered "original"
from OCP point of view.
When working on OCP, we need to try really hard to look at things from
OCP point of view and not from the application "ends" point of view.
Whatever the OPES preprocessor does before or after using OCP is out
of OCP scope. If we start bringing preprocessing and other
OCP-unrelated actions into the picture, we will make the protocol more
complex and will inevitably limit its application by restricting
things outside of its competence. This is not "The OPES" protocol.
This is just an OCP protocol. It has very specific goal and scope.
OPES processors do not have to use OCP to adapt application messages.
<20>
OPES processor establishes OPES connections with callout servers
for the purpose of exchanging [Abbie: OCP messages] application
messages and meta-data with the callout server(s).
The purpose is to exchange application messages. OCP messages are just
"means" of doing that.
The OPES processor then builds meta-data and forwards meta-data
and complete or partial application message data to the callout
server (original [Abbie: can also be partially adapted, example
translate English to German and then use callout server to do
text to audio] data flow).
Translation at the OPES processor is out of OCP scope. Please see my
rant above.
For the purpose of OCP, the result of OPES processor's
preprocessing is still an application message
[[Abbie: not needed here if we just clarify what OCP messages are
from the
start].
This is not about OCP messages, this is about application messages
(the definition of which does need an improvement). I will add
"original" before "application message" to clarify/emphasize the
intent.
Naturally, OPES processor and associated callout services must
agree on what application messages are acceptable (see section
XXX for information on OCP negotiations) [Abbie:Need to specify
negotiation here].
We probably should wait for negotiation details to become available:
There may be too much stuff to insert here and a dedicated section may
be more appropriate.
<21>
The callout server receives data and meta-data sent by the OPES
processor ([Abbie: Not really in the genral case]original data
flow).
Not sure what you mean, but probably the same thing as above --
preprocessing is out of OCP scope; "original" from OCP point of view,
not from application point of view. Suggestions for better terms than
"original" and "adapted" are very welcome!
The callout server analyses meta-data and adapts data as it comes
in. The server usually builds its version of meta-data and sends
adapted data back to the OPES processor as soon as possible
(adapted data flow). [Abbie: Are we ruling out the possibility
that the OPEs processor will send HTTP redirect to the client and
asks the callout server to adapt the connection, for example an
adapted stream for low bandwidth]
I do not see why we are ruling out any possibilities at this point.
Can you clarify, including the "adapt the connection" part?
[Abbie: How about if we classify messages as control and data
related]
I did that at some early stage, but deleted the results because:
- many messages cannot be clearly labeled as "control"
or "data related". For example, a 'data-pause' message
is both control and data related (it controls data flow).
- it is not clear how such classification will help
anybody
<30>
A OCP transaction starts with a explicit 'xaction-start' message
sent by the OPES processor. A transaction ends with the first
'xaction-end' message, explicit or implied, which can be sent by
either side. Zero or more OCP messages associated with the
transaction can be exchanged in between.
[Abbie: We need a flow diagram here with may be a table that shows
the interaction, I also suggest the use of a message structure (a
figure) that shows the overall general format of a message]
I will add a figure showing the nesting of messages. However, we
cannot document any message structure now because we did not decide on
transport/encoding issues yet. There is no message structure yet,
except for the required message name and a list of optional/required
parameters.
4. Connections
<31>
OCP connection is a logical abstraction representing a stream of
possibly interleaved OCP transactions and transaction-independent
messages. Connections allow for efficient handling of state
common to several OCP transactions, including processing
prioritization.
<32>
(XXX: OCP transport binding(s) will determine how callout
connections are mapped to transport connections. For example, if
raw TCP is the transport, than a TCP connection will correspond
to a callout connection. If BEEP over TCP is used, than a BEEP
channel will correspond to a callout connection, allowing callout
connection multiplexing over a single TCP connection.)
[Abbie: How does this relate to a session? I think we should use a
session as opposed to a connection, since a session can have
multiple connections???]
What is a session? Please use terminology from the
architecture/requirements drafts or define a new term. I do not see
any references to "sessions" in the architecture or requirements
draft. Is it defined elsewhere?
5. Message Parameter Definitions
[Abbie: General remark on the whole section: It is still look weak
and not easy to read at all, we really need to have a figure or a
atble that shows how a message look like and the various parameters,
we need better description of why things are needed and how it is
used, I could see that the reader that was not involved in OPES list
will find this section very confusing]
This section does not show how a message looks like because it
documents message parts. I will add illustrations to the "2. Messages"
section. Note that "6. Message Definitions" subsections already have
illustrations for every message. See above regarding message format
unavailability.
I agree that this (and all other) sections need a lot of polishing, of
course. Specific improvements are welcome :).
client: An OPES processor description. The description MAY be
used by callout server for logging and similar informational
purposes.
[Abbie: do u mean an OPES processor ID]
Possibly, but I do not know yet. We need to discuss this. Is passing
an ID enough? Is it possible that the callout server may need more
information about the OPES processor? Negotiation work may clarify
some of this.
6. Message Definitions
<52>
[Abbie: General remarks as in section 5]
Yes, same response.
Again, I will incorporate all other fixes shortly. The above mentioned
ones need more clarifications/discussion.
Thank you,
Alex.