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
