RE: OPES/SMTP scope

Hi Alex,

> 
> 	Thanks for clarifying AP#4 and response modification 
> cases. We may have a  
> scope problem here, similar to what we had with HTTP when we 
> realized that  
> we have to deal with 1xx responses. OPES/HTTP scope is 
> adaptation of a  
> single HTTP request or a single HTTP response augmented by 
> request info.
> 
> In OPES/SMTP, we currently seem to be talking about adapting 
> a single SMTP  
> command or a single SMTP command response (augmented by the 
> corresponding  
> command info, I guess?). Is that the right scope? 

I guess we have consensus now that we concentrate on command
modification/satisfaction (see the other message I just sent
that double checks this).

Yes, I think we should consider one OCP request to correspond
to a single SMTP message.


> It was 
> reasonable to  
> limit OPES/HTTP scope to request/response because HTTP is 
> mostly stateless  
> (and OPES is not allowed to adapt HTTP connections which are kind of  
> statefull in HTTP). However, could it be a design mistake to 
> introduce the  
> same scope boundaries for adaptation of a stateful SMTP 
> dialog? It seems  
> to me that results/information from earlier commands would 
> have to be  
> known to OPES callout servers adapting later commands.

We assumed that many OCP servers in the HTTP response profile
need the original HTTP request as meta data and will request this.

Same thing here I guess.
If a OCP server indicates that it wants to act on the RCPT or
DATA command, it may also require the MAIL FROM data to be sent
as meta data because it wants to know about this sender and not
only the one listed in the email message's From header.

I tried to illustrate this earlier. See my message from Jan 13:
 > While we see the need to involve the callout server on a per-command basis,
 > the commands and replies of one dialog belong together
 > and services may have the need to refer to earlier commands of the same dialog.

> Should 
> OPES/SMTP  
> scope be an entire dialog related to a "single" email (and 
> not a single  
> command from that dialog)?? Can a callout server reliably 
> adapt an SMTP  
> dialog by modifying isolated commands, without controlling 
> and knowing the  
> entire command sequence??

Depends on the service I guess.
This should be negotiated with the profile I think. Which
commands is the OPES processor wants to allow to modify?
Which commands is the callout server interested to modify
and which commands are needed as meta data with later command
mod requests?
This should be negotiated.

I wonder whether we can reduce data exchange for services that
want to act on multiple commands by doing several command
modification requests within a single OCP transaction context.


> 
> What is the primary difference between OPES/SMTP and Milter 
> approach: If  
> we wrap Milter calls in OCP, would we get OPES/SMTP?

Needs someone who knows Milter better than me to answer.


Regards
Martin