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.