Re: Strawman OPES Charter

Alex Rousskov wrote:

> Did you mean "one-party"?

Yes, will fix that.

> We can write "... will specify one or more OCP profiles that ...".

Agreed, will change that.

> And then add something like "Several kinds of agents participate in
> SMTP exchanges, including MSA, MTA, MDA, and MUA. The first SMTP
> adaptation profile will address the needs of at least the XXX SMTP
> agent. More profiles may be needed to address other agent-specific
> needs." I do not know what agent should replace XXX placeholder above.

Do we believe that the role of a SMTP element will have any impact on 
the OCP profile(s)?

I guess until we know for sure the proposal aboce makes sense. I'll 
put the proposed text in the draft charter for now.

Martin - since you've been implementing iCAP-based SMTP forwarding 
already, what SMTP element would you suggest, what's needed first? 
What makes sense?

> The reference to "application endpoints [controlling] the execution of
> OPES services" confuses me. It seems to imply that endpoints are
> controlling the execution of services. We usually say that endpoints
> authorize the execution of services (and may supply the rules), but
> execution is done by the OPES dispatcher.

The phrasing comes from the initial OPES charter. I agree with your 
statement.

> Also, "purely for ... invocation" may be read as "and not for
> selection of which services to invoke".

OK, it should clearly include the selection as well.

> Finally, can we be more precise than "methods for specifying rules"? Do
> we really intend to specify more than one method? Can it be anything
> other than some sort of configuration language like IRML or P?

No, I would assume its a single rules langueage. If we agree on that, 
I'm all in favor of putting this in the charter explicitly.

> How about:
> 
>   In addition, the WG will define a configuration language to
>   control OPES dispatcher selection and execution of OPES services.
>   Defining language(s) for implementing OPES services is out of the WG
>   scope.

I would suggest to use the term "rules language" rather than 
"configuration language" and use the term "OPES processor" rather than 
"OPES Dispatcher". What about

   In addition, the WG will define a rules language to control
   selection and execution of services by an OPES processor. Defining
   language(s) for implementing OPES services is out of the WG scope.

> To partially address SMTP agent concerns, how about:
> 
>   - Define a SMTP profile(s) to supplement OCP core.

Sounds ok to me. Will change that.

> If the above rule-related wording is changed, then this can be
> changed to:
> 
> - Define a configuration language to OPES dispatcher selection
>   and execution of OPES services.

Will put "Define a rules language to control the selection and 
execution of OPES services." for now.

> To address SMTP agent concerns, how about:
> 
>   NOV04   Initial document on SMTP adaptation profile for XXX agent
>           and possibly other agents.
>   NOV04   Decision on what other SMTP agents, if any, the WG should
>           work on.

I put this on for now.

> I would also consider changing the deadlines to OCT04. It does not
> take long to publish a draft. Some even consider the deadlines like
> the first one above meaningless because the "initial document" can be
> a placeholder, but we can play the game and have an extra "Done" on
> our record.

I sort of agree, but it allows to make sure (and track0 that we 
produce something within the first months.

With respect to shortening the timeline - keep in mind that the 
charter first has to be approved by IESG, and I don't know how fast 
this might happen. Also, we had to extend our deadliens too often in 
the past, I'd rather want to make sure that we meet the deadlines this 
time.


>>JAN05   Initial document on OPES rules language
> 
> Can we change the above to SEP04? It does not take long to publish the
> P draft again. We can republish it as-is right after the charter is
> approved. (This comment assumes we are going to use P, see below).

Makes sense.

>>FEB05   Submit document on SMTP protocol profile to
>>         IESG for Proposed Standard
> 
> 
> To address SMTP agent concerns, how about:
> 
> FEB05   Submit document on SMTP adaptation profile for XXX agent
>         and possibly other agents.
> MAR05   Submit document(s) on SMTP adaptation profile(s) for those
>         other agents the WG has decided to work on, if any.

Although this is very vague, let's put it in for now. Let's see what 
Ted thinks about this.

Is MAR05 too aggressive fo the other profiles?

> Would it be appropriate to mention that the rules work will be based
> on P language specification that WG has already worked on? Or are we
> going to re-select among P, IRML, and others as a starting point?

I like your suggestion. I would strongly assume that the rules work 
will be based on P. What about if we add a sentence like

   The rules language will be based on previous work of the WG on a
   rule language named "P".

> If we are going to re-select, should we start with a "language
> requirements" document?

No.

> Even if not based on P, OPES rules language is likely to have
> modules/parts that are application protocol specific (e.g., SMTP and
> HTTP modules). Are we implying that the WG will specify those modules
> for HTTP and SMTP? 

Yes.

> Are we implying that the WG will specify those
> modules inside a single "OPES rules language" specification? 

No.

> those modules should be described separately from the language itself.
> Like "C and stdlib" or "Java and J2EE". Can/should we reflect that in
> the Charter?

Not sure whether we already know exactly what this will look like, so 
it might be too early to limit ourselves to this specific aproach. But 
thisapproach is certainly covered by the current draft charter.

> Finally, are the following items in scope?
> 
> 	- Defining how available services become known
> 	  to the rules language interpreter? (At least
> 	  OCP-speaking services)

No, not for this re-charter.

> 	- 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?

I would consider passing of parameters and getting results back into 
the language/program in scope. Any other thoughts?

> 	- Assist with OCP/HTTP implementation and monitor
> 	  OCP/HTTP deployment experience. Maintain interoperability
> 	  and compliance data on OCP/HTTP implementations.
> 	  (This item may have an "implementation and deployment
> 	  report" as a deliverable, but it does not have to, I guess)

No, not for this re-charter. But an interesting issue.

Thanks,
   Markus