On Mon, 7 Apr 2003, Markus Hofmann wrote:
Alex Rousskov wrote:
In other words, let OPES processor worry about its application input
and output. OPES processor negotiates with the callout server what OCP
application they should use and then handles necessary conversions, if
any. Naturally, the processor should not negotiate OCP applications
that it cannot convert input application to or output application from.
OCP application could be HTTP. Or it could be something like
"transfer-encoded HTTP message body with content-type and
transfer-encoding passed via meta-data". Etc...
Provides quite some flexibility, but complicates the negotiation
process... Who would specify/standardize possible OCP applications
to be used? E.g., who would specify something like "transfer-encoded
HTTP message body with content-type and transfer-encoding passed via
meta-data". How do we ensure interoperability? By requesting some
mandatory OCP applications (e.g. HTTP)?
The above negotiations (automated or via configuration files) are
unavoidable anyway! The only way to eliminate negotiations is to
support all pre-defined input/output/OCP application protocols in
every implementation, honor their message boundaries, _and_ transfer
complete application messages.
If we want to make support for an application protocol optional (e.g.,
some callout servers may not support SMTP but may support HTTP), then
OCP agents must negotiate because the agents are no longer 100%
compatible "by default".
If we want to support partial message exchange (e.g., OPES processor
extracts HTTP/SMTP message body and forwards that body along with some
MIME headers as meta-information), then OCP agents must negotiate
because the callout server needs to know whether it is getting a
complete message or just the body.
And so on.
The proposed solution does not make negotiation more complex. In fact,
it actually clarifies negotiation purpose. OCP negotiation must result
in an agreement regarding OCP application protocol, which includes the
usual things like name, version, message framing, meta-data (headers),
etc. If you look at it, it all boils down to how to encode/interpret
"meta-data" and how to interpret "data" (what is it I am getting?),
something we have to negotiate anyway if we want to remain application
agnostic. We can probably agree on the same meta-data encoding/format
for all applications. Then,
OCP application protocol == required meta-data fields +
"data" meaning
OPES WG may then publish an "HTTP as an OCP application protocol"
draft where the above things will be specified for HTTP. Other working
groups and individuals may publish their own application protocol
bindings.
OCP implementations will have to support at least one binding and able
to negotiate it. OPES processors will have to support mapping of their
input/output protocols to/from OCP application protocol they support
(usually it will be a no-op mapping with exception of tracing). Again,
this is no different from what we were going to have; the proposed
terminology/approach is meant as a clarification, not an extension!
Does the above sound convincing enough? Or do you still think I am
opening a pandora box (that was closed before)?
Thanks,
Alex.