RE: Some attempts at clarification

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

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