On Fri, 9 May 2003, Oskar Batuner wrote:
Can you please elaborate on some of the points in your comparison
chart:
Polished ICAP/1.1
What specific problems should be solved? What problems remain? How
will it work with non-HTTP application protocols, especially
streaming? If I recall correctly streaming was declared as a
"desired" goal.
The biggest problem that must be solved is optional encryption of ICAP
connections, I guess. ICAP/1.1 will not be able to support protocols
that differ from HTTP by much (at least not without a lot of
encoding/decoding on each end of the ICAP connection). Partial support
for SMTP and similar MIME-based protocols is probably doable since
some existing ICAP vendors support SMTP.
Also I'm afraid I cannot agree with the following consideration:
- little incentive to upgrade existing ICAP installations and
implementations
IMHO the incentive is driven by the problems solved in the new version,
not by the passion for innovation. If an upgrade solves important
problem - incentive becomes high,
Agreed. ICAP/1.1 does not solve any important problems, IMO.
if this upgrade is small - incentive becomes even higher.
Please do not mix the two. Incentive is why you want to upgrade (the
reward). Migration difficulty is the cost of an upgrade. Ice cream is
tasty (incentive/reward), but may cost too much (migration difficulty
to get ice cream).
You may want to upgrade very much, but not being able to due to
resource constraints or whatever (e.g., it takes a year to code up the
new protocol or you must pay somebody $$$ in royalties to use the new
protocol).
The same applies to BEEP - in my view the following
two positions contradict one another:
- more incentive to upgrade existing ICAP installations and
implementations
- more difficult migration path
No contradiction, please see above for a clarification. In other
words, OCP/BEEP is more rewarding than ICAP/1.1 but migration to it is
more costly.
Another question - OCP on top of BEEP vs. OCP/OCPTRAN:
Do you agree with the following statement:
The most attractive/useful BEEP features for OCP are security
negotiation mechanism and channel control/multiplexing connection,
the most problematic are XML syntax and message exchange styles.
Not exactly. Here is my wording: The most attractive/useful BEEP
features for OCP are message fragmentation and connection- and
channel-scoped negotiation mechanisms. The most problematic are
message exchange styles and channel management (or async support)
style. XML comes next, I guess.
If yes - we can combine the best of two worlds by copying
security and channel control mechanisms and just describing them
in HTTP style syntax. A kind of "white box reuse".
Yes, that is what I referred to as "clone and modify". It is not "white
box" because you break any connection with the original protocol(s)
after you cloned the existing ideas. For example, if somebody adds
another BEEP profile or modifies/improves an existing BEEP profile,
then OCP/OCPTRAN is not going to benefit without more work.
On a positive side, that "extra conversion work" may not be difficult
and might even be semi-automated (which is why I talked about the
approach). But we should not fool ourselves that we are combining the
best of two worlds -- we are just reusing ideas instead of reusing
protocols/formats.
Should also satisfy some of "IETF powers" concerns as we do not
invent any new and maybe inferior transport mechanisms - just
grammar.
Perhaps, although I cannot predict powers reaction to a semi-formal
XML to MIME-like conversion of BEEP profiles.
Alex.