ietf-openproxy
[Top] [All Lists]

Re: AW: Using XML in OCP transport

2003-05-07 12:16:14

On Wed, 7 May 2003, Markus Hofmann wrote:

Alex Rousskov wrote:

I agree. I wonder how we should decide which way to proceed. What is
better:

  - best fit: a simpler, compact, domain-specific transport that
    we have to write (OCPTRAN), increasing OCP adoption chances

  - fast result: a more complex, larger, general-purpose transport
    that we can reuse with some effort and loss of elegance (BEEP),
    decreasing OCP adoption chances

It's also about what can be done with the resources we currently
have.  Who would committ to agressively move a new transport
forward, without slowing down work on the OPES challenges that are
at our core.

I do not think it would be a lot of work to define OCPTRAN because it
will be integrated with OCP and will not be a stand-alone
general-purpose transport protocol like BEEP. We can probable assume
TCP as low-level transport and make many other simplifying,
domain-specific assumptions as well.

As we discussed before, it is not the amount of work to build OCPTRAN
that pauses us, it is our desire to reuse things defined on top of or
for BEEP Core (such as security negotiations).

I have a feeling that if "fast result" is the correct choice here,
then we should just polish ICAP instead of doing OCP. On the other
hand, if "best fit" is the way to go, then I am worried about
documenting security negotiations (something BEEP already has).

What would we loose by "polishing ICAP instead of doing OCP" (over
BEEP)? It seems that most folks thought the expected benefits would
justify this approach.

The original motivation to build OCP was to provide an application
agnostic protocol (ICAP is HTTP-specific) with several key features
missing from ICAP (e.g., multiple adapted response generation or
copying optimizations). We cannot just "polish" ICAP to get most of
those new things supported; we would have to make major changes, which
is what OCP is supposed to do.

If we do not use BEEP, but still do OCP, we can make messages look
similar to ICAP ones. OCP can be a new protocol (with all the desired
features) that just has ICAP-looking messages. Or, to be more
accurate, messages that look more like ICAP/MIME than like BEEP/XML.

Please note that I am not casting my vote here, just documenting and
clarifying available options:

        - "polish" ICAP (e.g., document encryption) [ call it ICAP/1.1? ]
        - write OCP on top of TCP [ call it ICAP/2.0? ]
        - write OCP on top of BEEP [ call it OCP/BEEP ]

Alex.