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