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