Two observations, one substantive and one procedural...
Substantive: Yes. Regardless of how one feels about this
behavior in an alternate (perhaps even better) universe, in this
one, there is just too much established practice consistent with
Ned's description for second-guessing it to work. If someone
wants something else, it is probably time to dust off and finish
some flavor of per-recipient post-DATA reply model and see if it
gets any traction.
Procedural: It is probable that I can be talked into an AUTH48
change from "SHOULD not" to "SHOULD NOT" (and the RFC Editor may
catch it first). But anyone wanting _any_ change more
substantive than a change of case or similar editorial matter is
going to need to go to the IESG, ask that the approval of
2821bis be withdrawn and that a Last Call be initiated on the
change. If one were contemplating that, please do it soon, at
least well within the appeal window because, if you expect me to
do it quietly during AUTH48,... well, there is no chance.
john
--On Sunday, August 10, 2008 10:47 AM -0700
ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
<ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
>> As with temporary error status codes, the SMTP client
>> retains responsibility for the message, but SHOULD not
>> again attempt
> I note in passing that "SHOULD not" is bad standards-speak
> and needs to be corrected to "SHOULD NOT". Otherwise this
> is fine.
That's another call for "please fix the NOT":
<http://article.gmane.org/gmane.ietf.smtp/7481/match=auth48>
I'm not sure how "fine" it is, Hector's and your (among
others) interpretations are clearly different.
Hector appears to be mostly out on his own here. AFAICT SM,
Pete, all three Johns, Glenn, Tony F, Robert, and myself are
all in basic agreement as to what constitutes correct behavior.
...