Subject: feedback: OCP version head_sid2 thread: Try 2

From: "Abbie Barbir" <[email-masked]>
Date: Sun, 6 Apr 2003 15:31:12 -0400

Hi, 

PS: The previous e-mail was sent before I finished typing the full message.
I just hit the send button as opposed to the save one. 

So here is the full feedback

This is the feedback on the head-si2 ocp draft.

1. 
application message: A sequence of octets that OPES processor
      designates for callout service processing or a sequence of octets
      that callout server sends back to the OPES processor.  Usually, an
      application message is the basic unit of application protocol
      communication, as defined by that application protocol (e.g.,
      HTTP/1.1 message). (XXX: This definition is bad because OCP
      messages themselves are also sequence of octets that OCP agents
      send to each other.  How to distinguish "OCP" from "application"
      if we do not have an application data definition?  What we want to
      say is that application message is whatever an OCP agent has
      marked as such. How to say that?)

I still do not like this defintion at all.

An application message is still an application message whether OPES
processor will send it to the callout server or not. We need to remember
that in some cases the OPES processor will do all the work and if a trigger
happens such as CPU watermark, the processor will use the callout server as
an additional helper.

Furthermore, The OCP should be application agnostic, here I think we should
differentiate between the following:

 Application  +---------------+   OCP Message    +----------------+
 Protocol --->| OPES Processor| ---------------> | Callout Server | 
 Message <--- |               | <--------------- |                |
              +---------------+                  +----------------+

In this regard, it is possible to have only one OCP binding to TCP/IP
regardless of the Application layer Protocol

The same thing can happen for data

 Application  +---------------+   OCP Data       +----------------+
 Protocol --->| OPES Processor| ---------------> | Callout Server | 
 Data    <--- |               | <--------------- |                |
              +---------------+                  +----------------+

The arrow can be uni or biderectional ( in the general case).

In some cases, the OPES processor can infere the adaptation that is needed
from the application message and send a service request to the Callout
server. For example:

1. Service Type: Crop image to QCIF size and make it B/W
2. Here is the URL for the image.

These cases need to be identified in the definition of messages.

So I think that in the general case an OCP message can be one of the
following:
1. Identical Application message (just forwarded)
2. Partial Application message with some modification
3. A message that is infered from an Application message.

Thus, we should make distinction about an OCP message and an application
message.

So here is my proposal:

1. Application message:
A sequence of octets that OPES processor accept for further processing by
itself or with the additional help from a callout server. Usually, an
application message is the basic unit of application protocol communication,
as defined by that application protocol (e.g.,HTTP/1.1 message). 

2. application message data: 

A sequence or subsequence of application message octets. Application message
data may correspond to an application message fragment or may cover an
entire application message. OCP treats application message data as opaque
sequences of octets. Application message data may be empty.

Need to introduce the following

3. OCP Message:
A sequence of octets that OPES processor use to communicate actions required
on Application level messages to callout server. The callout server also
uses OCP messages to communicate results back to the OPES processor. In some
cases, the OCP message may be identical to the Application level message.
However, in some other cases the OCP message can be a partial Application
level message or generated entirely by an OPES processor.

4. OCP Data:
OCP Message Data: 

Fix the original definition to reflect OCP message.

More feedback will follow

Regards
Abbie

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 6 Apr 2003 14:14:40 -0600 (MDT)

On Sun, 6 Apr 2003, Abbie Barbir wrote:

> processor will send it to the callout server or not. We need to
> remember that in some cases the OPES processor will do all the work
> and if a trigger happens such as CPU watermark, the processor will
> use the callout server as an additional helper.

It is even worth than the above. We should try really hard to keep OCP
independent from the application (and, hence, application messages).
It is very important to do that to make OCP more "agnostic".

As somebody said on this list before, OCP should not care what the
application message is. The difficult part is that OCP has to identify
application messages without carrying what they are. That is what I
meant in the above XXX comments. OPES processor decides what an
"application message is". OPES processor may decide to forward true
application message "as is". It may decide to extract the payload and
forward just that. Or it can apply 100 transformations, change the
application protocol and encoding, and only then subject the
"application message" to OCP processing. The callout server can do
exactly the same, regardless of what the OPES processor did!

How do define that? The current definition defines it, but it makes no
distinction between "data octets" (which are application message
data) and "OCP octets" (which are OCP message structures). That is
what needs to be fixed.

>  Message <--- |               | <--------------- |                |

Sure, that's understood and is not the problem. Note that, from OCP
point of view, your leftmost part (Application Protocol Message) does
not exist.

>  Data    <--- |               | <--------------- |                |

There is no "OCP data", really. There is only application data
(original or preprocessed or adapted).

> 1. Identical Application message (just forwarded)

No, that cannot be an OCP message, only OCP message payload. OCP is a
protocol, it cannot forward application messages without wrapping them
in OCP headers/structures.

> 2. Partial Application message with some modification

Probably same problem as above unless adding OCP headers is "some
modification". Application message can only be OCP payload.

> Thus, we should make distinction about an OCP message and an application

We should, but that it easy. Nobody is going to confuse OCP messages
from application messages.  OCP defines OCP messages. The problem is
to define application message so that implementors know what they can
pass across OCP and what can they identify using am-id. That is very
important.

> as defined by that application protocol (e.g.,HTTP/1.1 message).

Not good. The application message definition cannot involve
"additional help from a callout server" because that implies using OCP
to get that "help" and one cannot use OCP until the application message
is defined (OCP does not exist yet).

> level message or generated entirely by an OPES processor.

This does not work for the above reasons, but the standard definition
in the current draft should be OK (it could be moved to the
definitions section). Again, the problem is with defining what
application message is without just saying "anything that OCP agent
sends" because the latter includes "OCP messages". See what I am
getting at? I know I am not explaining it well enough.

Thank you,

Alex.