Subject: RE: feedback: OCP version head_sid2 thread: Try 2

From: "Abbie Barbir" <[email-masked]>
Date: Sun, 6 Apr 2003 16:49:48 -0400

Alex,

my feed back on the draft attached

Abbie

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 7 Apr 2003 09:44:31 -0600 (MDT)

> 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.

---

From: jfcm <[email-masked]>
Date: Mon, 07 Apr 2003 20:39:24 +0200

>OCP point of view and not from the application "ends" point of view.

I understand that, everyone in here understand that, but think of the reader.

He will consider that "orginal" means "as initially entered in the OPES 
Processor" (I definitly hate that OPES Processor word for the dispatcher 
here, I do understand the other way around :-).

Could we not use someting as "out-bound" and "in-bound" IRT the used 
"call-out" protocol. It would be consistent. Also nothing prevents the 
returning in-bound message to be identical to the original if no change was 
performed.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 7 Apr 2003 13:40:49 -0600 (MDT)

On Mon, 7 Apr 2003, jfcm wrote:

> He will consider that "orginal" means "as initially entered in the
> OPES Processor" (I definitly hate that OPES Processor word for the
> dispatcher here, I do understand the other way around :-).
>
> "call-out" protocol. It would be consistent.

OK, it is a "choice of a word" question. I think it is very important
to use "right" words. Fortunately, it is easy to change the words in
the draft so we have time to find good ones. (I am more concerned
about the actual definitions and protocol specifics now.)

Anyway, since the communication is between two entities (OPES
processor and callout server), it is difficult for me to guess which
one is "out-bound". "Out" depends on whether you are looking from OPES
processor or callout server point of view. We already have
output/input for OPES processor, where there is no confusion since we
are talking about a single entity (the processor) in the middle of a
pipe.

Protocols often use request/response terms in these situations.
Perhaps we can use "request data" and "response data" instead of
"original" and "adapted"? I kind of like "adapted" though. It is the
"original" that's confusing.

More suggestions?

> Also nothing prevents the returning in-bound message to be identical
> to the original if no change was performed.

True, except, perhaps, for tracing requirements. Recall that "seeing
the application data" is a form of adaptation (by definition) because
if I can see it, then I can log it; and if I log it, then the user may
want to know my privacy policy.

If we ignore tracing issues, is there some wording that makes a reader
think that "something prevents returning identical messages"?

Alex.

---

From: jfcm <[email-masked]>
Date: Tue, 08 Apr 2003 11:45:36 +0200

>about the actual definitions and protocol specifics now.)

True. However I feel some wordings may have lead to some orientations.
I was refering to out-bound in the same direction and call-out.
What ever word is right and clear is good for me. But just think that
we will probably have many OPES acting in a daisy chain way
(to start with two your way OPES on the same flow : one on the
caller and one one the server side).

>are talking about a single entity (the processor) in the middle of a

In my own intuitive wording (sorry, I cannot keep thinking otherwise)
there is a dispatcher calling out on service processors.

>think that "something prevents returning identical messages"?

I do not think so, except a possible wording of "out-boud, in-bound"
chosen terms. Hence my remark.
jfc