Re: RSET scope issue

[Philip Hazel <[e-mail]>]

On Mon, 14 Aug 2000, Chris Newman wrote:

> There is a bug in the definition of the RSET command in section 4.1.1.5 of 
> draft 12.  The current text follows:
> 
>   4.1.1.5 RESET (RSET)
> 
>   This command specifies that the current mail transaction will be aborted.
>   Any stored sender, recipients, and mail data MUST be discarded, and all
>   buffers and state tables cleared.  The receiver MUST send a "250 OK" reply
>   to a RSET command with no arguments.  A reset command may be issued by the
>   client at any time.  It is effectively equivalent to a NOOP (i.e., if has
>   no effect) if issued immediately after EHLO, before EHLO is issued in the
>   session, after an end-of-data indicator has been sent and acknowledged, or
>   immediately before a QUIT. In other situations, it restores the state to
>                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   that immediately after the most recent EHLO.  An SMTP server MUST NOT 
> close
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   the connection as the result of receiving a RSET; that action is reserved
>   for QUIT (see section 4.1.1.10).
> 
> The sentence I have marked is incorrect in the presence of the "AUTH" or 
> "STARTTLS" extensions and is generally contradictory with the definition of 
> "RSET", namely to reset the _transaction state_ rather than the _connection 
> state_.
> 
> I propose that the sentence marked above be deleted.

I support this change.

The first sentence in effect makes the point about resetting the 
transaction rather than the connection, but this could be made clearer. 
(The wording of the first sentence is also a bit odd - a command doesn't 
usually "specify", and the use of the future tense reads oddly.) Here is 
a minor revision:

   This command causes the current mail transaction to be aborted. It 
   resets the state to what it was at the beginning of the transaction. 
   The state of the connection itself is not affected. Any stored sender 
   .... etc.


-- 
Philip Hazel            University of Cambridge Computing Service,
[e-mail]      Cambridge, England. Phone: [phone].