Subject: RE: Comments on ocp-00

From: "Martin Stecher" <[email-masked]>
Date: Fri, 4 Apr 2003 11:46:47 +0200

Hi,

here are my 2 euro cents:

> 
> 
> Here is a short summary of the pending issues on this thread.
> 
> 	a) OPES processor may be able to pre-process application
> 	  messages (e.g., extract payload). Callout servers
> 	  may be able to handle various kinds of application
> 	  data (e.g., complete HTTP messages versus MIME-encoded
>  	  payload). Thus, somebody needs to tell OPES processor
> 	  and callout server what is an "application message"
> 	  definition that they should both use during OCP
> 	  communications. Should OCP support auto-negotiation or
> 	  rely on out-of-band (e.g., manual) configuration?

I am very much undecided what I like better.
On one hand I completly follow your arguments that some callout
services like virus scanners would prefer application messages
that are generic and not bound to a protocol like HTTP or SMTP;
it's definitly great if an OPES processor can work on a new
application protocol but use existing callout services that
handle the data without understanding the new application
protocol.
On the other hand I experienced that at some time the callout
service better had the original application message; sticking
with the virus scanner example: One year ago a malformed email
project has been started; it is important to correctly handle
also malformed mime section for a good virus protection. A
virus scanner may want to include a best-of-breed solution for
this and not bank on the pre-process implementation in various
OPES processors.

These could be arguments for an auto-negatiations checking which
side has which capabilities and application protocol knowledge.
But I am very much concerned that this will become an inter-
operability nightmare.

How about this:
We discussed that we probably end with multiple application
protocol bindings of the OCP. One application protocol binding
could be a generic binding which is not really related to any
Internet protocol but handles data as if it was a file on disk.
Application messages could have a very simple and generic format
here. Many callout services may want to support this protocol
binding and an OPES processor may have pre-processing code to
translate Internet protocol data to that simple format.
Other protocol bindings will handle native HTTP and SMTP messages.
Every application protocol binding defines a fixed application
message format.
Negotiations between OPES processors and callout services is then
limited to exchange supported application protocol bindings.

> 
> 	b) Do we really need a special "error" flag to say
> 	  "rally bad error; you should probably wipe out all
> 	   related state". Or can we assign the same side-effect
> 	   to some of the result codes?
> 
> 	c) OPES processor can be [a part of] an application-level
> 	  proxy. Can OPES processor be a transport-level gateway
> 	  too? For example, can OPES processor manipulate with
> 	  raw TCP packets and care about things like
> 	  retransmissions and ACKs?

I think we should concentrate on the application layer only. If it
later turns out that OCP can also be handled on the transport layer
fine but it should not restrict any protocol features now.

> 
> 	d) If a fragment of an application message is lost,
> 	   [how] should OPES processor signal that to the callout
> 	   server? A loss can happen when adapting lossy application
> 	   protocols.
> 
> 	e) Do we need to group processing of a single application
> 	   message together using OCP transaction concept? Should
> 	   OCP transaction mean something else? Do we need OCP
> 	   transactions at all?

Yes, I think so.
In most cases not more than one application message will be
transferred from CLIENT to SERVER and back within a transaction.
But we have two examples where multiple messages make sense:
1. Allowing the SERVER to return different SMTP messages for
one email to multiple recipients it received from the CLIENT.
2. Pre-processing of a message at CLIENT which results in
multiple application messages, e.g. MIME sections of an email
to be transferred as multiple application messages

The first case requires to have the messages being wrapped into
a single transaction.
The second case could benefit from a transaction wrapping
because the SERVER may want to know which MIME sections belong
together.

I agree with Alex that the transaction overhead could (and should)
be limited to a minimum so that no additional transpart layer
packet is needed.
For the normal case the xaction-start app-message-start couple
could almost look like a single message I think.
But let's keep the xaction-start message two allow support of
above cases.

Regards
Martin