Date: 18 May 1998 11:54:25 -0000
Message-ID: <19980518115425.26534.qmail@cr.yp.to>
Mail-Followup-To: drums@cs.utk.edu
From: "D. J. Bernstein" <djb@cr.yp.to>
To: drums@cs.utk.edu
Subject: Re: State of 821bis and RSET inconsistency
References: <SIMEON.9805171235.F@p6.mci.net> <14375.895472196@munnari.OZ.AU> <19980518085023.25359.qmail@cr.yp.to> <15478.895483920@munnari.OZ.AU>

Robert Elz writes:
> Sure, that means more words to read, but having read them one knows the
> answers, rather than being left wondering,

Here's what the client does; here's what the server does in response.
End of story. There's nothing to wonder about.

> Eg: if one reads 821 and then looks to implementing the DATA (and RSET
> etc) commands, and then starts to wonder what should be done if someone
> should send "DATA FOR YOU\r\n"

That's not an option for the client. Que sera, sera.

821 didn't say ``The client can send DATA parameters as defined in other
documents; the server must send 504 for unrecognized parameters.''

(Nor did it say ``The client can send commands defined in other
documents; the server must send 500 for unrecognized commands.'' It's
always amusing when designers blame implementors for the designers'
failure to think ahead.)

> Much better if the doc simply says explicitly what is right - whether that
> is to ignore any parameters, or whether it is to send a parameter error
> code is less important - but it should always be explicit in the doc.

Have you had a chance to read RFC 2119 yet?

If an implementor finds it easier to ignore parameters, he can. If an
implementor finds it easier to reject parameters, he can. Unless there's
evidence of interoperability problems, it's a waste of time to suggest
one strategy.

---Dan
50000 new aliases in 6 seconds. http://pobox.com/~djb/fastforward.html