Hello Markus,
my feedback is as follows:
"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.
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)?
My suggestion is to decouple OPES from any requirement besides IP
connectivity and security.
" During the creation of a channel, an intermediary has the chance to
negotiate service parameters, associated with that channel, with the
remote callout service. These parameters apply to all messages
exchanged over that channel."
I'm not totally clear, but I assume here that you are indirectly saying that
an intermediary can open several channels, one for each service (virus
scanning, Content Filtering, etc). And since they are dedicated channels for
specific services, there is no need to inform the service needed to the
packets sent over this channel.
" 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.
This is something I've proposed in
[15] R. Penno, A. Rayhan, M. Duffy, "Out-Of-Path (OOP) Agents and
MIDCOM Framework Integration", draft-penno-midcom-oop-00.txt,
work in progress.
In the case on encryption between intermediary and call out server this is
specially useful.
" 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".
" 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.
Of couse, this poses an interesting problem, right? The problem of ordering.
Performing ad insertion, language translation and they content filtering is
not the same as
ad insertion, Content filtering and then Language translation.
regards,
Reinaldo
-----Original Message-----
From: Markus Hofmann [mailto:hofmann(_at_)bell-labs(_dot_)com]
Sent: Wednesday, November 14, 2001 2:14 PM
To: OPES Group
Subject: Draft on Callout Protocol Requirements
Hi,
we just submitted attached draft on "Requirements for OPES Callout
Protocols" as an attempt to get a discussion on callout protocol
requirements going. Please post any comments and feedback to
this list.
-Markus