Subject: RE: Some attempts at clarification

From: "Martin Stecher" <[email-masked]>
Date: Thu, 10 Apr 2003 13:27:30 +0200

> 
> Message definitions and relating messages to connections
> 
> [...]
> 
> The ensuing discussion yielded the assertion that OCP could not be
> implemented without a binding to an application protocol.  One
> solution is for OCP be specified as a core protocol and that separate
> documents could be produced with the OCP-HTTP, OCP-SMTP, OCP-FTP,
> etc. bindings.  The current draft would be called the "OCP core"
> protocol, with no application-specific information.  The OCP-HTTP
> document would need attention as soon as the protocol elements are
> firm.
> 
> There might be protocol independent services, such as mime part
> transformation, because mime parts can occur in several different
> application protocols.  One solution would define a new application
> protocol binding for OCP, such as OCP-MIMEPARTS.  Are there other
> solutions?
> 

Such as OCP-MIMEPARTS I think we need something like OCP-FILE or
OCP-GENERIC that is able to vector out something like a file with-
out anything application protocol specific.
I even think that it makes sense to define this together with the
OCP core instead of a separate pseudo-application-binding.
That should be able to produce maximum interoperability.

As an example look at a virus scanner: While it may do a better job
by understanding application protocols, the basic functionality is
to find viruses in any file. Let's say the virus scanning OPES
service is developped for perfect handling of HTTP and SMTP and
therefore supports OCP-HTTP and OCP-SMTP.
Next you get an OPES processor for FTP. The OPES service does not
support OCP-FTP; still a chance that the FTP up- and downloads get
checked for viruses?
If every OPES processor and OPES service is encouraged to support
OCP-FILE if possible at all, this could be a fallback solution if
compatibility on OCP application protocol binding cannot be achieved.

I believe that although there are services that cannot support
OCP-GENERIC (because they filter HTTP header fields for example),
most and the most interesting OPES services can support this.
So, definition on a promiment place (as in the core) could be
a good idea. Support cannot be made a MUST but a "SHOULD if
possible".

> 
> Negotiation
> 
> Capability negotiation is needed on a per transaction basis, not just
> on a per connection basis.  Transactions with similar capability
> requirements can be grouped usefully onto a single connection.  We
> need to make sure this is compatible with privacy and security
> requirements; we have to revisit this wrt to the requirements and what
> can be done with IPSec and TLS.
> 

I agree that different transactions could require different capability
negotiations.
What I am missing is a good example why these kind of different trans-
actions still need to be grouped within one connection and so make it
necessary for OCP to renew capability negotiations in between some
transactions.
Couldn't the protocol be defined lighter by requireing that a new
connection needs to be established if capability renegotiations needs
to take place?
Could somebody give an example why this is not sufficient?

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 10 Apr 2003 09:03:26 -0600 (MDT)

On Thu, 10 Apr 2003, Martin Stecher wrote:

> > application protocols.

Protocol-independent services may be viable not just because some
protocols share similar message structure and encoding (e.g., MIME) but
because it is often trivial for an OPES processor to do message
conversion to/from a protocol-independent form while writing one
"generic" service instead of one for each application protocol is
obviously attractive.

> > One solution would define a new application

Yes, this is what Hilarie calls OCP-MIMEPARTS, essentially. You get a
blob of data with MIME-like encoding (and other general details)
specified in the metadata. It is very generic. You cannot avoid
metadata completely because you have to specify encoding/content-type
(with real files, the latter can be assumed by application or guessed
based on the file name extension or even file content).

We should be careful with using MIME "as is" though because it implies
certain payload transformations (new lines and such); HTTP had to
solve this problem (HTTP payload is not strictly MIME compliant).
OCP-Generic might be a better name.

> OCP core instead of a separate pseudo-application-binding. That
> should be able to produce maximum interoperability.

I believe this is a separate question that we can answer once
OCP-MIMEPARTS/Generic is documented.

We can, for example, keep it as a separate document, but add a
"OCP-Generic SHOULD be supported" to OCP-Core. We have to integrate
only if many OCP core parts become affected. For example, HTTP caching
features are a MAY; in theory, they could have been documented as a
separate document, but there were too many interactions with HTTP
"Core". HTTP Authentication (also a MAY), on the other hand, is a
separate document because there is very little interaction.

> therefore supports OCP-HTTP and OCP-SMTP. Next you get an OPES
> processor for FTP. The OPES service does not support OCP-FTP; still
> a chance that the FTP up- and downloads get checked for viruses? If
> every OPES processor and OPES service is encouraged to support

Agreed.

> a good idea. Support cannot be made a MUST but a "SHOULD if

Actually, virtually _any_ service can support OCP-Generic. It is all a
question of the amount/kind of pre- and post-processing work done at the
OPES processor. In your example (HTTP headers adaptation), OPES
processor may pass just the headers as application data and then
re-assemble the message once the adapted headers come back from the
callout server.

There are two primary settings that need to be negotiated
(auto/dynamically or statically via configuration files) between an
OPES processor and a callout service:
	- how the data is encoded (raw/unknown, chunked, UTF-8, ...)
	- what that data represents (SMTP payload, HTTP headers, ...)
The OCP-Generic specification should be flexible enough to "support"
a variety of common combinations without hindering interoperability
between and specific pair of OCP agents. One agent (processor or server)
would most likely have to do the legwork of converting "anything" to
"generic". OPES processor is probably the best candidate to do that.

Finding an elegant scheme to support the above is one of the biggest
challenges ahead of us.

> I agree that different transactions could require different
> capability negotiations. What I am missing is a good example why
> these kind of different trans- actions still need to be grouped
> within one connection and so make it necessary for OCP to renew
> capability negotiations in between some transactions. Couldn't the
> protocol be defined lighter by requireing that a new connection
> needs to be established if capability renegotiations needs to take
> place? Could somebody give an example why this is not sufficient?

Right now the OCP core is light enough to open/close OCP connections
(not transport connections!) without much overhead. However, the OCP
Core specification lacks any details regarding transport-level
negotiations such as transport encryption. What I suspect may happen
is that the "OCP connection" entity from the OCP requirements draft
will be split into two entities:
	- OCP connection (responsible for expensive, mostly
	  transport-level negotiations and state)
	- OCP session (responsible for light-weight, mostly
	  service-level negotiations and state)
It is also possible that OCP sessions could be nested so that
you do not have to renegotiate from scratch. Some may argue that
OCP transactions should be used to override OCP session state and
that sessions must not be nested.

I think we should discuss this issue once people review the next OCP
Core version (to be posted shortly). It may be time to bring transport
binding into the picture. The above will depend, in part, on OCP
transport binding(s?).

Thank you,

Alex.