Re: Strawman OPES Charter

On Mon, 12 Jul 2004, Markus Hofmann wrote:

> The OPES Working Group has previously developed an architectural
> framework to authorize, invoke, and trace such application-level
> services. The framework follows a one-part consent model, which

Did you mean "one-party"?

> In a next step, the WG will specify an additional OCP profile that
> will support applications operating on SMTP messages. In particular,
> the profile to be specified will enable an OPES processor to
> encapsulate and forward SMTP messages (or parts thereof) to a
> callout server for additional processing.

We can write "... will specify one or more OCP profiles 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.

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

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.

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

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.

> Each deliverable must follow the previously developed OPES
> architecture. As each deliverable is developed, it must address the
> IAB considerations specified in RFC 3238.
>
> Goals and Milestones:
> ...
> NOV04   Initial document on SMTP protocol profile

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

> 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).

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

> MAY05   Submit document on OPES rules language to
>         IESG for Proposed Standard


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?

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?

Finally, are the following items in scope?

	- Defining how available services become known
	  to the rules language interpreter? (At least
	  OCP-speaking services)

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

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

Should we say that explicitly?

Thank you,

Alex.