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:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
> 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.
>