--On Friday, 13 April, 2007 14:07 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
I am not proposing anything else but a "150-" as a PRELIMINARY
reply code for this purpose. No mixing of two or more
different 2xx, 3xx, 4xx, 5xx lines. If the server finds
itself where it needs to "keep the channel" alive, or show it
is still "working" it could issue the PRELIMINARY code 150-
before any other COMPLETION code is finally determined and
issued.
Hector,
Once again, if we were in the middle of the original DRUMS work,
it would have been be perfectly reasonable to propose:
(i) Define 150 as a code to be used only in multiline
responses as a placeholder and
(ii) Permit mixed codes in multiline replies as long as
all of them are the same except for zero or more
intermediate lines starting with 150.
But it is just too late to do that in 2821bis since it involves
new definitions and new functionality.
In my view of what is going on here, we are supposed to be
eliminating ambiguities and dropping unimplemented features (if
any). We can get rid of the apparent ambiguity about mixed
codes in multiline replies by prohibiting them or by explicitly
permitting them. But, if we do the latter, we need to specify
what happens if they are different _in the general case_. It
would be unambiguous to say, "well, in the general case, you
can't use multiline replies with different codes, but there is
this specific case involving '150' lines in particular
contexts....", but it involves new functionality for the
standard (i.e., regardless of what you have been doing in your
implementation and no matter how successful it has been), doubly
so because 2821 and its predecessors have never assigned any
semantics to a 150 code and the comment you take as authorizing
it at all is (IMO) clearly about final-position 1yz codes, not
their use as placeholders intermediate in multiline replies.
I just don't see any way out of this box. We either (i) retain
the ambiguities that you believe exist, or (ii) we add new ones,
or (iii) we add or change functionality. Or we end up
prohibiting what you ware asking for. We can't do (iii).
(ii) strikes me as a bad idea, inconsistent with our mandate.
And, once it has been persuasively argued that an ambiguity
exists, I see a rational way to leave it there if we know how to
fix it.
So, ironically, the more strongly you argue that the present
text permits multiline replies with different codes as long as
those codes follow one particular scheme, the stronger the
arguments get for insisting that all continuation lines use the
same code.
john