Hello MArkus,
comments inline..
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Wednesday, March 06, 2002 9:56 AM
To: The Purple Streak (Hilarie Orman)
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: comments on
draft-dracinschi-opes-callout-requirements-00.txt
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).
I agree that parallel service requests (actually to totally different
call-out server) are very powerful, but the callout server would never known
by its own whether its modifications on the message are going to affect
other services or not. It seems to me this is worst if you are talking about
differentcall-out servers potentially geographically disperse that need to
apply a service to the same message (actually a copy of the message in this
caseI assume).
I think the OPES local device would need to signal this somehow to the
call-out(s) and also be able to reconstruct the original message from
potentially different servers that modified the message independently. It
could always assume as a default behavior that any modification on the
message could affect other services.
I would even argue that even if we ask for services to be sequential, they
need to be on a specific order. I mean, applying Content Filtering first and
then inserting regional news is very different from the other way around.
If you expand this to all possible OPES services you see that there might be
a potential problem to be solved here.
thanks,
Reinaldo
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