Tony Hansen wrote:
As yet, there has been no discussion on this issue.
John C Klensin wrote:
In RFC 2821bis-01, Section 4.2.1 (Reply Code Severities and Theory), in
the description of the generic 4yz category, described the desired
action in terms of what the client "is encouraged to" do. I was
persuaded in an off-list exchange that this can reasonably be changed to
"SHOULD" and -01 reflects that change. For 5yz, there was a similar
construction that indicates that the client "is discouraged from"
repeating the request. I was less confident about changing that to
"SHOULD NOT", so the "is discouraged" text remains in -01.
Question: Should the 5yz description be changed to use "SHOULD NOT".
If not, is "SHOULD" in the 4yz description reasonable?
In my view, removing the subjective considerations and focusing on what
is the technical automated state machine consideration helps.
For 4yz, I think SHOULD is ok, but I think MAY is better when reworded
more appropriately. SHOULD implies some enforcement, when in fact, the
is not required to do so. The client MAY try again. I don't think the
original "is encourage to" is correct either - too subjective, but I
think your goal was to encourage "delivery" success, which I agree but
it should be part of the automation explanation.
Maybe the text should be:
4yz Transient Negative Completion reply The command was not
accepted, and the requested action did not occur. However, the
error condition is temporary and the action may be requested
again. Each reply in this category might have a different
interpretation and depending on the request, this response may
inform the client the transaction can not be completely at
this time, thus initiating a QUIT by the client. The SMTP client
MAY try again and it SHOULD try again if the condition increases
the success of delivering the message The SMTP client is
?required? to implement retry logic to complete the delivery of
the mail. See section 4.5.4. "Retry Strategies."
I think the last statement for 4yz should be moved to after 5yz or
before 4yz to generalize the consideration of which response code to use
in other to properly drive the client.
A rule of thumb to determine whether a reply fits into the 4yz or
the 5yz category is that replies are 4yz if they can be successful
if repeated without any change in command form or in properties of
the sender or receiver (that is, the command is repeated
identically and the receiver does not put up a new implementation.)
In the same vain, for 5yz, I think it should be a SHOULD NOT, but I also
think a MUST NOT is appropriate as well.
Maybe the text should be:
5yz Permanent Negative Completion reply The command was not accepted
and the requested action did not occur. The SMTP client
SHOULD NOT repeat the exact request (in the same sequence).
Depending on the request, it may trigger the requirement for
a different request (EHLO fall back to HELO), in others, it
may suggest the client may not be able to complete the
transaction. In such a case, it should proceed to gracefully
end the transaction (See QUIT command). Please note many
server implementations will monitor repeated fail attempts and
forcefully end the transaction if the client does not honor
the server response codes.
I see no need for the "Even some..." sentence since it is implied in the
first sentence (SHOULD NOT repeat the exact request) and in addition, it
wouldn't be the same request if the command data was changed. If the
goal was to inform the client that it may repeat an altered request
during the same session or at some future transaction, then 5yz would
not be the response, but instead 4yz.
Anyway, I think the main technical concept should be to emphasize the
technical behavior of the automated state machine and how these critical
codes drives the automation process. The 4yz informs the automated
client it is allowed to repeat the request in the same session or in the
future which implies the client MAY end the transaction and try again in
the future. A 5yz informs the client to not continue with the same
thing or end the transaction because repeating the same request isn't
going change the state.