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@xxxxxxxxx]
> 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@xxxxxxxxxxxx
> [mailto:owner-ietf-openproxy@xxxxxxxxxxxx]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
>
>