First, one point about terminology. I think that it's fine to use the
most general term for a box type, but in the case of caching proxy,
it's clear from reading the messages on this list that no one ever thinks
of a bare "message store" in the web context. A cache is a caching proxy,
and if such a thing has a local cache, the surrounding verbiage makes it
clear when a cache is not a cache.
Another generality is that it is difficult to go from the specific (ICAP) to
the general (these requirements) without becoming a little schizoid.
This document makes many implicit assumptions about the callout protocol
that need explicit mention. I've tried to note some of them, but I know
there are more, otherwise I wouldn't note that I just don't understand
parts of the document.
A remote callout server is a cooperating server that runs
OPES service modules on behalf of an OPES intermediary.
I'd not phrase it that way - "on behalf of" has too many vague
interpretations. It runs OPES services "when requested to by an
OPES intermediary" sounds less loaded.
Instead of "messages exchanged on the content path" could it read
"on the transport path"?
For 3.1.1 Service identification, I'm not sure what it means for a
protocol to "uniquely identify a callout service" outside of any
protocol message context. I mean, if I don't know where I could use
the service identification yet, how can I tell if it is important
that it be unique? For all I know, local translation tables are
I think the document gets into URL's and header fields before stating
basic things, like the callout protocol MUST have header fields that
can contain arbitrary binary data.
The stuff at the end of 3.1.3 isn't clear. If we have several
requests issued in parallel, why don't we have clear id's for each
request session, like in a normal protocol?
I can't make sense of the second paragraph of 3.1.4.
In 3.1.6, I can see that an intermediary cannot receive an entire message
if the message is potentially unbounded, but I think it is short-sighted
to mandate SHOULD NOT for all messages. I very much favor an OPES
design that allows lightweight relevance filtering on the intermediary
before invoking the callout server, and in that case, some messages will
be entirely received before a decision about callouts is made.
For caching, it is important to keep in mind that some things may be
inherently uncacheable, no matter what the callout server may say.
If, for example, the object in question is a request message in the
content transport protocol semantics, the intermediary might have good
reasons to consider the callout server response to be uncacheable. In
this case, and in what follows, the intermediary can always reduce the
cache validity period.
I agree that the validity period for cached responses must be considered
in terms of both the callout server's view, the origin server's view,
and even local policy on the intermediary. Thus, 3.2.1 needs expansion.
I'm not sure what to do if the callout server feels it needs to lengthen
the validity period offered by the origin server. Seems like a policy
matter - the publisher's policy may allow such changes, may limit them,
For 3.2.2, Channels, why not allow any number of channels, each with its
own service parameters?
From the description of buffering, it seems clear that the content transport
protocol must be one that sends data in order, in some sense. That's because
there's verbiage about "the initial part", etc.
Why can't the "I'm not buffering any more stuff, send me a response ASAP"
info be part of a message header for the protocol? Seems a lot cleaner than
setting buffering limits.
It must be possible to send isolated parts of the content data to
the callout server. Bytes 500-778, bytes 10023-20000, etc. The responses
must indicate the range and whether the content has been altered and its
new length. This is partially addressed by 3.2.5, but that seems to
assume that the intermediary sends the whole message and the server
makes any partiality decisions.