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