ietf-openproxy
[Top] [All Lists]

Re: Strawman OPES Charter

2004-07-13 07:08:24

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