ietf-openproxy
[Top] [All Lists]

RE: Some attempts at clarification

2003-04-10 08:03:26


On Thu, 10 Apr 2003, Martin Stecher wrote:

There might be protocol independent services, such as mime part
transformation, because mime parts can occur in several different
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
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.

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.

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.

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.

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.

Agreed.

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

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.

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?

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.



<Prev in Thread] Current Thread [Next in Thread>