[Top] [All Lists]

Re: RFC2821bis-01 Issue 4: Client actions on receipt of 4yz and 5yz codes

2007-03-29 04:30:17

Tony Hansen wrote:
As yet, there has been no discussion on this issue.

Any comments?

        Tony Hansen

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.