Subject: Strawman OPES Charter

From: Markus Hofmann <[email-masked]>
Date: Mon, 12 Jul 2004 17:46:47 -0400

Folks,

please see below for a strawman proposal for a new OPES charter.

Ted already provided some comments and feedback on it; his main 
comment being that the single SMTP milestone seems a bit monolithic. A 
  suggestion is to maybe split the work up a bit more along the 
several roles SMTP elements can have: MSA, MTA, MDA, MUA, and working 
out what might be opes related for each. Ted mentioned that for some 
it will be easy (not much "callout protocol" work for an MUA), but 
that there is no guarantee that the roles are the same for the others.

Please provide your comments and thoughts on the proposed new charter, 
but also on the suggestion made with respect to the single SMTP milestone.

Thanks,
   Markus

===========================================================

Open Pluggable Edge Services (opes)
-----------------------------------

Chair(s):
Markus Hofmann <[email-masked]>

Applications Area Director(s):
Ted Hardie <[email-masked]>
Scott Hollenbeck <[email-masked]>

Applications Area Advisor:
Ted Hardie <[email-masked]>

Technical Advisor(s):
Allison Mankin <[email-masked]>
Hilarie Orman <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
Archive: http://www.imc.org/ietf-openproxy/mail-archive/

Description of Working Group:
The Internet facilitates the development of networked services at the 
application level that both offload origin servers and improve the 
user experience. Web proxies, for example, are commonly deployed to 
provide services such as Web caching, virus scanning, and request 
filtering. Lack of standardized mechanisms to trace and to control 
such intermediaries causes problems with respect to failure detection, 
data integrity, privacy, and security.

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 
requires that each service be authorized explicitly by at least one of 
the application-layer endpoints. It further requires that OPES 
services are reversible by mutual agreement of the application endpoints.

In particular, the WG has developed a protocol suite for invocation 
and tracking of OPES services inside the net. The protocol suite 
includes a generic, application-agnostic protocol core (OCP Core) that 
is supplemented by profiles specific to the application-layer protocol 
used between the endpoints. So far, the WG has specified an OCP 
profile for HTTP, which supports OPES services that operate on HTTP 
messages.

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.

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 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.
- Define specification method(s) and rules for controlling
   invocation of OPES services operating on HTTP/SMTP
   messages.

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:

Done    Submit OPES scenarios document and architecture
         document to IESG for Informational.
Done    Submit document on protocol (callout and tracing)
         requirements to IESG for Informational.
Done    Submit document on endpoint authorization and
         enforcement requirements to IESG for Informational.
Done    Submit document on threat/risk model for OPES
         services to IESG for Informational.
Done    Initial protocol document for OPES services
         including their authorization, invocation,
         tracking, and enforcement of authorization.
Done    Initial document on rules specification method.
Done    Submit protocol document for OPES services
         including their authorization, invocation,
         tracking, and enforcement of authorization to IESG
         for Proposed Standard.
NOV04   Initial document on SMTP protocol profile
JAN05   Initial document on OPES rules language
FEB05   Submit document on SMTP protocol profile to
         IESG for Proposed Standard
MAY05   Submit document on OPES rules language to
         IESG for Proposed Standard

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 12 Jul 2004 23:57:57 -0600 (MDT)

> services. The framework follows a one-part consent model, which

Did you mean "one-party"?

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

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

> compatible with existing policy work within the IETF (e.g. IETF
> Policy Framework) and be able to interface with systems automating

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

>    invocation of OPES services operating on HTTP/SMTP

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.

> ...

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

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

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

---

From: jfcm <[email-masked]>
Date: Fri, 16 Jul 2004 14:40:26 +0200

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?

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

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

>   Defining language(s) for implementing OPES services is out of the WG

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.

> >    invocation of OPES services operating on HTTP/SMTP

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

---

From: Geetha Manjunath <[email-masked]>
Date: Tue, 13 Jul 2004 18:46:52 +0530

> >< stripped>

I suggest
*  Define a configuration language to specify rules/policies for invocation
of OPES services.
*  Specify all the interface(s) to the OPES core  required to support
specific application protocols.

If needed we can work on specific interfaces for HTTP and/or SMTP protocols
as a part of the second aspect.

Rest of Alex's comments seem ok to me.

regards
Geetha

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 10:08:13 -0400

> Did you mean "one-party"?

Yes, will fix that.

> We can write "... will specify one or more OCP profiles that ...".

Agreed, will change that.

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

> execution is done by the OPES dispatcher.

The phrasing comes from the initial OPES charter. I agree with your 
statement.

> selection of which services to invoke".

OK, it should clearly include the selection as well.

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

>   Defining language(s) for implementing OPES services is out of the WG

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.

>   - Define a SMTP profile(s) to supplement OCP core.

Sounds ok to me. Will change that.

>   and execution of OPES services.

Will put "Define a rules language to control the selection and 
execution of OPES services." for now.

>   NOV04   Decision on what other SMTP agents, if any, the WG should

I put this on for now.

> a placeholder, but we can play the game and have an extra "Done" on

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.

> approved. (This comment assumes we are going to use P, see below).

Makes sense.

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

> 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

No.

> for HTTP and SMTP? 

Yes.

> Are we implying that the WG will specify those
> modules inside a single "OPES rules language" specification? 

No.

> Like "C and stdlib" or "Java and J2EE". Can/should we reflect that in

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.

> 	  to the rules language interpreter? (At least

No, not for this re-charter.

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

> 	  report" as a deliverable, but it does not have to, I guess)

No, not for this re-charter. But an interesting issue.

Thanks,
   Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 10:22:31 -0400

> specific application protocols.

With "OPES core", you probably assumed some kind of "rules language 
core", rather than OCP core, right?

I would assume that the phrasing

   Define a rules language to control the selection and
   execution of OPES services.

does not preculde us from specifying a "rules languahe core" and 
HTTP/SMTP specific profiles.

In order to ensure that we come up with a solution that at least 
supports HTTP and SMTP, let's word it as

   Define a rules language to control the selection and
   execution of HTTP/SMTP-based OPES services.

How does that sound?

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 10:33:19 -0400

jfcm wrote:

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

Proposed changes to the new charter now explicitly refer tp "P".

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

So far, we've specified a OCP/HTTP profile that supports services 
operating on HTTP messages.

Now we specify a OCP/SMTP profile that supports services operating on 
SMTP messages.

I would assume this becomes clear from the proposed charter.

> OPES action to be corrected, C will nevertheless know what was in the 

All future work will have to follow the one-party consent model, i.e. 
at least one of the ends has to authorize the servive (this,, of 
course, can be done implcitily).

> My Franglish is lost. HTTP/SMTP messages ?

That is meant to say "...HTTP or SMTP messages". Will change that.

Thanks,
   Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 10:10:07 -0600 (MDT)

> HTTP/SMTP specific profiles.

It does not. The problem is with the specific deliverables that seem
to mention just one language specification/document rather that a core
language plus modules approach:

    DATE Initial document on OPES rules language
    DATE Submit document on OPES rules language to
         IESG for Proposed Standard

Should we rephrase so that multiple documents are allowed?

>    execution of HTTP/SMTP-based OPES services.

Sounds like it excludes other protocols from being considered when
designing the core language. How about:

     Define a rules language to control OPES processor selection
     and execution of OPES services, including HTTP and SMTP
     adaptation services.

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 10:38:56 -0600 (MDT)

> the language/program in scope. Any other thoughts?

I agree. Supporting just that in a general way is already difficult!

We are talking about any P program being able to pass any parameters
to any service in scope (e.g., any OCP-speaking or perhaps
WSDL-describable OPES service). How will P interpreter know what
parameters are available? Which parameters are optional? What are their
types?

I hope that we can decide on specific mechanisms after we settle on
the charter, but I wonder if we should now decide on whether to
accommodate just OCP-speaking services or something broader like
WSDL-describable services (assuming we can use WSDL core to describe
any OCP-speaking service).

OCP-speaking services already have a PETDM-driven "feature" interface
that can probably be used to infer the set of parameters, but handling
PETDM declarations may require human involvement. Is that good enough?
If human involvement is required, any P interpreter would have to
hard-code known OCP feature descriptions instead of being able to
handle any "registered by administrator" OCP feature. A big difference
from deployment point of view! You have to know all feature profiles
in advance...

If we do not want human involvement, we have to use something like
WSDL (and map WSDL to P and to OCP PETDM feature declarations) or make
OCP PETDM notation more formal so that it can be processed by P
interpreters to extract feature interfaces. Either task is quite a
challenge.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 10:40:51 -0600 (MDT)

> No, not for this re-charter. But an interesting issue.

May I ask why not? Isn't it a "good practice" to shepherd produced
standards? If the item has no deliverable, would it really increase WG
load? We do not intend to ignore any OCP/HTTP questions/concerns
coming at us from early adopters, are we?

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 10:37:27 -0600 (MDT)

On Tue, 13 Jul 2004, Markus Hofmann wrote:

> Alex Rousskov wrote:
>
> > 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.
>

Then lets fix it! No reason to continue to confuse those who read our
charter (and, hopefully, more folks will discover OPES as our
documents start to gain RFC status).

Thanks,

Alex.

---

From: jfcm <[email-masked]>
Date: Fri, 16 Jul 2004 19:25:35 +0200

At 16:33 13/07/04, Markus Hofmann wrote:
>>(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.
>
>Now we specify a OCP/SMTP profile that supports services operating on SMTP 
>messages.

This is why the same phrasing should be used.

>All future work will have to follow the one-party consent model, i.e. at 
>least one of the ends has to authorize the servive (this, of course, can 
>be done implcitily).

The answer does not match the question. In one to one direct access http, I 
know who are the parties. I one to many possibly rerouted mailing I do not 
know what you mean by parties. Has to be clarified otherwise the whole 
thing will be opposed on security grounds.

>That is meant to say "...HTTP or SMTP messages". Will change that.

I am not sure about what you mean in this as SMTP Messages when you refer 
to HTTP Messages. You will find that SMTP will probably used in OPES 
related application as application signal and message transport. Even if 
you do not want to take theses mechanisms in consideration, what IMHO 
removes a lot of interest to effort when you consider real life 
applications - for example spam fighting, I suggest a clearer wording to 
avoid this confusion.

Cheers.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 11:37:42 -0600 (MDT)

On Tue, 13 Jul 2004, Markus Hofmann wrote:

> jfcm wrote:
>
> > 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.
>
> Now we specify a OCP/SMTP profile that supports services operating
> on SMTP messages.
>

Markus,

	Jfc seems to re-visit, perhaps unknowingly, a very important
charter-related question that we must finish discussing. Please see

	http://www.imc.org/ietf-openproxy/mail-archive/msg02979.html

for the start of the thread. In

	http://www.imc.org/ietf-openproxy/mail-archive/msg02982.html

you said "Similar to what we did in the first charter, we can make
SMTP the prime goal which we'll have to provide a solution for, but we
can first explore the feasibility of a general "email/MIME" profile
(and maybe include an explicit charter item for such exploration)."

The above direction was supported by Abbie and myself, without
objections. Can we go down that path and include an exploratory
charter item instead of starting with SMTP? It may also simplify
solving the agent-dependency problem for SMTP. We can be more vague
about SMTP if we have to do MIME first!

I apologize for not recalling that two-week old e-mail thread earlier.

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 11:43:00 -0600 (MDT)

> *  Define a configuration language to specify rules/policies for invocation

Yes, I like "selection and invocation" better than "selection and
execution". P is really not about execution, just invocation. Once
invoked, services execute on their own, without P participation. P has
no controls to change service execution run-time. P can only select,
configure, "start" or "invoke" a service, and get the result.

... unless we want to expand P scope to affect things like preview
size dynamically, while the data is being retrieved from the network.
We will be able to control service _execution_ then.

Thanks,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 16:37:30 -0400

> Should we rephrase so that multiple documents are allowed?

What about:

SEP04   Initial document(s) on OPES rules language
MAY05   Submit document(s) on OPES rules language to
         IESG for Proposed Standard

>      and execution of OPES services, including HTTP and SMTP

Let's committ to producing a solution that at least supports HTTP and 
SMTP, but not more.

We aim to define a language that is open to support others as well, 
but we don't get into trouble if it turns out to be too complex. 
That's exactly what we did with the protocol in the current charter - 
we were chartered to define a solution for HTTP. but we were able to 
come up with an elegent solution that is flexible enough to support 
other protocols as well.

So I'd suggest to stick with "Define a rules language to control the 
selection and invocation of HTTP-based or SMTP-based OPES services."

-Markus

PS: I'll go through the reamining comments and will send out an update 
charter once I got through.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 16:38:53 -0400

> documents start to gain RFC status).

As indicated in earlier email, I agree, which was meant to imply that 
I changed that.

Updated charter to be broadcasted on this channel soon - stay tuned :)

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 16:44:21 -0400

Alex Rousskov wrote:

> WSDL-describable OPES service). 

Minor personal preference... I don't like talking about "P programs", 
but rather about "P rules", since the former might get people the 
impression that P can be used to program actions.

 > How will P interpreter know what

I consider this out-of-scope for the current work. The author of the 
rules needs to know about the parameters and their types when writing 
the rules.

For example, when I'm writing rules like

   if (condition)
    invoke Service_A(p1, p2, p3)

then I assume to know about Service_A and its parameters. How I learn 
about this is out-of-scope (could be either human interaction or 
automated).

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 16:46:35 -0400

Alex Rousskov wrote:

> load?

If it has no deliverables, why should it be on the charter?

 > We do not intend to ignore any OCP/HTTP questions/concerns

No, they can be brought in in the context of the work items we already 
have.

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 16:52:43 -0400

> configure, "start" or "invoke" a service, and get the result.

Agreed, chaned that.

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 16:51:51 -0400

> I apologize for not recalling that two-week old e-mail thread earlier.

I actually had this in mind... The phrasing we've so far in the 
strawman charter does *not* preclude us from doing this. I would 
expect us to explore these options first, just as we did with OCP 
(without having it mentioned explicitly in the previous charter). Not 
explicitcly broadening the scope might make it more likely to get the 
charter accpeted.

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 17:24:14 -0400

> This is why the same phrasing should be used.

Here's what we've in currently proposed charter"

   So far, the WG has specified an OCP profile for HTTP, which supports
   OPES services that operate on HTTP messages.

and

   [...] the WG will specify one or more OCP profiles that will support
   applications operating on SMTP messages.

I think this is exactly what I describe above and you agreed on, so 
we're in agreement here.

> The answer does not match the question. In one to one direct access 
> http, I know who are the parties. I one to many possibly rerouted 
> mailing I do not know what you mean by parties. Has to be clarified 
> otherwise the whole thing will be opposed on security grounds.

Hm, you bring up a good point. For example, your asking who are the 
endpoints when I send an email to a mailing list, right? I've one 
source endpoint, but multiple destination endpoints. So it's not 
sufficient if only one of the endpoints authorizes a service.

Now, in case of this example, sending to the mailing list results 
basically in multiple transmissions to individuals, in which case 
we're back to a scenario with two endpoints.

Any thoughts from anyone?

> I am not sure about what you mean in this as SMTP Messages when you 
> refer to HTTP Messages. You will find that SMTP will probably used in 
> OPES related application as application signal and message transport. 
> Even if you do not want to take theses mechanisms in consideration, what 
> IMHO removes a lot of interest to effort when you consider real life 

Not sure whether I understood the above, but the wording now is 
"Define a rules language to control the selection and invocation of 
HTTP-based or SMTP-based OPES services." which I would assumeto be 
adequatly clear.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 17:14:22 -0600 (MDT)

On Tue, 13 Jul 2004, Markus Hofmann wrote:

> > How will P interpreter know what parameters are available? Which
> > parameters are optional? What are their types?
>

I am not sure you can get away with this without making a major
sacrifice. I agree that how _you_ learned about the parameters is out
of scope. However, P interpreter has to check your rules and translate
them into specific OCP messages. To do that, it needs to know what
parameters Service_A has (by name or position), which of them are
optional, and what their types are.

You can say that the programmer will supply parameter names and/or use
much more dangerous positional notation. While technically possible,
it would make it impossible to check your rule set for correctness
without executing it. For example, if P interpreter does not know that
Service_A only has two parameters, then P interpreter cannot tell you
that the above code snippet with Service_A(p1, p2, p3) is buggy. Only
the service can, at runtime.

Same for parameter types. You can get away with trusting the
programmer to supply the right types, but in reality that means that
a P interpreter will not be able to detect a type mismatch.

	invoke Service_A(p1, p2, p3);
or
	invoke Service_A(p2, p1, p3);

will all look the same to the interpreter (but not to the service!).

We know how poor humans are at writing bug-free code.  I think that
being able to validate much of P code off-line is an essential rule
language feature that we should strive to preserve. Unfortunately,
that seems to require informing the interpreter of service interface,
independent of P code itself.

Can we have a safe/validate-able service invocation without the
knowledge of service interfaces (service "feature" definition in terms
of OCP)?

Thanks,

Alex.

P.S. If P programs are "rules", what should we call P programmers?
     Rulers? :-)

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 17:18:48 -0600 (MDT)

> If it has no deliverables, why should it be on the charter?

So that folks external to the WG (e.g., OCP implementers) know that
they have come to the right place when searching for help/advice. Some
would assume that, but some might not. And so that we can offer that
advice/help on the mailing list, without being told that it is out of
our charter scope.

> No, they can be brought in in the context of the work items we
> already have.

But we will not have any work items in OCP/HTTP context.

It is not a big issue for me, especially since IETF does not usually
do protocol maintenance (unfortunately), but I think it would be a
good idea to add the blob, even without any specific deliverables. The
deliverable, in this case, is a service to the community, to the
protocol implementors and such.

Thanks,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 20:57:35 -0400

> independent of P code itself.

You start convincing me... Could any of the existing service 
description languages (WSDL?) be of help? Abbie was suggesting this 
before I believe...

I see the following options:

(1) Rely on the rules authors to specify the correct parameters
     and don't do any offline checking -> no mechanisms for service
     description needed
(2) Have an OPES specific "service interface description language"
     (maybe similar to function declarations in some programming
     languages?) -> would be part of the rules language (?)
(3) Rely on an existing solution and require OPES services to be
     described in this language -> nothing to do for us other than
     refering to existing solution.

Now, my feeling this that this already goes into discussing the 
solution, I don't see a need to specify any of this in the re-charter. 
The proposed charter text seems to cover and allow for this work, so I 
would assume we're ok in this respect.

> P.S. If P programs are "rules", what should we call P programmers?

Sure, OPES rules :)

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 21:18:10 -0400

Folks,

what we need to solve now is the issue with respect to "what SMTP 
element to focus on first", and whether distinguishing between SMTP 
elements makes sense - see below from earlier emails.

> I guess until we know for sure the proposal aboce makes sense. I'll put 
> the proposed text in the draft charter for now.
> 
> already, what SMTP element would you suggest, what's needed first? What 
> makes sense?

So, following questions:

(a) Does it make sense to distinguish between different SMTP roles?
(b) If the answer to (a) us 'yes', what role should we focus on first,
     i.e. where's the most practical need?

Thanks,
   Markus

---

From: Geetha Manjunath <[email-masked]>
Date: Wed, 14 Jul 2004 09:52:32 +0530

Alex Rousskov wrote:

> <stripped>

Alex,
Won't that info be available while  "discovering a service" ie., your
(following) first addendum item  ?
- Defining how available services become known
          to the rules language interpreter? (At least
          OCP-speaking services)

regards
Geetha

---

From: Geetha Manjunath <[email-masked]>
Date: Wed, 14 Jul 2004 09:55:17 +0530

> would assume we're ok in this respect

Agreed!

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 22:27:53 -0600 (MDT)

> description languages (WSDL?) be of help? Abbie was suggesting this

Yes, and (after reading the corresponding Content Networking
chapter:), I also suspect that we can reuse WSDL core. This will
require some serious work on our part though. Current WSDL profiles
are based on SOAP and MIME(?), not OCP. We will have to define an
OCP-specific profile and then define how WSDL/OCP can be used to
describe OCP-speaking services for P interpreters.

I can see benefits, but I do not know whether the whole scheme will
work -- it all depends on how flexible WSDL core is, how many
W3C-centric assumptions are in that core. Since this is not a trivial
exercise, it may be a good idea to add P-services interface as a
chartered work item, possibly without a separate deliverable since we
already have multiple "document(s)" for P-related specs.

Yes.

>      refering to existing solution.

... Other than defining how to apply that existing solution
(e.g., WSDL) to OCP-speaking services. AFAIK, OCP-speaking services
cannot be described using any existing WSDL profile. We will need to
build one. This makes (2) and (3) equivalent, unless (2) assumes
service interface declaration *in P*.

Declaring services natively in P is good because it does not require P
interpreter to know another language/interface like WSDL.  Declaring
services in WSDL is good because it allows P interpreter to easily
interoperate with both classic Web Services speaking SOAP and
OCP-speaking services (in theory).

Ideally, you want to obtain the declaration from another, independent
source. In case of Java or C++, that source would be a library
header/interface file. If we use P declarations, we can encourage
service writers to supply them off-line (just like C library writers
supply header files with the library) and even runtime via OCP (to
kill buggy invocation calls before they generate data traffic on the
wire).

> solution, I don't see a need to specify any of this in the
> re-charter.  The proposed charter text seems to cover and allow for
> this work, so I would assume we're ok in this respect.

I am worried that if we want to define WSDL profile for OCP, some of
us (or some of IESG) will find that extending W3C technology like WSDL
is out of current charter scope. We do not know whether using WSDL is
the right way to go, but should we just mention that we need to

	Define P-services interface, based on existing interface
	description standards like WSDL, if possible, or OPES-specific
	description otherwise.

Thanks,

Alex.

---

From: Geetha Manjunath <[email-masked]>
Date: Wed, 14 Jul 2004 10:17:48 +0530

Alex Rousskov wrote:

> <stripped>... unless we want to expand P scope to affect things like preview

I am sure this is right. If the service is say, "virus scanning", by changing the
preview size of the stream being sent, you cannot probably tell the scanner to
change its execution path . On the other hand, the OPES service may be able to
dictate the preview size required for it to function.. Basically, it will boil
down to negotiation over the callout protocol .

thanks and regards
Geetha

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 22:57:26 -0600 (MDT)

> (a) Does it make sense to distinguish between different SMTP roles?

For those like me, fuzzy on MUA, MSA, MTA, and MDA definitions, here
is some text I found (please post better references if available!)

RFC 2821 says:

   SMTP servers and clients provide a mail transport service
   and therefore act as "Mail Transfer Agents" (MTAs).  "Mail User
   Agents" (MUAs or UAs) are normally thought of as the sources and
   targets of mail.  At the source, an MUA might collect mail to be
   transmitted from a user and hand it off to an MTA; the final
   ("delivery") MTA would be thought of as handing the mail off to an
   MUA (or at least transferring responsibility to it, e.g., by
   depositing the message in a "message store").  However, while these
   terms are used with at least the appearance of great precision in
   other environments, the implied boundaries between MUAs and MTAs
   often do not accurately match common, and conforming, practices with
   Internet mail.  Hence, the reader should be cautious about inferring
   the strong relationships and responsibilities that might be implied
   if these terms were used elsewhere.

http://www.ietf.org/internet-drafts/draft-hutzler-spamops-00.txt says:

   The Internet email architecture distinguishes four message-handling
   components:

   o  Mail User Agents (MUAs)

   o  Mail Submission Agents (MSAs)

   o  Mail Transfer Agents (MTAs)

   o  Mail Delivery Agents (MDAs)

   At the origination end, an MUA works on behalf of end-users to create
   a message and performs initial "submission" into the transmission
   infrastructure, via an MSA.  An MSA accepts the message submission,
   performs any necessary pre- processing on the message and relays the
   message to an MTA for transmission.  MTAs relay messages to other
   MTAs, in a sequence reaching a destination MDA that, in turn,
   delivers the email to the recipient's inbox. The inbox is part of the
   recipient-side MUA that works on behalf of the end-user to process
   received mail.

   These architectural components are often compressed, such as having
   the same software do MSA, MTA and MDA functions. However the
   requirements for each of these components of the architecture are
   becoming more extensive, so that their separation is increasingly
   common.

Given the above, I think MTA is an appropriate first target. Since we
are OPES, we should be looking for an intermediary here. Targeting
MUAs would be like targeting browsers in OCP/HTTP profile, right? The
latter is not theoretically inappropriate (nobody can clearly define
what an intermediary or "edge" is), but also not important enough for
OPES right now.

Moreover, could we try to simplify the charter by removing all other
SMTP agents from it? Can we just hope that OCP/SMTP profile with a
focus on MTAs will be applicable enough to MSAs and MDAs? We can
always add MSA- or MDA-specific features later, right?

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 23:15:33 -0600 (MDT)

On Wed, 14 Jul 2004, Geetha Manjunath wrote:

> I am sure this is right. If the service is say, "virus scanning", by
> changing the preview size of the stream being sent, you cannot
> probably tell the scanner to change its execution path . On the
> other hand, the OPES service may be able to dictate the preview size
> required for it to function.. Basically, it will boil down to
> negotiation over the callout protocol .

I had an even more dynamic case in mind, where some P code will tell
the invoked service or OPES processor (after the service invocation),
that the service can have 10 more bytes, then 30 more bytes, etc.
(depending on some conditions expressed in P). That would be execution
control. I do not think we want to go that far for now.

Configuration before invocation is clearly in scope.
	s.a = 1;
	invoke s;

Negotiation over OCP might be in scope, but only if P hides the
details:

	if (s.supportsFoo()) then {
		s.a = 1;
	} else {
		s.b = "bar";
	}
	invoke s;

P interpreter should be free to implement "supportsFoo()" call via OCP
negotiation with the service if static information about Foo support
is not available, right?

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 23:29:42 -0600 (MDT)

>           to the rules language interpreter? (At least

Good question. It all depends on the result of service discovery. If
the result of service discovery is service ID and IP:port pair, then
no. If the result of service discovery is service ID, IP:port pair,
and complete service profile, then yes. I assumed the former context.

In many cases, the service interface will be hard-coded in some OPES
processor configuration file, avoiding any dynamic discovery.  The
question is, do we want to be able to write a P interpreter that only
understands one (standard) service interface description (possibly
supplied by the service vendor) as opposed to supporting multiple
non-standard description formats (also possibly supplied by service
vendors)?

And, even if we declare standardizing service interface description
out of WG scope, we still must document how an invocation call in P is
translated into OCP commands, right?

Thanks,

Alex.

---

From: Geetha Manjunath <[email-masked]>
Date: Wed, 14 Jul 2004 11:54:49 +0530

That's right!
So I beleive, it becomes mandatory to explicitly define 'how to interface external
modules to P?'

regards
Geetha

---

From: Geetha Manjunath <[email-masked]>
Date: Wed, 14 Jul 2004 12:07:12 +0530

> and complete service profile, then yes. I assumed the former context.

I assume the latter context ;-) Atleast that is what is done for  web service
discovery.

> translated into OCP commands, right?

How about supporting non-std interfaces as additional module?

For example (pl forget the syntax for now):
Services.invoke(serviceA,1,2);
// Invokes the std OCP service, serviceA  - OCP service supported by default.

import  ICAPService // A special module that supports invoke method on ICAP
services
ICAPService.invoke(serviceB);

Geetha

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 14 Jul 2004 10:06:20 -0400

> what an intermediary or "edge" is), but also not important enough for

I'm *no* expert on SMTP or email in general, but I would tend to agree.

> always add MSA- or MDA-specific features later, right?

Sounds ok to me. Anyone any strong feelings?

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 14 Jul 2004 10:34:08 -0400

> 	description standards like WSDL, if possible, or OPES-specific

What about the following:

   In addition, the WG will define a rules language to control
   selection and invocation of services by an OPES processor. This
   includes a mechanism allowing an OPES processor to perform a runtime
   check of service parameters, leveraging existing interface
   description standards like WSDL, if possible, or OPES-specific
   description otherwise.

-Markus

---

From: jfcm <[email-masked]>
Date: Wed, 14 Jul 2004 19:07:40 +0200

At 23:24 13/07/04, Markus Hofmann wrote:
>I think this is exactly what I describe above and you agreed on, so we're 
>in agreement here.

I am sorry. This is not.

"The WG will specify one or more OCP profiles for SMPT to support OPES 
services that operate on SMPT messages" would be same phrasing.
I expect that you will say it is not what you want. This is precisely what 
I want you to dig into. Because SMTP is structurally different and I do not 
think that OPES can apply to the whole SMTP system.

>>The answer does not match the question. In one to one direct access http, 
>>I know who are the parties. I one to many possibly rerouted mailing I do 
>>not know what you mean by parties. Has to be clarified otherwise the 
>>whole thing will be opposed on security grounds.
>
>endpoints when I send an email to a mailing list, right? I've one source 
>endpoint, but multiple destination endpoints. So it's not sufficient if 
>only one of the endpoints authorizes a service.
>
>basically in multiple transmissions to individuals, in which case we're 
>back to a scenario with two endpoints.

No. For several reasons.

1. the mailing list the information is sent to is part of the information. 
That information cannot be modified without the agreement of the whole 
mailing list. If I send a mail to this list saying that you do not 
understand this point and I make an OPES to remove you from the list
     - I agree so it is OK by your criteria
     - you will not respond, so everyone will believe you do not object
     - I send another mail agreeing but I make an OPES changing the from 
jfc in from markus (I can do it since I am one end). Everyone will 
understand that you have agreed not understanding this point
... and you will know nothing of this.

2. Again I am A, you are B and someone is C. An OPES changes B in C. C will 
be the receiving end. He has agreed to the change. Is that enough? May be 
if B gave authority to C, maybe not if B has not.

>Not sure whether I understood the above, but the wording now is "Define a 
>rules language to control the selection and invocation of HTTP-based or 
>SMTP-based OPES services." which I would assumeto be adequatly clear.

OK. I suggest that we are extermely carefull at using the word "message" 
without explaining it, in a signal-message-mail-datagram passing environment.

jfc

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 14 Jul 2004 14:40:46 -0400

jfcm wrote:

> I expect that you will say it is not what you want. This is precisely 
> what I want you to dig into. Because SMTP is structurally different and 
> I do not think that OPES can apply to the whole SMTP system.

I fail to see a big difference in the wordings, but if it makes you 
feel more comfortable, would the follwing work:

   ... the WG will specify one or more OCP profiles that will support
   OPES services operating on SMTP messages.

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 14 Jul 2004 14:46:54 -0400

jfcm wrote:

[I separated this response from the others and gave it a new subject, 
since I believe it's important]

> 1. the mailing list the information is sent to is part of the 
> information. That information cannot be modified without the agreement 
> of the whole mailing list. If I send a mail to this list saying that you 
> do not understand this point and I make an OPES to remove you from the list
> 2. Again I am A, you are B and someone is C. An OPES changes B in C. C 
> will be the receiving end. He has agreed to the change. Is that enough? 
> May be if B gave authority to C, maybe not if B has not.

See your point, but the example you outline above violates the OPES 
tracing requirement, which says that Markus (or B in the generic 
example) must be able to trace the OPES service. I.e. I would be aware 
of the OPES service that removed me.

Now, I'm not yet sure how to achieve this and whether this is the 
full/correct answer...

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 00:45:27 -0600 (MDT)

> Alex Rousskov wrote:
>
> P interpreter should be free to implement "supportsFoo()" call via
> OCP negotiation with the service if static information about Foo
> support is not available, right?

On Wed, 14 Jul 2004, Geetha Manjunath wrote:

> So I beleive, it becomes mandatory to explicitly define 'how to
> interface external modules to P?'

Mandatory only if by "external modules" you mean "OCP-speaking OPES
services". Interfacing with them is required for OPES framework to be
complete. Interfacing with something else (e.g., a Java class
implementing a content adaptation service, C library implementing
P/HTTP module, or an ICAP service) is not required/mandatory.

Are we on the same page?

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 00:51:59 -0600 (MDT)

>    description standards like WSDL, if possible, or OPES-specific

Sounds good to me. I assume there will be a sentence somewhere about
documenting interfaces for P/HTTP and P/SMTP modules. Or is that
implied?

Injecting "investigate" before "a mechanism allowing" may make Abbie
happier. Or we can replace "includes" with "may include". Is that what
you are after, Abbie?

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 01:02:05 -0600 (MDT)

> ICAPService.invoke(serviceB);

Sure, that's the intended feature/beauty of P design! If we get the
abstraction level high enough, 3rd parties would be able to add all
sorts of modules doing all sorts of interesting things, while P
programmers will not even notice.

Do we agree that defining such additional modules or even defining an
interface to plug such additional modules into a P interpreter is
outside of our current scope?

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 01:47:19 -0600 (MDT)

On Wed, 14 Jul 2004, Markus Hofmann wrote:

> > 2. Again I am A, you are B and someone is C. An OPES changes B in
> > C. C will be the receiving end. He has agreed to the change. Is
> > that enough?  May be if B gave authority to C, maybe not if B has
> > not.
>
> example) must be able to trace the OPES service. I.e. I would be
> aware of the OPES service that removed me.

Tracing does not work for one side if the message is killed or
short-circuited by another side. If I send an HTTP request to a porn
site, my corporate proxy blocks the request, then the porn site will
not know I sent the request. This is a corner case of a message not
reaching the other side at the consent of the originating side.

IMHO, jfc's example is broken (for the lack of a better word) because
when jfc talks about changing distribution lists or From headers, he
assumes both that the mailing list has no reliable authentication
_and_ that unauthenticated changes may have negative affect on
subscribers. Both things are true for most IETF mailing lists!

However, since subscribers know the environment is not secure, but
still subscribe, they accept the risks. In other words, they
technically authorize the adaptations jfc is talking about. They
consent to receive forged e-mails and to being silently removed from
the distribution lists. Both things did happen many times in IETF. I
was even lucky enough to be the subject of the latter.

Thus, we are talking about a two-party consent case. Nothing "bad" is
happening in jfc examples from consent point of view.

In a "good" mailing list environment, jfc would either not be able to
change/forge headers OR doing so would not have an impact on the
subscribers.

HTH,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 15 Jul 2004 09:10:04 -0400

> was even lucky enough to be the subject of the latter.

I remember that :)

> happening in jfc examples from consent point of view.

So, what you're saying is that (a) there are mechanisms in place that 
can prevent things like the ones described in the example, and (b) if 
users accept an environment that doesn't use these mechanisms, they 
implicitly accept that things mentioned in the example can happen, so 
they basically consent that this can happen?

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 15 Jul 2004 09:18:28 -0400

> documenting interfaces for P/HTTP and P/SMTP modules. Or is that

The charter lists the corresponding deliverable as "Define a rules 
language to control the selection and invocation of HTTP-based or 
SMTP-based OPES services.". Since the text previously stated "This 
includes a mechanism allowing an OPES processor to perform a runtime 
check of service parameters", I would assume that takes care of it.

> happier. Or we can replace "includes" with "may include". Is that what

Working on that issue implies doing prior investigation of existing 
approaches, so I'd assume we're OK here.

-Markus

---

From: jfcm <[email-masked]>
Date: Thu, 15 Jul 2004 13:35:43 +0200

At 20:46 14/07/04, Markus Hofmann wrote:
>tracing requirement, which says that Markus (or B in the generic example) 
>must be able to trace the OPES service. I.e. I would be aware of the OPES 
>service that removed me.
>

This is excactly my point and that responds Alex's question over my more 
general comment (Alex thinks "how". I think "what").
- I am not sure how to achieve this - IMHO this cannot be achieved by an OPES
- is what we say a correct answer ? because we debate within an 
"end-to-end, dumb network/smart host, protocol on the wire" vision of a 
network system, which architecturally totally opposes our target of 
external-change-in-multiple-alternative-routes

This is why I quoted the Judge who had a parallel problem and who gave it a 
solution I can architecturally accept : considering the mail when 
temporarily stored at an Agent. There is no difference with HTTP (and Alex 
there is right): in both cases what we discuss is changing the header and 
the payload when stored on a host. The particulars of HTTP blurred that 
debate (my initial discussion) because it permitted to consider the stream 
as a virtual host. The particulars of "one to interacting many" of mail 
services do not permit that.

I fully agree with Alex: there will be no drastic change in OCP and P etc. 
But this will not be OPES and there will be impossible problems of 
interoperation with the interconnected interapplications - as mentionned 
above. Authorizations, Error reporting, cancellations, priorities, delays, 
orders, authentication, application interface, LHS acceptation, security, 
authoritative domains, relation with the DNS, resends, archiving, 
inter-OPES operations, server failures, spam, etc.

Just one small question. Let assume a change is conditional to time. What 
is the time we chose as a reference. The time the mail was entered, the 
time it was sent, the time it reached each OPES filter, the time it reached 
every OPES filters, do we take into account the time the first mail or the 
last mail reached the filter? Let assume a very common case : authority 
changes at a given time (a different watch, a justice decision, etc.) and 
also the management rules.

jfc

---

From: jfcm <[email-masked]>
Date: Thu, 15 Jul 2004 12:55:36 +0200

At 20:40 14/07/04, Markus Hofmann wrote:

>>what I want you to dig into. Because SMTP is structurally different and I 
>>do not think that OPES can apply to the whole SMTP system.
>
>I fail to see a big difference in the wordings, but if it makes you feel 
>more comfortable, would the follwing work:
>

yeap. Thanks.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 17:40:51 -0600 (MDT)

On Thu, 15 Jul 2004, Markus Hofmann wrote:

> Alex Rousskov wrote:
>
> > Thus, we are talking about a two-party consent case. Nothing "bad"
> > is happening in jfc examples from consent point of view.
>
> So, what you're saying is that (a) there are mechanisms in place
> that can prevent things like the ones described in the example, and
> (b) if users accept an environment that doesn't use these
> mechanisms, they implicitly accept that things mentioned in the
> example can happen, so they basically consent that this can happen?

Yes.

OPES cannot be blamed for breaking something that is already broken.
If something is already broken, OPES should not be expected to fix it.
If something is not broken, OPES is expected to keep it that way.

IAB concerns and such only apply to non-broken environments. They are
meaningless in broken environments that already violate them without
OPES help.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 15 Jul 2004 17:54:23 -0600 (MDT)

On Thu, 15 Jul 2004, jfcm wrote:

> I fully agree with Alex: there will be no drastic change in OCP and
> P etc.  But this will not be OPES and there will be impossible
> problems of interoperation with the interconnected interapplications
> - as mentionned above.

I am not sure I have the energy to debate abstract "what is OPES?"
questions, but I do want to make sure that there are no "impossible
problems" with specific solutions we develop.

Can you give a specific example of an impossible technical problem?
Not a vague problem of "what do we call it?" or "who consented to this
change?", but a specific technical problem? An example where a working
system is badly broken by introduction of OPES-compliant SMTP
adaptations...

> Just one small question. Let assume a change is conditional to time.
> What is the time we chose as a reference. The time the mail was
> entered, the time it was sent, the time it reached each OPES filter,
> the time it reached every OPES filters, do we take into account the
> time the first mail or the last mail reached the filter? Let assume
> a very common case : authority changes at a given time (a different
> watch, a justice decision, etc.) and also the management rules.

It would be up to the rules author what time to use, on a per-message
basis, I think:

	if (system.time() > 15:30) { ... }
	if (message.ua_sent_time() < 13:10) { ... }
	if (random() > 0.5) { ... }

Are all valid P statements, triggering OPE adaptations. Where is an
"impossible [technical] problem" here?

Thanks,

Alex.

---

From: Geetha Manjunath <[email-masked]>
Date: Fri, 16 Jul 2004 15:45:52 +0530

> P/HTTP module, or an ICAP service) is not required/mandatory.

No, I want to differ slightly here.. Specifying tht interfaces with OCP-speaking
OPES services  is mandatory (as you agree). However, I think we should also
specify  the interfacing with external  module , atleast to some extent. One of the
sample use cases is invocation of non-OCP services as we discussed in the attached
mail... Having said that, I realize that it is not possible to define/specify how
to interface all the different types of modules (types based on authored language -
Java, Python, P) onto P. But, I guess we need to define a list of mandatory API's
that the module needs to provide in order to interface with a P rule set. The exact
way in which the external module interfaces with the P runtime/core
(language/runtime issues) is left to the implementor. These API's could be
reflective in nature, used by the P runtime (at the minimum) for validating a P
program. Whether to make it available to the rule writer or not can be debated
later, I guess.
Examples:
M.moduleHasFunction(functionName)
S.serviceHasParameter("a")
M.getModuleAttrList()
S.isOCP()

Do you agree?

thanks & regards
Geetha

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 16 Jul 2004 17:12:16 -0600 (MDT)

On Fri, 16 Jul 2004, Geetha Manjunath wrote:

> Examples:
> M.moduleHasFunction(functionName) S.serviceHasParameter("a")
> M.getModuleAttrList() S.isOCP()

Hmm... Are you proposing some kind of "symbol table" API that would
specify what objects the module exports, by name? So that the core
interpreter could check that all names in a rule set are defined
without actually loading/executing the module?

If a module exports an object called "request", will the API also
define that the "request" object has "headers" and "body" sub-objects?
But the API will not define how an interpreter can actually access
"body" or even "request", right?

What purpose would that API serve other than code validation?

Thanks,

Alex.

---

From: jfcm <[email-masked]>
Date: Sat, 17 Jul 2004 00:16:20 +0200

>OPES cannot be blamed for breaking something that is already broken.

OPES are violating the principles of the Internet. This is not that much
visible with HTTP because HTTP is real time one end to one end.

On can support the idea that OPES is a nasty idea, or that the Internet
is "broken" (limited). I support the second one.

>If something is already broken, OPES should not be expected to fix it.

This is not a good response - or stop working on them.

OPES can provide limited answers to needs the Internet cannot address.
But they do it in breaking the architectural principles of the Internet
(protocol on the wire, end to end, smart host/dumb network, ... etc.
please refer yourself to Harald's IETF mission Draft "core principles").

No to waste our time and to provide a good service, we can work
on where your OPES concepts can provide solutions,
_within_the_limits_that_an_internet_architecture_permits_.

The charter must define these limits.

- Either we work on SMTP Mail part and the mails are massaged when
stored on an agent, we are outside the network (you defined the OPES
that way against my suggestions). OCP is used for its qualities.

- Or we work on SMTP Transfer part and only the headers are massaged
and this corresponds to a gigantic extrension of the SMTP protocol. I
suppose several other WG will be interested.

- Or we work on an hyper-inter-complex-mail-transfer protocol as you
plan. OK. You ask for an example. Please tell me what in the charter
would prevent me to take the expected result and build a good and
complete working model of the world's evolution since the Big Bang.
Just HICMTP and OPES.

Again, I have nothing against it (I presisely think _it_is_ the way it
works(ed)). But I feel a first attempt calls for more precise
boundaries or explanations and - even if you dislike it - to tell what
OPES are.

But again, I may be dumb stupid. Or a complete fool. I have no
objection to you demonstrating that no one needs an architect
when building a house. But you have to do it. I am not to demonstrate
you are wrong here, you have to demonstrate you are right. Convince
me and I will support you.

After all, all what I am trying to do is to avoid you waste your skills,
time and OPES/P/OCP image just because you will deliver a good
1% of what you claimed you would. Spend a little more time in
defining your target as 1% so you will be thanked for delivering
100% of what you promised.

jfc

---

From: Geetha Manjunath <[email-masked]>
Date: Mon, 19 Jul 2004 18:55:34 +0530

Pl see my comments inline...

> without actually loading/executing the module?

That;s right. Infact, this is pretty common in object oriented runtimes
which allows dynamic loading of modules (like Java, Python) - this is what
is often referred to as "reflection API".
One of the uses (as you mention) is validating whether a P program is
correct . This is however very important - since the validation can be
done just once, at the time a P program is loaded onto the OPES processor
- rather than everytime a P program is executed ( request/response)

> "body" or even "request", right?

Yes - that is implementation dependent. The OPES processor is free to run
a P runtime/core engine that was developed  in any language - and the
specifics of this interfacing actually depends on the languages chosen and
so on -- which is clearly out of our scope.

> What purpose would that API serve other than code validation?

See my comment above.
In addition, specifying the mandatory API's that need to be supported by
an external module - allows us to clearly and completely specify the
requirements of a P runtime engine - for somebody to go ahead and
implement in different ways. At somepoint, it will also enable P modules
to be used on multiple implementations of P runtime - which is one of the
implicit goals of OPES (I beleive).

Thanks and regards
Geetha

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 19 Jul 2004 11:50:11 -0600 (MDT)

Geetha,

	I understand your motivation better now, thank you. I wonder
whether we can use the same generic approach to describing "loadable"
modules and services. This would match the "service is a module"
approach we talked about just before P work got frozen awaiting for
new charter.

	Do you have a proposal of what to use for publishing
declarations of module interface? P? WSDL? Something else? Can you
point us to documented examples of similar interfaces for other
languages?

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 19 Jul 2004 13:32:53 -0600 (MDT)

On Sat, 17 Jul 2004, jfcm wrote:

> OPES are violating the principles of the Internet. This is not that
> much visible with HTTP because HTTP is real time one end to one end.
>
> On can support the idea that OPES is a nasty idea, or that the
> Internet is "broken" (limited). I support the second one.

... Or that there is no violation if the principles of the Internet
are interpreted in the current context rather than read literally. I
think that's the only way to meaningfully interpret any principle, and
I dare to say that IAB is using that "context interpretation" approach
in RFC 3238.

> This is not a good response - or stop working on them.

Done! We are not working on fixing application protocols. We are
working on creating new functionalities on top of those protocols, in
environments where those protocols are not broken or will be fixed (by
others).

> OPES can provide limited answers to needs the Internet cannot
> address. But they do it in breaking the architectural principles of
> the Internet (protocol on the wire, end to end, smart host/dumb
> network, ... etc. please refer yourself to Harald's IETF mission
> Draft "core principles").

Please refer to RFC 3238 for interpretation of those core principles
in OPES context.

> The charter must define these limits.

IAB has defined those limits in RFC 3238. Do you think we need to add
additional limits? If yes, what would those additional limits be?

> that way against my suggestions). OCP is used for its qualities.

I do not understand the "SMTP Mail part" scope. I also do not
understand "stored" in this context. Can you define those two in OPES
context? For example, current OPES protocols do not depend on whether
somebody considers the application message "stored" or "in transit".
Why are you talking about "stored" messages? What is so special about
them that is relevant to OPES?

> and this corresponds to a gigantic extrension of the SMTP protocol.
> I suppose several other WG will be interested.

I do not understand the "SMTP Transfer part". I am not sure why we
would want to limit ourselves to adapting MIME(?) headers only.
Translating e-mails at recipient's request, for example, sounds like a
good use case for modifying more than just headers.

> plan. OK.

Not sure what you mean here.

> You ask for an example. Please tell me what in the charter

Not sure what you mean here. I am asking for examples of problems that
we should fix in the charter. I am not sure how world's evolution is
related to that.

> Again, I have nothing against it (I presisely think _it_is_ the way
> it works(ed)). But I feel a first attempt calls for more precise
> boundaries or explanations and - even if you dislike it - to tell
> what OPES are.

I believe that OPES Architecture draft, with all its limitations, sets
some boundaries and (with the Use Cases draft) provides some
explanations. To provide more precision, we would first need to agree
on where we currently lack precision. If you can identify specific
boundary problems, we can try to address them.

> After all, all what I am trying to do is to avoid you waste your
> skills, time and OPES/P/OCP image just because you will deliver a
> good 1% of what you claimed you would. Spend a little more time in

I cannot spend more time on solving an unidentified problem. If you
see a problem, please define it so that we can discuss and solve it.
The level of the problem can vary from architecture to protocol
specifics.  It can be an OPES scope problem, an OPES architecture
problem, an OPES charter problem, an "SMTP adaptation problem", or
whatever, but you have to tell us what exactly we should fix or
improve.

And, for the record, since it did come up before, "what is OPES?" is
not a problem. It is a question already answered in OPES WG documents.
If you do not like the answer, please explain what needs to be
fixed/added to that answer so we can work on that.

Thank you,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Mon, 19 Jul 2004 14:58:00 -0600

I have sympathy with Morin on two of these issues (assuming I understand
what he's saying).

The notion of "consent" was seriously eroded in the architecture
documents, and I have always felt it was a mistake.  Endpoints have no
guaranteed means to configure their OPES profile, or even to discover
it.  That should be remedied.

However, the current discussion has, at its heart, this question:

  Will OPES modify SMTP message bodies?

There is an obvious slippery slope adjacent to modification of email
content.  With HTTP, the information is usually meant for many
recipients (anyone who asks).  For SMTP, it is frequently
individual-to-individual, and privacy concerns are paramount.  I'd
argue that a very high standard of privacy and integrity protection
should accompany any venture into this area.  We need at the minimum a
document on "security and integrity guidelines for OPES SMTP
services".

I see some nugget of an idea about doing message body adaptation on
the mail agents themselves (the agents that store messages, like POP3
servers), and I always felt that was the way to go for most of the
SMTP services.  The only compelling argument for modifying the message
body "in the network" is to remove malicious code, though even that is
a slippery slope (my ISP insists on removing the MIME type URL in IETF
announcements).

Hilarie

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 19 Jul 2004 18:02:53 -0400

> document on "security and integrity guidelines for OPES SMTP

While I'm the last one to endorse unauthorized modification of email 
(I actually have to live with it every day), I stopped assuming that 
email is private a long time ago - at least from a technical 
perspective, not a legal one. When I want an email to be private, I 
encrypt it. OPES cannot fix existing privacy problems, but it should 
also not worsen them. I assume that's what you meant?

HTTP information is increasingly personalized, i.e. no longer 
necessarily meant for many recipients. Privacy conerns in this context 
can be solved by offering delivery of content via https - just as 
emails can be encrypted.

Do we expect that "security and integrity guidelines for OPES SMTP 
services" will be fundamentally different from the ones for HTTP, or 
would it make sense to cover them in the "Security Considerations" of 
the SMTP-related protocol drafts?

-Markus

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Mon, 19 Jul 2004 16:27:29 -0600

Privacy consideration in handling email have always been and still
remain an important responsibility.

I expect SMTP security and integrity guidelines to be considerably
stronger than HTTP guidelines.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 19 Jul 2004 16:46:48 -0600 (MDT)

On Mon, 19 Jul 2004, The Purple Streak, Hilarie Orman wrote:

> should accompany any venture into this area.  We need at the minimum
> a document on "security and integrity guidelines for OPES SMTP
> services".

Hilarie,

	Can you help me understand why "SMTP security guidelines" are
far more important than "HTTP security guidelines"? The above text
implies, to me, that misleading millions (anyone who asks) is somehow
less important than misleading an individual. I suspect that is not
your motivation for the "SMTP security guidelines" document, but I am
not sure what is.

	Certainly (IMHO), spam and phishing already educated everybody
that could be educated that they should not trust ordinary e-mails
more than an ordinary web page. Thus, we are not talking about some
elevated level of trust (compared to HTTP) that OPES ought to protect.

	Perhaps we can start from a different angle: How would
"security and integrity guidelines for OPES SMTP services" document
differ from what this WG and the IAB already wrote about security
aspects of OPES?

> the mail agents themselves (the agents that store messages, like
> POP3 servers), and I always felt that was the way to go for most of
> the SMTP services.

IMHO, the "best" agent/location for adaptation depends on the
adaptation. For provider-authorized adaptations, SMTP agents closer to
the provider are usuallly more appropriate. That usually includes MTAs
and excludes IMAP or POP servers. For user-authorized adaptations,
SMTP agents closer to the user are usuallly more appropriate. That
often includes MTAs (when user controls them) and IMAP or POP servers.

> The only compelling argument for modifying the message body "in the
> network" is to remove malicious code, though even that is a slippery
> slope

There are many compelling (IMHO) arguments for adapting the message
body on the edge of the network: A group of clients behind the same
edge may want to attach a French translation to every English e-mail.
An IP-to-WAP edge may want to reformat HTML and strip images. A CDN
may want to insert local ads into mailing list postings. Doing all of
the above adaptations at the IMAP or POP server may be impractical.

> (my ISP insists on removing the MIME type URL in IETF
> announcements).

Let's assume your ISP is using OPES for the above adaptation. If you
have authorized your ISP to adapt your e-mails by agreeing to their
policies, then there is no problem from OPES point of view. If you
have not authorized, you can take your ISP to court and/or switch ISPs
(the practically of either solution is outside of OPES scope, of
course).

Thanks,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 19 Jul 2004 16:59:58 -0600 (MDT)

> remain an important responsibility.

So have been handling of HTTP or any other kind of Internet traffic.

Legal hickups notwithstanding, the notion of privacy does not depend
on a low-level transfer protocol. As a trivial example, consider the
fact that millions get and send e-mail via HTTP-driven web sites.

> stronger than HTTP guidelines.

Understood, but I (personally) need more facts/illustrations/reasoning
to get excited about working on a yet another abstract (for the lack
of a better word) OPES document. It seems that Markus and I are asking
the same basic question:

	- What will we write about SMTP security that we have
	  not written already?

And, perhaps,

	- What will we write about SMTP security that we did not
	  have to write about HTTP security?

We agree that mail security is important, but I do not think you are
answering the above questions. Perhaps an outline of the proposed
"SMTP security" document might help?

Thanks,

Alex.