ietf-openproxy
[Top] [All Lists]

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

2005-01-13 18:42:26
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