Hi Frank,
At 07:04 PM 8/9/2008, Frank Ellermann wrote:
Hector proposed an abstraction. If this abstraction
agrees with reality (as in running code and 2821bis)
and is simpler to understand than existing prose with
long examples it is good for a "retry clarification"
draft.
The existing prose attempts to cover the breadth of SMTP whereas the
abstraction addresses specific scenarios. This discussion has gone
beyond retry clarification.
To arrive at a useful abstraction we have to reduce
the numerous scenarios, and for the "retry" business
we can IMHO assume that HELO and MAIL FROM went well.
I assume that HELO went well. It is a bit complicated for MAIL FROM
as we can have policies based on the MAIL FROM/RCPT TO pair. As we
are only considering the SMTP angle here, I'll assume that the MAIL
FROM went well.
Hector's table had only three rows, I think that was
an over-simplification. Three columns for the DATA
results 2xx, 4xx, and 5xx could be also too simple.
But four columns 5xx, 354-2xx, 354-4xx, and 354-5xx
could be a good abstraction. I tried three columns
plus a comment for all "there is no valid recipient"
cases. Ned pointed out that this is too simple for
PIPELINING.
It gets more complicated as we take PIPELINING into account.
Decision tables are a crude instrument, but if they
helped to reduce 8 * 4 cells (actually 12 * 4) to
4 * 2 cells, where each cell represents a flow from
HELO to QUIT, then that is good. Certainly simpler
Ned mentioned why a 4yz may not require a retry under certain
circumstances. We cannot depict that in a decision table.
Regards,
-sm