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

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

> > -----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:27:13 -0600 (MDT)

> > > this addresses some of the concerns.  Note the questions at the end.

<snip>

Good stuff, thank you! I would just polish the parts that imply that
OCP deals with application message modification (it does not, the
protocol just shovels data and metadata between the two agents,
essentially). You should expect this text in the next draft version
(tomorrow?).

> > > this from the requirements doc.

You cannot determine this because there is no such rule/implication.
There is no required relationship between OCP connections and
application connections. The latter may not even exist!

We cannot document all non-existing rules, of course, but I will add a
note to avoid any confusion.

> > > transmittal unit ("chunk"), and application/OPES connection?

Yes, this is what this thread is about! How to define what an
application message is given that the definition is really up to the
OPES processor _and_ the callout server. I will try to polish some
more to say just that.

> > > "anything sent on the application connection".

Application connections are out of OCP scope. In some environments,
they might be referred to in metadata, but metadata is opaque to OCP.

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 7 Apr 2003 11:09:18 -0600 (MDT)

> Question: Should we be more careful about the notion of

> an application message (header and payload),

OCP does not distinguish between application message header and
application message payload. OCP treats the entire message as an
opaque sequence of octets. Should we explicitly state that "header"
and "payload" are not visible to OCP?

> applicaton message transmittal unit ("chunk"),

I think WG drafts use the term "fragment" instead of "chunk". Fragment
may be preferred to avoid collision with HTTP chunked encoding (OCP
fragment may spawn HTTP chunk boundaries, of course). Comments?

Note that OCP does not use "fragment" much. OCP mostly uses "data"
which stands for both a "application message fragment" and a "complete
application message". Suggestions for a better term to describe both
complete and partial application messages are very welcome.

> and application/OPES connection?

Application connections are out of OCP scope. Should we state that
explicitly?

There are no OPES connections, but Hilarie is probably talking about
OCP connections. Abbie suggests to rename OCP connections to
"sessions". Which term would you prefer?

> 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.

Yes, we just need to agree on the "standard".

Thanks,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 07 Apr 2003 14:09:48 -0400

> "sessions". Which term would you prefer?

The protocol requirements draft only talks about "connections", and 
not about "sessions". Unless something different is refered to, I 
would suggest to stick with the terminology we've in the existing drafts.

Thanks,
   Markus

---

From: jfcm <[email-masked]>
Date: Mon, 07 Apr 2003 21:16:05 +0200

>and "payload" are not visible to OCP?

YES. Everything which clarfy what we talk about is an absolute need.

>complete and partial application messages are very welcome.

Data seems appropriate. However this remark seems of interest to quote.
In the Minitel X.25 system for example I am investigating, the size of the
Message may be of interest if it is smaller than the X.15 window size. It
may make the transfer extremely fast.

>Application connections are out of OCP scope. Should we state that

ABSOLUTELY. For the same reasons.

>"sessions". Which term would you prefer?

Would these sessions represent the whole message transiting
through OCP towards as many services as required ? If yes I
would accept the concepts. Interaction otherwise? A session
would be all the OCP interactions that a message may perform
from the dispatcher to services until sent to the user. So you
could talk of the OPES session. Makes sense in French, but I
do not know if it is the same in English.

>Yes, we just need to agree on the "standard".

You sure you want to use OPES Processor the way you do?
For me it is opposed to every standard thinking I know.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 7 Apr 2003 13:53:31 -0600 (MDT)

> YES. Everything which clarfy what we talk about is an absolute need.

Will do.

> may make the transfer extremely fast.

OCP can relay OCP application message size via size parameter and
input/output application message size via meta-data. I am not sure how
your remark relates to OCP though. Please clarify.

> ABSOLUTELY. For the same reasons.

Will do.

> Would these sessions represent the whole message transiting through
> OCP towards as many services as required ? If yes I would accept the
> concepts. Interaction otherwise? A session would be all the OCP
> interactions that a message may perform from the dispatcher to
> services until sent to the user. So you could talk of the OPES
> session. Makes sense in French, but I do not know if it is the same
> in English.

If "many services" are on different callout servers, then your
definition of "session" makes sense, but seems to be out of OCP scope
since OCP is concerned with single processor - single server
communication. If the services are on the same callout server, then
your "session" would be in OCP scope. It would be something that may
cross OCP connections even. I am not sure why we would need it though.
To be able to abort easier?

> For me it is opposed to every standard thinking I know.

Not sure what you mean. OPES processor is just an application proxy
that outsources processing of some messages. Sounds pretty "standard"
to me. Is it not?

Thank you,

Alex.

---

From: jfcm <[email-masked]>
Date: Tue, 08 Apr 2003 11:38:23 +0200

At 21:53 07/04/03, Alex Rousskov wrote:
>If "many services" are on different callout servers,

I did not say "many services" but "as many services as required".
- if there is one or there are ten this makes no difference
- there must be no asumption of where a service process is located.

>then your definition of "session" makes sense, but seems to be out of OCP 
>scope since OCP is concerned with single processor - single server 
>communication.

Tracing should keep track of previous OPES applied to the message. To 
prevent loops. This builds the concept of a session (exit the session in 
case of loop).

>If the services are on the same callout server, then

The question was about using the word session to another end. I explained 
what "session" meant to me, and I think it makes sense and can be used. 
Abort is one reason I quoted, yes. There may be others like to understand 
the order of the previously applied services, etc.

>that outsources processing of some messages. Sounds pretty "standard"

Documented that already. To me a a processor is where an process occurs. An 
OPES is a service. So to me OPES Processor is where the service process 
occus, ie on what you call the call-out server. On what you currently call 
the OPES Processor only happen the dispatch of the call-outs.

An addition confusion is if I use another archtecture than the 
dispatcher/call-out to implement OPES. I will use daysy chained OPES 
Porcessors where the servies will be provided if some conditions apply.

jfc

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 8 Apr 2003 06:50:20 -0600 (MDT)

> >scope since OCP is concerned with single processor - single server

Please reread what I wrote. I am simply saying that if multiple
servers may be involved, then your definition of a session becomes out
of OCP scope. It is no longer an OCP session but something else. There
is nothing wrong with that, but it needs to be stated explicitly so
that we would know that OCP has nothing to do with it (this is an OCP
draft discussion thread!).

> Tracing should keep track of previous OPES applied to the message.
> To prevent loops. This builds the concept of a session (exit the
> session in case of loop).

That's fine. You are, essentially, talking about tracing mechanisms.
Tracing discussion has its own thread.

> The question was about using the word session to another end.

The question was about naming communication between OCP agents.  We
are talking about logical connections "to another _OCP_ end". Your
session is not about OCP, but OPES in general, I guess.

> I explained what "session" meant to me, and I think it makes sense
> and can be used.  Abort is one reason I quoted, yes. There may be
> others like to understand the order of the previously applied
> services, etc.

Sure, that is what tracing is for. For example, HTTP Via headers are
used by proxies to detect loops. It looks to me that your session is
nothing else but a collection of all trace records added to the
application message so far. Is it not?

> the OPES Processor only happen the dispatch of the call-outs.

OPES processor can do adaptation internally. It can also do adaptation
externally but without the use of callout servers and OCP. I think
that is why it was called Processor, with a Dispatcher element. I
agree that the name/concept is unfortunate because it focuses on
physical placement (same box versus external server) rather than
logical role.

I tried to use OPES dispatcher as an OCP client, but folks objected,
citing the architecture draft. I do not have the energy to fight this
well-established terminology. Perhaps you can drive the change? Does
anybody else care about "OPES processor" terminology imperfections?

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 8 Apr 2003 17:45:55 -0600

I think we need to stick with the terms "OPES processor" and "callout
servers".  If it helps, think that the terms are abbreviations for
"OPES-enabled proxy processor" and "a server performing OPES services
in response to requests from an OPES-enabled proxy processor".

It seems like a good idea to me to have OCP headers that mean "The
OPES processor A expects OPES service X to be applied to this data"
(these might even be ordered) and "callout server B applied OPES
service X to this data".  That doesn't mean that the headers MUST be
copied to the tracing data on the messages that are part of the
proxied data (but they COULD be).

I'm skeptical about using these headers to avoid loop detection,
though.  That's a local implementation matter.  Sometimes it will
work, sometimes the services might actually have loops (apply
unbase64, translate gif to jpg, apply base64, apply unbase64,
translate color to bw, apply base64).  Still, the headers would be
useful for workflow organization, even if loops are OK.

Hilarie