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