> -----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:ho@xxxxxxxxxxxx]
> > 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".
> >
> >
> >
>