ietf-openproxy
[Top] [All Lists]

RE: Draft on Callout Protocol Requirements

2001-11-23 16:05:02
Hello Ian,

comments inline.

-----Original Message-----
From: Ian Cooper [mailto:ian(_at_)the-coopers(_dot_)org]
Sent: Wednesday, November 21, 2001 3:52 PM
To: 'OPES Group'
Cc: Penno, Reinaldo [SC9:T327:EXCH]
Subject: RE: Draft on Callout Protocol Requirements



I agree that the wording isn't too good with respect to your 
comment.  That 
said, it's possible that by adding the intermediary to offer the OPES 
service that network becomes a Content Network.  (And on that 
note I think 
the authors/editors need to be a little more careful about 
the distinction 
of content networks and CDNs as they are typically understood.)

But yes, if you only have plain IP there's no device that OPES could 
connect to in order to provide its services (OK, I'm not 
avoiding that 
issue, am I).  You need an application layer intermediary 
(and for the 
protocols proposed that would tend to be called a proxy) on 
which to do the 
value-added services that OPES enables.


hummm. Let's see a real example. My broadband provider is ATT and I have
webmail. If AT&T offers anti-virus with a intermediary (proxy) and remote
call-out server (anti-virus scanner), does ATT as a whole suddenly becomes a
CDN? A Content Network?

Another example. In my house I run a web server with a reverse proxy. If in
this (OPES) reverse proxy I offer some service, for instance language
translation, does my home network becomes a CDN? Does ATT as a whole becomes
indirectly a CDN? A Content Network? 


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.

I do not see any difficulty doing this. It all depends on the remote
call-out protocol. Maybe you are thinking in terms of a specific call-out
protocol.


"       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...


I never said a new header in HTTP. Moreover because it would retrict the
remote call-out protocol to some HTTP variant. The idea would be have a
field (possibly a TLV) on the remote call-out protocol header in which the
service requested could be specified. This field could also allow
vendor-extensions and being a TLV could also allow for hierarquical
information. 

regards,

-RP