[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-22 13:57:53

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 behavior?

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.


<Prev in Thread] Current Thread [Next in Thread>