Markus Hofmann wrote:
If I want a callout server to execute a specific service on a certain
message, I need a way to tell the callout server which service to
execute (i.e. I need to indicate the specific service to be executed
in an unequivocal way). That's what the paragraph meant to be about.
Then this is in the context of an intermediary to callout server request
or initialization of some kind. Still, local translation tables seem
perfectly suitable, unless there are unexpressed requirements for both
a global naming scheme and some kind of service discovery on the global
> 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?
If we've requests issued in parallel, we've to make sure that these
requests are serviced on a consistent message context. It must not
happen that one service modifies the message context, while another
service executes based on he same message context. This is achieved
most simply by not allowing services to modify the message context at
all - or by not allowing parallel service execution...
I still don't understand. Are you concerned about different requests
for one piece content being executed in parallel? What is a message
> I can't make sense of the second paragraph of 3.1.4.
This meant to say that a callout protocol may allow specification of
payload-specific profiles, i.e. the callout protocol itself defines a
common framework independent from the actual payload message
format,but allows for additional payload-specific profiles to be included.
Sorry, but I still don't get it.
> 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.
I somewhat disagree in that I'm not convinced it would be a good idea
for OPES intermediaries to base decisions about callouts on the body
of application messages (complexity, performance - OPES intermediaries
are in the content path). This topic was discussed for quite a while
on the list, although this was before the WG has been chartered
officially and we migt therefore raise this issue again.
An architecture that prevents intermediary filtering is not acceptable.
Despite that, I agree that mandating "The intermediary SHOULD NOT try
to receive the entire message before it is sent to the callout server"
is too strong. It might be ok if the callout protocol is able to do
so. The point rather is that a callout protocol MUST NOT be designed
assuming it will always be able to receive the message in its entirity
before starting to forward.
> 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, etc.
Hm, if the publisher's policy would allow such changes, for example
lengthening the validity period, why didn't the publisher indicate the
longer validity in the original response in the first place? If we
allow overwriting the cachability depending on publisher policies, it
gets more and more complex for the publisher to actually define the
cachability of its content - did I set the header fields correct, did
I set my policies correct, etc.? Basically, it means that cachability
is given by even more parameters than we already have today... I like
The publisher's policy might be set wrt to the callout service. E.g.,
"callout service C can extend the validity period".
> 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.
We thought about that and had long discussions, but at the end we
weren't sure and didn't put it in. What's the general feeling about
that, would this be useful/needed, is it worth the added complexity?
What are the application scenarios and the expected benefits?
URL replacement in large documents. This is a critical piece of
functionality, especially if you don't allow lightweight filtering
on the intermediary.
Who are the people you refer to who had these long discussions? If
this was on the email list last fall and I somehow missed it, I'm sorry,
but it seems like a lot to have just slipped by.