FW: feedback: OCP version head_sid2 thread: Try 2

> > -----Original Message-----
> > From: The Purple Streak, Hilarie Orman 
> > [mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
> > 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".