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
names.
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.
-Markus