Re: Strawman OPES Charter

Abbie Barbir wrote:

>>If we are going to re-select, should we start with a 
>>"language requirements" document? 
>>
> obsultly, yes we should do a requirement document. 

I disagree on this one. We already spent plenty of time discussing 
requirements and writing them down in the "Policy, Authorization and 
Enforcement Requirements of OPES" document. I don't want to start all 
over again.

I assume that the rules work will be based on "P", as we've already 
burned many cycles over this. Unless somethig imprtant has changed, 
let's start from there.

>>Finally, are the following items in scope? 
>>
>>      - Defining how available services become known 
>>        to the rules language interpreter? (At least 
>>        OCP-speaking services) 
>>
> 
> -- abbie 
> yes, even if we state that is hard coded (in the least case) 

Service discovery is out-of-scope for this round.

>>      - Defining an interface between rules language 
>>        and service (at least OCP-speaking service) 
>>        How to pass parameters to services? How to 
>>        get the result of service application, including 
>>        errors, back to the language/program? 
>>
> 
> --- abbie 
> this is a muddy situation. we can rely on other work or at least
> reference how they handel it (examples, BPEL, CDL etc..)

Not sure whether we all talk about the same thing here. To me, all we 
need is a way that allows us to specify parameters to be passed on to 
a service and to consider the result of a service invocation in later 
rules.

For example something like

  if (condition is true)
   invoke (Service A with parameters x, y, z)
  if (result of Service A was OK)
   do this.

> other objectives: 
> 
> 1. Security for OCP, should we mention that the group might attempt to
> do that as part of the charter or not. It can be a MAY deleiverable.

No MAY deliverables. Either we do it or we don't. At the moment, I 
would *not* feel comfortable to broaden the scope. Let's get the 
currently discussed items done, and then we can take on new ones.

> 2. Need to ensure that IAB requirements are still applicable to any new
> protocol we address. This MUST be in the charter. Our previous work
> addressed the general acrhitcecture but has focused on HTTP.

This is already in the proposed charter, you probably overlooked it. 
It says "Each deliverable must follow the previously developed OPES 
architecture. As each deliverable is developed, it must address the 
IAB considerations specified in RFC 3238.'

Thanks,
   Markus