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

From: "Abbie Barbir" <[email-masked]>
Date: Sun, 6 Apr 2003 17:04:36 -0400

Hi,

See remarks inline

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".
> 
Abbie: Agreed

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

Abbie: Yes, that what I was trying to stay by seperating the OCP message
from the Application message for a given protocol. The way I see it is that
if a session is opened between the OPES processor and the callout server,
that session is related to the supported application protcol. The indication
of what the application protocol should be is done at setup!!!!!

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

Agreed. That is used for illustration purposes.

> 
> > 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).
> 
NOP. This is data that is associated with an OCP message, regardless of
where the data was originated from (at the higher level).

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

Abbie: That is a given, Sorry if I did not spill it in detail.
Same applies for next remarks.

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

Abbie: Kind off, It is not clear. I still disagree, it does not cover case
3.

Abbie

---

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

On Sun, 6 Apr 2003, Abbie Barbir wrote:

> Abbie: Yes, that what I was trying to stay by seperating the OCP
> message from the Application message for a given protocol. The way I
> see it is that if a session is opened between the OPES processor and
> the callout server, that session is related to the supported
> application protcol. The indication of what the application protocol
> should be is done at setup!!!!!

Yes, that is what Reinaldo Penno is working on right now.

> > application message data) and "OCP octets" (which are
> > OCP message structures).

Yes.

> where the data was originated from (at the higher level).

Well, yes, but this is only a question of a definition. We can have
"application data" and "OCP data" and then define a relationship
between the two. Alternatively, we can have "application data" only
since any "data that is associated with an OCP message" is (by
definition) "application data". The latter is the current, perhaps
inferior, approach.

Once we have a good definition for "application message", it should
become less messy.

Thanks,

Alex.