Subject: RE: Activation points and callout modes

From: "Martin Stecher" <[email-masked]>
Date: Wed, 2 Feb 2005 17:24:36 +0100

Jfc,

> - who are the "we" when you say "we won't do that as a humman command 
> interface" ?

From our charter:
  > In a next step, the WG will specify one or more OCP profiles that
  > will support OPES services operating on SMTP
OCP has no human command interface! That is why I said "we"

> - what is the purpose of this OPES work? Is it just to carry 
> some research 
> or to design operational network building blocks?

Again the charter:
  > In a next step, the WG will specify one or more OCP profiles that
  > will support OPES services operating on SMTP. In particular, the
  > profile to be specified will enable an SMTP server (the OPES
  > processor) to encapsulate and forward SMTP data and metadata to a
  > callout server for additional processing. 

This is what we are trying here. And to prepare this we are discussing
the specific use cases, activation points and callout modes needed for
OCP.

> - the language being used "OCP server/client" and an "MTA 
> becoming an OPES 
> processor" and a "callout server" does not make ANY sense to 
> me. 

Sorry jfc. We discussed and defined them over and over again while
working on our previous charter and also for the SMTP work.
These terms are also used in our current charter.

> This is a 
> middlebox language where the middlebox protocols are 
> affected/enhanced by 
> an external feature. This is not a server based Service 
> language. IMHO this 
> confusion does not help.

I will not further discuss this topic.

Regards
Martin

---

From: "Martin Stecher" <[email-masked]>
Date: Thu, 3 Feb 2005 09:16:57 +0100

> 
> At 17:33 02/02/2005, Martin Stecher wrote:
> > > I don't see how D (email body modification) "falls back" 
> to A (command
> > > modification), but as long as it can be done, I don't 
> care what letter
> > > gets assigned to it.
> >
> >On Jan 20 you replied to an earlier message saying:
> >   > Yes, I think that operating on the DATA portion fits into the
> >   > architecture without the need for special consideration.
> >
> >That is what I wanted to describe here again. The email 
> message body is
> >the data coming after the DATA command. It can be seen also 
> as command
> >modification. No special consideration necessary -> D "falls 
> back" to A.
> 
> This is true with unstructured text. But not with structured 
> text messages 
> (XML, ASN.1, proprietary formats, signals, etc.).
> 

I don't understand what the content type of the message body has
to do with this. Please explain.

---

From: jfcm <[email-masked]>
Date: Thu, 03 Feb 2005 23:06:18 +0100

I want to be able to consider it as an extened header.
jfc

Interesting: 
http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-08.txt under 
last call. I do not think there is any future with ENUM but I may be wrong 
and they have funding.

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 21 Feb 2005 07:53:00 -0500

[Forwarded email from Alex, who currently has problems posting to the 
OPES list].

> ------------------------------------------------------------------------
> 
> Subject:
> Re: Activation points and callout modes
> From:
> "Alex Rousskov" <[email-masked]>
> Date:
> Sun, 20 Feb 2005 22:48:01 -0700
> To:
> "Martin Stecher" <[email-masked]>, [email-masked]
> 
> To:
> "Martin Stecher" <[email-masked]>, [email-masked]
> 
> 
> On Fri, 2005/01/28 (MST), <[email-masked]> wrote:
> 
>>   1. Receiving email
>>      Do a SMTP dialog with the peer, receiving email from it,
>>      usually storing the emails in a queue and maybe sending on later
>>  2. Stored email in queue
>>      Operate on an email that has been received earlier. Their is
>>      no current SMTP dialog going on
>>  3. Sending email
>>      Do a SMTP dialog with a peer, sending email to it.
>>  4. Proxy (receive and forward)
>>      Having two SMTP dialogs at the same time. Mostly forwarding
>>      commands and replies; often no own email queue
> 
> 
> FWIW, it looks to me that, *from OPES point of view*, 1 and 3 are  
> essentially the same, and 4 is essentially a combination (or concurrent  
> application) of 1 and 3. Number 2 is out of OPES/SMTP scope; it could 
> be  in some future OPES/MIME scope.
> 
> This makes the situation essentially equivalent to the one we have in  
> OPES/HTTP: The difference between 1, 3, and possibly 4 can be 
> accomodated  by two or possibly three OCP profiles that share most of 
> their properties.
> 
>> In addition to that there are four modes
>>
>>   A. SMTP command modification
>>      The command is modified by the callout server
>>  B. SMTP command satisfaction
>>      Callout server responds with a SMTP reply (usually an error
>>      message).
>>  C. SMTP reply modification
>>      The SMTP reply is modified by the callout server
>>  D. Email message body modification
>>
>> Re C: SMTP reply modification seems to make sense for
>>     - reply logging (so no real modification)
>>     - At activation point 4, when commands and replies are proxied
> 
> 
> I do not yet understand why SMTP reply modification is essential for 
> AP#4  if it is not essential for other APs. Did I miss an example posted 
> earlier  (I did go through all the messages on the list)?
> 
>> Re D: When part of OCP/SMTP (not OCP/MIME or alike) this can be
>> seen as command modification, i.e. it falls back to mode A.
> 
> 
> Yes, at this level of abstraction there is no difference.
> 
> Alex.