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