At 15:20 -0400 on 04/11/2007, Tony Hansen wrote about Re: recap
rfc2821bis-01 Issue 17: all contination lines mus:
Please state your preference for one of the following. (I've broken
John's (ii) into two parts.)
(i) Do nothing, leaving the text as is
(ii-a) Make it clear that the codes may be different and
that clients are expected to respect the *last* value listed
(ii-b) Make it clear that the codes may be different and
that clients are expected to respect the *first* value listed
(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.
While I can see a reason for splitting ii into ii-a and ii-b so as to
document the two options, I do feel that a usage example for ii-b
should provided to should a valid case where ii-b is justified (as
was done for the 150-I'm_working_on_it case that was associated with
ii-a). If none can be provided, I think the option list should be
trimmed back to i/ii/iii with the ii having the proposed ii-a text
(IOW: The codes can differ BUT the last one is the one to use)
possibly saying that the continued codes should be parsed not just
ignored.
Also, I do not like the optional "Pick One" authority in iii. If you
are going to ignore the LAST result (the only valid one in a "Here is
my result" case when the prior replies are intermediate status
updates [as in the 150 case] as opposed to a single continuation
reply such as the EHLO 250) you should verify that all the codes are
the same and error out if they are different.
IOW: I vote for a wording that makes EXPLICATE that the last reply
(in a status vs. list case) is the only VALID reply and that prior
replies must not be substituted for it in any case where different
codes are permitted. I thus vote for either ii-a or iii (but iii only
with the "optional" permission REQUIRING that the others be validated
for consistency - IOW: If you pick the non-Last code, you must not
ignore the others by not checking for consistency and just ASSUME
they are/will-be the same).