Peter J. Holzer <hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:
On 2007-04-13 10:07:19 -0400, John Leslie wrote:
Peter J. Holzer <hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:
On 2007-04-12 16:44:01 -0400, Robert A. Rosenberg wrote:
At 15:20 -0400 on 04/11/2007, Tony Hansen wrote...
(iii) Prohibit different codes and, optionally, suggest
that it is ok for a client to select one of them and
assume that all of the others are the same.
We're discussing a bug (IMHO) in 2821 which allows, in the case of
multiline replies to DATA (phase 2), different clients to have
different views of whether the message was accepted for delivery.
The bug is IMHO that it isn't completely clear whether all codes in a
multiline reply must be the same. Hector interpretes the current text to
mean that they can be different, while several other (including me)
interprete it to mean that they must be the same.
The question isn't whose interpretation is "right".
There isn't any clear statement in RFC2821 that different codes are
an error: thus, that spec allows Hector's behavior in a server. The
bug (as I said) is that such allowable behavior can lead to different
clients having different views of whether the message was accepted
for delivery.
I, at least, would like to say something like, "Absent agreement
between server and client on the meaning of different reply codes
within a multiline reply, the server SHOULD make all the codes the
same, and the client SHOULD generate an error if it receives
different codes."
I would go for "the server MUST make all the codes the same" here. Is
there anything to be gained from this ambiguity?
It's a smaller change; thus it increases our chances of getting to
Proposed Standard.
At most I would add a warning that an extension could allow different
codes in multiline-replies.
I would go for MUST language myself if we were starting from scratch.
Different codes strikes me as a bad idea. (I wouldn't like it even if an
extension were available.)
--
John Leslie <john(_at_)jlc(_dot_)net>