|
RE: Draft on Callout Protocol Requirements
2001-11-21 16:51:52
--On Wednesday, November 21, 2001 12:58 -0800 Reinaldo Penno
<reinaldo_penno(_at_)nortelnetworks(_dot_)com> wrote:
"Similar to the CDN space, there exists need for delivering a variety of
services to corporate/enterprise Intranets. [2] introduces Open Pluggable
Edge Services (OPES), an infrastructure for adding valuable content
services to a CDN or an Intranet."
Again, my take on this is that OPES does not need a CDN in place to offer
its services. OPES is not laid over CDN, but over IP directly. To offer
OPES services you only need IP connectivity. So, if you have the "plain"
Internet as it exists today, OPES cannot offer any service (given that we
put the necessary authorizations in place)? This sure limits the
applicability of OPES.
I think what you mean by "over IP directly" is somewhat different to what I
read into that phrase so I'm going to avoid that issue for now.
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.
And I wonder why you mention Intranet specifically and make it a separate
case? So a Intranet without any CDN infrastructe can offer OPES, but not
the Internet? How about Extranets? How about VPNs, are they a Intranet
(managed or not)?
Agree. Highlighting particular instances of networks isn't particularly
useful. I think the point is to demonstrate that they are leaf networks,
e.g. not transit networks. (Perhaps)
My suggestion is to decouple OPES from any requirement besides IP
connectivity and security.
There is, pretty much by definition, a need to have an application layer
intermediary involved...
" 3.1.5 Pipelining requests
Internet Draft Callout Protocol Requirements November
2001 It is very likely that a remote callout service is called
many times in sequence with a very short time in between two
single requests. For example an ad insertion service might be
called for every HTTP message passing through an intermediary.
For this reason, a callout protocol MUST be capable of issuing a
request without having received the response for a previous
request. In other words, the protocol MUST be capable of
pipelining multiple requests. "
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.
" 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...
|
|