some comments inline..which might have already being discussed, but I'm
starting to read the thread now...
-----Original Message-----
From: Ian Cooper [mailto:ian(_at_)the-coopers(_dot_)org]
Sent: Monday, May 20, 2002 12:13 PM
To: OPES Group
Cc: Oskar Batuner; Markus Hofmann
Subject: RE: WG Last Call: draft-ietf-opes-architecture-00
--On Monday, May 20, 2002 13:28 -0400 Oskar Batuner
<batuner(_at_)attbi(_dot_)com>
wrote:
Some notes on the OPES Architecture draft..
1. Introduction
In some cases it may be impossible to offer the
customization service
at either the provider or the consumer applications. In this case,
one or more additional application entities may participate in the
data stream service.
This term - "impossible" - may leave an impression that this is the
only, or at least main justification to use OPES. This does not look
right. The only scenario (from existing draft-beck-opes-esfnep) where
OPES is the only way to implement the service is request filtering
for hand-held devices, in all other cases service can be implemented
either at the server side or at the client side, or both.
In fairness I think it's fair to say that there are cases where it's
impossible to insert localised advertisements without
something like an
OPES intermediary.
concrete examples would be on the scenarios document. I'm not sure an
architecture document should have examples. Maybe the best way is just to
reference the scenarios document.
Still use of OPES may be beneficial, so I'd suggest ether to use
a different wording, like:
"In some cases in may be beneficial to provide a
customization service
at network location instead of deploying it at either the provider or
the consumer host. For certain services performed on end-user behalf
this may be the only option of service deployment".
That seems limiting and doesn't seem (to me) to convey the
aspect that some
content can only be produced with the cooperation of (possibly
non-exportable) information available to the ISP/IAP. The
problem is that
without concrete examples (which are frequently limiting in
themselves) it
becomes very difficult to write introductory text like this.
The existing
text (plus the introductory paragraph you omitted) seems, to
me, a better
approach to articulate the problem.
2.1 OPES Entities
The usage of terms "OPES service application" and "data dispatcher"
is not always consistent and sometimes even confusing. According to
the definition in 2.1 service application is invoked by data
dispatcher.
If this is always a case (an according to the definition it is so)
Figure 1 should look like this:
+----------------+
| OPES service |
| application |
+----------------+
|data dispatcher |
+----------------+
| |
| HTTP |
| |
+----------------+
| TCP/IP |
+----------------+
| ... |
+----------------+
Figure 1: An OPES protocol stack
I have a problem with this picture since the OPES Service application and
data dispatcher are not in the "protocol stack per se". They do talk to each
other internally but not with outside entities, as shown in the proposed
diagran below. Maybe what we need is to replace the word stack by "logical
implementation" or something the like.
It also may have sense to point out explicitly that OPES application
may be executed either on the same box (or even in the same
application
environment) with the dispatcher or on different box through OCP.
This was on of important features in initially discussed
architecture,
there were even terms like "proxylet" flying in the air.
Agree
I thing it has sense to emphasize this possibility and to provide a
figure like this:
+--------------------------+
| +----------+ |
| | OPES | |
| | service | |
| | appl | |
| +----------+ | +----------------+
| || | | |
| +----------------------+ | | +--------+ |
| | data dispatcher | | | | Service| |
| +----------------------+ | | | App2 | |
| | HTTP | OCP | | | +--------+ |
| +------------| |===(2)====| OCP | |
| | TCP/IP | | | | +--------+ |
| +------------+---------+ | | |
+-------||-----------------+ | callout server |
|| +----------------+
...........(1)
This is a kind of combination of figures 1, 3 and 4.
I like this diagram