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

From: "Abbie Barbir" <[email-masked]>
Date: Sun, 6 Apr 2003 20:00:23 -0400

> -----Original Message-----
> From: Barbir, Abbie [CAR:1A00:EXCH] 
> Sent: Sunday, April 06, 2003 5:46 PM
> To: 'The Purple Streak, Hilarie Orman'
> Subject: RE: feedback: OCP version head_sid2 thread: Try 2
> 
> 
> Hilarie,
> 
> Thanks, sounds much better now (I will respond once I digest it more).
> 
> Regarding,
> 
> Question: MUST all the messages forwarded from an application 
> connection be on the same OCP connection?  I can't determine 
> this from the requirements doc.
> 
> You are right, it is not clear, even the definition of a 
> connection is not clear, since it sounds like a session to me.
> 
> For the sake of simplicity ( I am trying to be careful here 
> with the choice of words) I think we should state the same 
> connection. I am sure though that others will disgaree, which 
> means more state keeping (keeping track of message id/fragments etc..)
> 
> Abbie
> 
> 
> > -----Original Message-----
> > From: The Purple Streak, Hilarie Orman [mailto:[email-masked]]
> > Sent: Sunday, April 06, 2003 5:41 PM
> > To: Barbir, Abbie [CAR:1A00:EXCH]
> > Subject: Re: feedback: OCP version head_sid2 thread: Try 2
> > 
> > 
> > I agree that the definition needs reworking, but I didn't
> > understand your comment about "one OCP binding to TCP/IP 
> > regardless of the Appplication layer Protocol."
> > 
> > Here are my suggestions for rewarding the opening ... I think
> > this addresses some of the concerns.  Note the questions at the end.
> > 
> > Hilarie
> > 
> > =========================================================
> > 
> > The normal processing OPES processing is a loop in which the
> > OPES processor sends application messages to the callout 
> > server using OCP and the callout server returns those 
> > messages, possibly modified, using OCP.  This is sometimes 
> > called a "bump in the wire" architecture.  The application 
> > messages are augmented with metadata, some required by OCP, 
> > and some encoded by private convention between the two 
> > processors.  OCP is not required to use application message 
> > framing boundaries when forwarding messages, though the 
> > original framing boundaries can be indicated by the OCP 
> > metadata.  OCP may also use messages without any application 
> > message data.  OCP has no requirements about application 
> > message reframing, re-ordering, or reconstructing the 
> > original application messages.  
> > 
> > An OPES processor is at liberty to choose which application
> > messages or data about them to send over OCP.  All data on 
> > all connections, or everything on some connections, or 
> > selected parts, or nothing might be sent over OCP.
> > 
> > OCP communications are primarily about analyzing and/or
> > modifying application messages, including the application 
> > message headers and the application message payloads.  
> > However, it is possible for OCP to carry only metadata about 
> > an application message. OPES metadata can also contain 
> > information about the connection between an application 
> > endpoint and the OPES processor.
> > 
> > The two processors may exchange data related to their
> > configuration, state, and connections (to each other and to 
> > applications).  These messages are OPES messages and are 
> > specified by this protocol (OCP).
> > 
> > A single OPES processor can communicate with many callout
> > servers and vice versa.  The OPES architecture [OPES-ARCH] 
> > describes the configuration possibilities.
> > 
> > OCP is application agnostic but it is not suitable for all
> > applications.  The OPES metadata can carry application 
> > specific information.
> > 
> > Question: MUST all the messages forwarded from an application
> > connection be on the same OCP connection?  I can't determine 
> > this from the requirements doc.
> > 
> > Question: Should we be more careful about the notion of an
> > application message (header and payload), applicaton message 
> > transmittal unit ("chunk"), and application/OPES connection?  
> > For my own part, I'd find it helpful if people would use 
> > standard terms for these, because it's so easy to become 
> > confused about which part is meant.  Usually it doesn't 
> > matter for "messages", so I think we also need a term meaning 
> > "anything sent on the application connection".
> > 
> > 
> > 
>

---

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

> > connection is not clear, since it sounds like a session to me.

What is not clear about the OCP connection definition? We should fix
whatever is broken.

We can change "OCP connection" to "OCP session"; the only reason the
draft says "connection" is because that is what OCP requirements draft
uses. Should we ignore this minor discrepancy if "session" is more
appropriate?

> > means more state keeping (keeping track of message id/fragments etc..)

Actually, for the sake of simplicity, we should not explicitly try to
adapt application connections. Adapting application connections would
be the only reason to talk about them in the OCP context. Then we
should talk about adapting other application-specific things like
sessions, caching, etc.

The current intent is for OCP to facilitate adaptation of application
message data and metadata. The metadata hides all application-specific
things like source IP, session ID, or "connection". That's the beauty
of the design, we just need to document/explain it better.

Alex.