Hello Lily,
the dynamic loading of rules need to occur even without personzalition. For instance, in the case of location based services (news, weather, etc) where the user is mobile, we need to dynamically load rules (whether in the callout server, whether in the intermediary) in real time.
Services like virus scanning and content filtering are pretty static in relation to the rules, but services that depend on changing parameters like the location of the user, current performance of the network (bandwidth, jitter, etc), user profile, and others need dynamic rules anyway.
regards,
Reinaldo
>-----Original Message-----
>From: Yang, Lily L [mailto:lily.l.yang@xxxxxxxxx]
>Sent: Monday, April 01, 2002 10:14 AM
>To: 'The Purple Streak (Hilarie Orman)'; ietf-openproxy@xxxxxxx
>Cc: Knight, Paul [BL60:1A00:EXCH]; 'pcs@xxxxxxxxxxxxxxx'
>Subject: RE: [Pcs] Re: some questions and comments on
>draft-barbir-opes-sp cs-01.txt
>
>
>Hilarie -- Maybe you are right to call it a matter of terminology than
>architecture. But I am a bit confused now about the role of
>Admin server and
>the callout server and how much now they overlap with each
>other. I am also
>concerned about the performance implication of dynamically
>loading rules to
>the OPES engine by callout server in the content path in real
>time. In a
>separate thread, you mentioned the slow XML parsing
>performance. Whether or
>not that is indeed true remains an ipen issue. But having the
>callout server
>dynamically loading the rules onto the OPES engine requires
>that the rules
>being transported over the wire is in standard formats (IRML?)
>instead of
>the internal format between the Admin Server and the OPES engine. That
>imposes some extra (XML?) parsing overhead in the content path.
>All these have implications that I think deserve some careful
>consideration
>in the requirement gathering phase.
>Lily
>
>> -----Original Message-----
>> From: The Purple Streak (Hilarie Orman) [mailto:ho@xxxxxxxxxxxx]
>> Sent: Thursday, March 28, 2002 2:38 PM
>> To: ietf-openproxy@xxxxxxx
>> Cc: 'paknight@xxxxxxxxxxxxxxxxxx'; 'pcs@xxxxxxxxxxxxxxx'
>> Subject: [Pcs] Re: some questions and comments on
>> draft-barbir-opes-spcs-01.txt
>>
>>
>> This seems like a matter of terminology more than architecture.
>> The OPES intermediary can trigger on the event "begin user
>> session" and have the action "notify personalization server" or
>> "notify user services admin server" as basic policy rules. The
>> communication can use the OPES callout protocol, and the returned
>> items can be rules. OPES policy can state that rules are
>> only accepted
>> from a trusted callout server list, and they can implement the policy
>> that the returned rules can apply only to the user session for which
>> the callout server was invoked. This doesn't seem particularly
>> dangerous. It does put more requirements on the OPES engine
>> to enforce
>> local policy, but I thought it was going to be a policy enforcement
>> engine, anyway.
>>
>> Hilarie
>>
>> Yang, Lily L wrote:
>>
>> > Hi, Paul --
>> >
>> > Just went through draft-barbir-opes-spcs-01.txt. Sorry that
>> I couldn't do
>> > that earlier -- Looks like I got a lot to catch up.
>> >
>> > First of all, I am not sure that I fully understand the
>> exact role of the
>> > OPES Service Personalization Callout Server (SPCS) and how
>> it should be
>> > treated in the OPES framework. My understanding of the
>> draft is that, to
>> > achieve service personalizaiton, we actually need to deploy
>> two kinds of
>> > callout servers within the OPES framework. One is the SPCS,
>> its role is to
>> > generate dynamic rule modules to upload onto the OPES
>> intermediary based
>> > upon subscriber profile and content profile. But the actual
>> rules (which are
>> > dynamically generated by SPCS) will possibly invoke some
>> content adaptation
>> > service that is to be carried out by the Callout Server
>> (per the diagram
>> > depicted in Figure 1 on page 12). These Callout Servers are
>> the second kind
>> > of callout servers. At the surface, both are callout
>> servers and should be
>> > treated as such by the OPES framework. However, they are
>> VERY different in
>> > what they actually do.
>> >
>> > In my mind, callout servers only do adaptation service for
>> the content, they
>> > don't control/alter the behavior of OPES intermediary (the
>> engine). So only
>> > the second kinds are the real callout servers in that
>> sense. The first kind
>> > (SPCS) is not, at least not according to my understanding
>> of the callout
>> > server definition. Allowing a callout server to dynamically
>> upload or delte
>> > rules from the OPES engine sounds like asking trouble to
>> me. Allowing them
>> > to adapt the content is already a riksy business! This is
>> 10 times worse
>> > than that. To me, SPCS sounds much more like one instance
>> of the OPES admin
>> > server. Admin Server is the entity that can control/alter
>> the behavior of
>> > OPES engine and it requires a much tighter security/trust
>> model between the
>> > Admin Server and the OPES engine. .
>> >
>> > The description of the SPCS's functions are very much the
>> same as the Admin
>> > Server, but with some important exceptions -- the purpose
>> of SPCS is much
>> > narrower of the Admin Server; and there is the "real-time,
>> in the content
>> > path" aspect of SPCS that is not required (in general) by
>> the Admin Server.
>> > My understanding is that SPCS needs to generate and upload
>> the dynamic rules
>> > in real time at the beginning of the "SP-session", and then
>> SPCS is not
>> > involved for the rest of the session before its
>> termination, is it correct?
>> > At the middle of the session, the rules that is just
>> uploaded would govern
>> > the actual content adaption (for personalization). It seems
>> that somewhere
>> > the text also suggests the profile might change mid-session
>> and does that
>> > mean the rules will be generated again mid-session?
>> >
>> > Maybe I misunderstand the whole concept -- otherwise, I
>> have some serious
>> > concern about some of these issues.
>> >
>> > Lily
>> >
>> >
>> >
>> >
>>
>>
>> _______________________________________________
>> Pcs mailing list
>> Pcs@xxxxxxxxxxxxxxx
>> http://eng.registro.br/mailman/listinfo/pcs
>>
>_______________________________________________
>Pcs mailing list
>Pcs@xxxxxxxxxxxxxxx
>http://eng.registro.br/mailman/listinfo/pcs
>