All,
See inline.
Abbie
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Tuesday, July 13, 2004 1:58 AM
To: Markus Hofmann
Cc: OPES Group
Subject: Re: Strawman OPES Charter
SNIP
In addition, the WG will define one or more methods for specifying
rules that enable application endpoints to control the execution of
OPES services. These methods are purely for controlling the
invocation
of services. They are not aimed at implementing the actual services.
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.
--- abbie
agree
Also, "purely for ... invocation" may be read as "and not for
selection of which services to invoke".
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?
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.
--- abbie
agree, we need to be specific here.
The working group will have a design goal that the methods be
compatible with existing policy work within the IETF (e.g.
IETF Policy
Framework) and be able to interface with systems automating
distribution of policies to multiple endpoints. It will be out of
scope for this WG to develop the policy framework and specify
multiple-endpoint policy distribution.
The group's new work items can be listed as:
- Define a SMTP profile to supplement OCP core.
To partially address SMTP agent concerns, how about:
- Define a SMTP profile(s) to supplement OCP core.
- Define specification method(s) and rules for controlling
invocation of OPES services operating on HTTP/SMTP
messages.
-- abbie
agree
SNIP
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.
--- abbie
agree, but no games here. the imnitial document is a place holder.
SNIP
Other concerns:
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?
If we are going to re-select, should we start with a
"language requirements" document?
-- abbie
obsultly, yes we should do a requirement document.
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? Are we implying that
the WG will specify those modules inside a single "OPES rules
language" specification? I think 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?
-- abbie
yes, we need to be as specific as we can.
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)
- 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..)
-- abbie
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.
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.
ABbie