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