ietf-openproxy
[Top] [All Lists]

Re: Draft on Callout Protocol Requirements

2001-11-22 05:39:42

"transferred between intermediary and callout server. However, it
 requires the intermediary to store and manage all messages it has
 sent to the callout server. Thus, it introduces complexity in the
 intermediary and increases its memory requirements.  "

Not necessary believe it introduces complexity. Only memory
requirements. 
 
I agree, the major point here is definitely the memory requirement in
the intermediary (but then, don't we need at least a little
functionality for the management of messages stored in that memory?).

Another option to be explored is when you ask for a service, you do not
know a priori how the content will be transformed. You just ask for
ad-insertion, not for a specific ad. So when call out send the first
response with an ad-insertion, he also might say "and by the way, apply
the same ad to all HTTP requests from network A.B.C.D to network F.G.H.I
for a period of time T".

Of course, the problem with pipelining is that things can get delayed in 
the pipe, so responses become serial.

As to Reinaldo's suggestion above... I don't really see how that logic can 
be passed back in a way that can be used in quite that way.  Caching of 
transformations may be appropriate if these can be addressed appropriate, 
of course.

Caching of transformation rules would require some standardized rule
language and a respective rule processor in the intermediary. I don't
think that an intermediary should be required to provide this
functionality since this would definitly increase its complexity. 

However, this could be useful as an optional feature where an
intermediary signals "I am capable of processing rules specified in
language XY". In that case, the service could return a rule instead of a
response (or both?). But then, do we need explicit support of such a
mechanism in a callout protocol or can this be implemented using the
regular request/response mechanism?

"       To invoke multiple services, an intermediary MUST be able to
specify          more than one URL. "

Here you are implying that URL as a means for Service Identification MUST
always be supported. This should be MAY or better just rewrite it so that
whatever method used (embbebed URL or a new header, or even different
combination of channels) asking for several services on the same content
MUST be possible.

Doing it in a header?  I'd hate to think of the consequences if someone's 
HTTP server just happened to start injecting headers that caused unexpected 
activity in OPES systems...

Hmmm, the header is part of the callout protocol (not of the conent path
message). So a web server is never able to generate these headers.

Volker

-----------------------------------------------------------------------
Volker Hilt               Phone: +49 621 181 2606
Praktische Informatik IV  Fax  : +49 621 181 2601
University of Mannheim    EMail: 
hilt(_at_)informatik(_dot_)uni-mannheim(_dot_)de