ietf-openproxy
[Top] [All Lists]

RE: Content Provider Notification: Summary: Please provide feedba ck ASAP

2002-06-11 06:37:44
oskar,

thanks,

the e-mail was specific for notification.

the other threads will be added to the draft.

thanks again

abbie


-----Original Message-----
From: Oskar Batuner [mailto:batuner(_at_)attbi(_dot_)com]
Sent: Monday, June 10, 2002 7:52 PM
To: OPES Group
Cc: The Purple Streak (Hilarie Orman); Markus Hofmann; Marshall Rose
Subject: RE: Content Provider Notification: Summary: Please provide
feedback ASAP



What about some proposal from other threads that did not met
objections:

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

2. > 2.1 OPES Entities

Figure 1 should look like this:


                             +----------------+
                             | OPES service   |
                             | application    |
                             +----------------+
                             |data dispatcher |
                             +----------------+
                             |                |
                             |    HTTP        |
                             |                |
                             +----------------+
                             |   TCP/IP       |
                             +----------------+
                             |     ...        |
                             +----------------+

                    Figure 1: An OPES protocol stack


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 a different box through OCP."

I thing it has sense to emphasize this possibility and to provide a
figure like this:


        +--------------------------+
        | +----------+             |
        | |   OPES   |             |
        | |  service |             |      +----------------+
        | |   appl   |             |      | Callout Server |
        | +----------+             |      |                |
        |     ||                   |      | +--------+     |
        | +----------------------+ |      | | OPES   |     |
        | |     data dispatcher  | |      | | Service|     |
        | +----------------------+ |      | |  App2  |     |
        | |   HTTP     | OCP     | |      | +--------+     |
        | +------------|         |==========|  OCP   |     |
        | |            |---------+ |      | +--------+     |
        | |   TCP/IP   |           |      +----------------+
 =========|            |=============== OPES Data Flow ====
        | +------------+           |
        +--------------------------+


It illustrates positions and interaction of different components
of OPES architecture.

There were some other things mentioned, like use of PEP abbreviation,
but the most important are:

- Trust domains: delegation of authority (coloring) propagates
from the content producer start of authority or from the content
consumer start of authority, that may be different from the
the end points in the data flow.

- OPES processor MUST obey tracing/reporting/notification requirements
set by the center of authority in the trust domain to which OPES
processor belongs. As part of these requirements OPES processor MAY
be instructed to reject or ignore such requirements from the
the sources of a different "color".

Oskar

-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Abbie 
Barbir
Sent: Monday, June 10, 2002 12:44 PM
To: OPES Group
Cc: The Purple Streak (Hilarie Orman); Markus Hofmann; Marshall Rose
Subject: Content Provider Notification: Summary: Please 
provide feedback
ASAP


All,
Following the thread on Content Provider Notification, it 
seems to me that
no
conclusion could be made about the course of action.
There were proposals and counter proposals with no way of 
determining that a
general conclusion that the group could live with was reached.
However, it seems to me that if properly phrased, the 
following should be
added to
the architecture document.
"
The presence of an OPES processor in the data 
request/responce flow SHALL
NOT
interfere with the operations of non-OPES aware clients and 
servers. OPES
processors, content server and content consumer MAY use OPES 
extensions to
the base protocol (HTTP), but support of these extensions SHALL NOT be
required."
I am proposing to add this extra requirement to the 
architecture document
provided that i do not get negative feedback(S).
Furtheremore, I think that the topic of general notification should be
delayed
for a later stage. This will be mentioned in the draft also.


Please give feedback by the end of the day. The new -01 draft will be
comming out soon.
Abbie


<Prev in Thread] Current Thread [Next in Thread>
  • RE: Content Provider Notification: Summary: Please provide feedba ck ASAP, Abbie Barbir <=