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:[email protected]]
>> *Sent:* Thursday, January 13, 2005 2:55 PM
>> *To:* OPES Group
>> *Cc:* Markus Hofmann; Martin Stecher; [email protected]
>> *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