Re: Strawman OPES Charter

I add comments on Alex's to simplify the things.

I would like to see a reference to P in the existing achievements. To know 
where it fits. This might clarify the questions about P, IRL, etc later on?

At 07:57 13/07/04, Alex Rousskov wrote:
>On Mon, 12 Jul 2004, Markus Hofmann wrote:
>
> > 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.

I am disturbed by the imbalance. First was developped a profile for HTTP (a 
protocol),  now we want to support applications (not a protocol) using 
messages transported by a protocol. What about messages supported by other 
protocols. This is one of the fall out of my remark about the judge 
analysis. If the messages are considered they could be transported by http, 
ftp etc.

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

One of the key element in SMTP is routing. My main interest in OPES (as 
long as they do not support ONES and interoperations) is in massaging 
routing elements (what permits to correct DNS or SMPT recipient informations).
- is this included ?
- this may forbide the wording about one end to agree. Let say A send a 
mail to B and B (or law) wants an OPES changing B into C. The C real 
termination is not necessarily informed. Also correction is impossible 
since the mail information arrived to C is compromised. If C demands the 
OPES action to be corrected, C will nevertheless know what was in the message.

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

I see that Alex is on ATOM. Feeds can be supported by mail, mail can also 
be supported through feeds (IMHO this is what I worked on | in French ] and 
named "weemail", and what is the future of e-mailing). This means that OPES 
are to massage messages texts. Indendently from SMTP.

In this SMTP is just used as a signaling tool or a feed transport (one 
datagram in many cases). This rises the question again of what OPES have to 
do with :
- SMTP a signaling protocol (which can also carry a message payload)
- messaging which can use any protocol and which can be push or signal and 
pull.

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

My Franglish is lost. HTTP/SMTP messages ?

The end of Alex's comments are OK with me - being considered the initial 
remark about P.
jfc