FW: feedback: OCP version head_sid2 thread: Try 2
2003-04-06 17:00:29
-----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(_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".
|
|