SM wrote:
If we are going to draw scenarios, then we have to
look into the actual retry codes being returned.
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.
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.
There are various cases for RCPT. IMO they all boil
down to three basic values 2xx, 4xx, and 5xx. That
gives us 2^3 = 8 possible mixes, including a case of
no RCPT at all.
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.
For the goal "retry clarification" we could remove
RCPT 5xx from the picture, this is clear and needs
no clarification. This reduces 8 rows to 4 rows.
The first row "no RCPT" needs no clarification, it
can be removed.
The 4th row "mixed 2xx- and 4xx-RCPT" contains two
results per cell, we'd still end up with four rows:
only-2xx, only-4xx, mixed-2xx, and mixed-4xx RCPT.
IMO the "5xx instead of 354" (no valid recipients)
column can be removed, in the only-2xx + mixed-2xx
+ mixed-4xx rows this means "server is confused":
Nothing to clarify here, the client is free to give
up (= bounce) without retry. And in the only-4xx
row this outcome needs no clarification, the client
can try again later.
The second column 354-2xx can be also removed, for
the 2xx-rows it means "mail was accepted, ready",
for 4xx-rows the client can try again later.
After that we are down to four rows and two columns
(354-4xx, 354-5xx) which might need a clarification.
We also have to understand the flow of events
instead of simplifying an elaborate document with
a chart.
Yes, it's the purpose of the abstraction to come to
an understanding of the elaborate document. If the
still remaining eight cells turn out to be related
to reality *and* are clear we might need no "retry
clarification" draft at al.
If they are not good enough (= again too simple) it
helps to pin down what is missing. And to note the
six assumptions how I arrived at this abstraction
with 4*2 cells. Otherwise we'd soon start to argue
in circles with folks trying to re-introduce cases
already eliminated as "need no retry clarification".
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
than 12 * 4 "S: xxx" "C: command" flow notations,
and tossing out 40 irrelevant cases before the real
fun begins. Two of the 4*2 cells represent JohnL's
example:
Rows mixed-2xx + mixed-4xx, column 354-5xx, what is
the client supposed to do ? You said it's "give up
on the 2xx, that was rejected, retry for the 4xx".
And if that is what running code anyway does, then
a "retry clarification" draft might be unnecessary.
Frank