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

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

Alex, 

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

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

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> 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 
> "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.
> 
> 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
> > following:
> > 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 
> 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).
> 
> 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,
> 
> Alex.
>