[Top] [All Lists]

Re: comments on draft-dracinschi-opes-callout-requirements-00.txt

2002-03-06 10:57:45

The Purple Streak (Hilarie Orman) wrote:

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

Sure, in this specific context, local uniqueness of the service identifier is sufficient (because the callout message is already directed to a specific callout server). The document does NOT require something else, but might not be clear about it. Maybe the part on "...MUST contain the complete hostname..." is a little bit confusing, but it is required (when using URIs) to get local uniqueness if we allow callout servers to listen to multiple hostnames on a single IP address (in analogy to the explanation of the 'Host' header field in HTTP 1.1).

I still don't understand. Are you concerned about different requests for one piece content being executed in parallel? What is a message
context, exactly?

Yes, that's the concern. Of course, we could also require that different service requests for one piece of content are always executed sequential, which would make it simpler (but maybe less powerful).
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.

The callout protocol specifies only things that are relevant independent from the protocol used on the content path. If there's something specific to the protocol used on the content-path, it could be specified in a profile, which is specific to that content-path protocol. The callout protocol would then have to indicate which profile is used.

Example: A callout message may include an HTTP response and the HTTP request, which triggered this response => callout protocol somehow needs to indicate that the request is also included. However, this is only of relevance to HTTP (or request/response protocols in general), so this might be something to be inclued in content-path specific profiles (rather than the general callout protocol).

An architecture that prevents intermediary filtering is not acceptable.

That's not what I said.

The publisher's policy might be set wrt to the callout service.  E.g.,
"callout service C can extend the validity period".

Still, defining and determining the cachability of an object will get more complex for the publisher - it's no longer sufficient to set all the header fields appropriately, but also to remind and to take care of all the policies for all the services out there. Do you have a specific application example in mind where this would be beneficial?

URL replacement in large documents. This is a critical piece of functionality, especially if you don't allow lightweight filtering
on the intermediary.

Ok, we thought of that as well, but weren't sure whether it would be worth the added complexity in implementations.

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.

Didn't slip by, "we" was refering to the authors of the draft.