Re: [draft-ietf-opes-smtp-use-cases-01]

All,

just for clarification - submitting a -00 version of the draft does 
*not* imply that the draft is finalized. There's plenty of opportunity 
for suggestions and contributions after submission of the -00, which 
will then result in subsequent versions.
Thanks,
  Markus

jfcm wrote:
> Martin,
> you may be fully right. But I would suggest that we follow the agenda 
> proposed by Abbie. One week to understand and possibly enhance or review 
> the existing cases. I understand that you want to continue the work you 
> engaged. But for us your document is new and we need to digest your work 
> (just to make sure you listed all my cases and I do not see some others 
> :-). Or we may lose some thinking (and some Members) if we do not wait 
> for everyone to have time to come to speed?
> Thank you for the work done.
> jfc
>
>
> At 15:50 13/01/2005, Martin Stecher wrote:
>
> > Hi folks,
> >  
> > please have a look at chapter 5, the OPES SMTP based services.
> >  
> > We tried to find the similarities and differences to the HTTP case 
> > described in RFC 3752.
> > I believe that this is very essential for this document and will help 
> > us a lot when later doing the OCP profile.
> >  
> > After writing this first draft, I keep thinking about it and would 
> > like to simplify further.
> > Could I have your comments on the following please?
> >  
> > In HTTP we have a request that goes all the way from the client thru 
> > proxies to the server and the response going back the same way.
> > The commands and replies in the SMTP dialog are always just between 
> > each hop.
> >  
> > 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.
> >  
> > In total I see all use cases to deal with SMTP commands. The email 
> > message body is also nothing else but the value of a DATA
> > command.
> > We see services that want to modify command values and those that want 
> > to block commands by defining an error reply that the
> > MTA should send in response to the reply it received (for receiving 
> > mail activation point, see below).
> > So, we have command modification and command satisfaction, analog to 
> > request modification and request satisfaction that we
> > know from HTTP.
> >  
> > I do not see any use case that deals with response modification. Does 
> > anybody see a use case in which first the MTA should
> > check for the response of its peer and then forward that response to 
> > the callout server for further modification? What can be
> > modified here? Responses are only short acknowledgements or error 
> > codes. So turning an ok into an error would be possible
> > but the callout server does not really need to see the ok first, does it?
> >  
> > So, if you agree we can reduce everything to command modification and 
> > command satisfaction for every possible command.
> > Depending on the activation point (receiving or sending email) the 
> > OPES processor == MTA will do different things with the
> > callout server reply:
> >  
> >  1. MTA receives email, i.e. it receives SMTP commands and vectors 
> > them out to the callout server
> >        a) callout server modified the command value: MTA will treat 
> > the modified value as if it received it that way from its SMTP peer
> >        b) callout server returns an SMTP error-reply: MTA will send 
> > that error code to its SMTP peer
> >  
> >  2. MTA sends email, i.e. generates SMTP commands and vectors them out 
> > to the callout server
> >        a) callout server modified the command value: MTA will send 
> > modified command to its SMTP peer
> >        b) callout server returns an SMTP error-reply: MTA does NOT 
> > send the command to its SMTP peer but treats the error as if it 
> > received it from the SMTP peer
> >  
> > I can regroup all use cases to fall into the four categories plus the 
> > side effects that we see from some use cases (section 7.3)
> > Services operating on email message content (section 7.1) are not 
> > longer special. They are just the cases where the callout server 
> > operates on the DATA command.
> >  
> >  
> > Best regards
> > Martin
> >  
> >  -----Original Message-----
> > *From:* Abbie Barbir [mailto:abbieb(_at_)nortelnetworks(_dot_)com]
> > *Sent:* Thursday, January 13, 2005 2:55 PM
> > *To:* OPES Group
> > *Cc:* Markus Hofmann; Martin Stecher; abbieb(_at_)nortelnetworks(_dot_)com
> > *Subject:* [draft-ietf-opes-smtp-use-cases-01]
> >
> >     All,
> >
> >     attached is the first version of the
> >     draft-ietf-opes-smtp-use-cases-01.
> >
> >     This is the time to get engaed and provide feedback on the draft.
> >     Let us do that for the next week and then we can update it and
> >     send it to the ietf list as a WG draft.
> >
> >     Thanks
> >     Abbie Barbir
> >     Nortel Networks