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

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 11 Jun 2002 09:37:31 -0400

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:[email-masked]]
> 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: [email-masked]
> [mailto:[email-masked]]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
> 
>