[Top] [All Lists]

RE: feedback: OCP version head_sid2 thread: Try 2

2003-04-06 13:45:20

I know that comming up with a definition is hard,
so we are still at square one !!!!!!!!!!!!!!!!!!!!!!!.

Ha ha ha.............


-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com] 
Sent: Sunday, April 06, 2003 4:15 PM
To: OPES Group
Subject: Re: feedback: OCP version head_sid2 thread: Try 2

On Sun, 6 Apr 2003, Abbie Barbir wrote:

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

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.

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

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.

The same thing can happen for data

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

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

So I think that in the general case an OCP message can be one of the
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.

3. A message that is infered from an Application message.

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

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.

So here is my proposal:

1. Application message:
A sequence of octets that OPES processor accept for further 
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 

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

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.

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,