John C Klensin wrote:
If they are not _all_ true, then we end up with either a
procedural or a technical difficulty with this conversation and
maybe with the document. Partially because it seems so obvious
to me that these uses of 0yz or 1yz codes should be supported by
an extension to be sure that the client and server are in
agreement about how to interpret what is being done, I continue
to believe that we have a communications problem here rather
than a substantive one, but I may be wrong and may not
understand what is being proposed and why.
The problem as I see is that you are being uncharacteristically
inconsistent in how you applying SHOULD or MUST for this issue and the
persistent reply code issue. You are using a premise there are NO
systems in 25 years of possible operations or in your eyes not enough
important systems are actually implementing, supporting or using this
in some form or fashion. That is an incorrect presumption and basis to
lock down these items.
The VERB issue is not the same. Here a CLIENT is compliant because it
issued this VERBosity command. Whether its was a formal extension or
proprietary, the CLIENT is in full control here and knows how to handle
the this "05x " response line.
Now, the question here as I see it whether a SERVER has the formal
specification blessing to issue "1xy " or "xyz-" as part of a multiple
line response to clients.
The answer is a RESOUNDING yes and the many years of fine tuning, time
tested, evolving, published, or unpublished behavior supporting this
behavior beg the question as to why we would enforce a spec change to a
MUST for both of these issues when there is a possibility that it made
alter, perhaps uncommon, yet perfectly SMTP acceptable and supported
Common practice or not, you are basically saying
"Well, I don't know anyone who is using this, so I guess we
better close this loophole before it becomes a problem."
The point is is that it hasn't been a PROBLEM in practice because
everyone is following the specification.
Again, you simply do not know whether its use in practice or not and to
what levels because NO ONE has ever complain it was causing problems.
That is very uncharacteristic of how I have come to learn the IETF
process which I have had depended on for common sense engineering.
This one completely goes against all common sense. It shouldn't be a
matter of playing the game of semantics but to clarify what is the
actual possible practice evolved over 25 years.
Just look at how it has been interpretation at:
You can't just throw that out into the waste basket. It is important
consideration on how the industry has evolved. Whether it is common
practice is insignificant. What is common practice is that all clients
handle it appropriately and if they do not, they are not following the
formal and suggestive written specs. It just isn't an issue.
Application of the robustness principle as the usual
disambiguator of such things says that the server ought to send
homogeneous codes because that eliminates any sensitivity to
"first", "middle", "last" or "all".
Thats fine, and its good material when you are starting from scratch and
it is also good advice for a very conservative and simple SMTP server to
apply in its transactions. But for that matter, using your
conservative robustness principle, if it was really concern for the
server, then it SHOULD NOT use Multiple Lines. The 2821bis suggestion
would be "avoid them."
The point is that it has possible and always been possible and by far
clients have evolved to followed the 25 year old formal declaration of
using only a "xyz[sp]" concept to the command response and ignoring
continuation reply codes in lines with "xyz-".
What are you basically implying that we have a problem with clients not
supporting the 25 year specification so therefore we better LOCK it down
to a MUST (persistent reply codes) and a MUST NOT use "1yz-" and thats
simply not correct.