Peter J. Holzer wrote:
You can't just throw that out into the waste basket.
Why not? There are tons of bad books out there which belong into the
waste basket. To be fair, a simple mixup of sender and recipient in a
case which can only happen if the server uses an extension not defined
in any RFC is probably easy to miss (I had to read the sentence several
times to see what was wrong with it and I was specifically looking for
an error).
The key difference in this text was the 1yz was literately interpreted
as a "PRELIMINARY code" not a COMPLETION code, which literally means
there more codes are pending.
Second, given the fact that 1yx are not currently defined for current
commands, it should be ignored. That is something that isn't
specifically stated but implied. The 821/2821 specs simply "implies"
that there is NO expectation for these codes to exist in any of the
current commands and may be useful in an extended environment.
But in either interpretation, what do you do when your code does
encounter it?
well you do what MOST systems will mostly like do - ignore it and when
it coupled with a "-", it justifies it when coupled with the formal
definition in section 4.3 "SMTP Replies" for "xyz[sp]"
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-".
Except that this has not been formally defined for 25 years. That is
your interpretation of an (admittedly not perfectly clear) 25 year old
specification.
As one of the developers in the community and market place, it has been
very clear. As formally defined in section 4.3 "SMTP Replies" for the
reply code:
Formally, a reply is defined to be the sequence: a
three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
reply (as defined in the same section).
Coupled with the logical suggestive text for handling multiple lines -
look for the first "xyz[sp]" non-continuation line, I don't see how you
can screw that up and practice has shown it hasn't been an issue. Why
would a serious SMTP system go against this? There is no reason why it
would.
What are you basically implying that we have a problem with clients not
supporting the 25 year specification
No, we are concerned that clients which are supporting the 25 year old
specification will be rendered non-compliant if your interpretation is
formalized.
But my interpretation matches what is already written and already
existed in practice. I'm not altering functionally as this new lock down
text threatens to do with a greater possibility.
Can you show one system that will not use the first non-continuation
reply line encountered? How do you know there aren't systems out there
that is using this?
What you are agreeing with has a greater chance of breaking new
development when they do encounter it. It might even ABORT the
transaction because it may enforce persistent reply code concept.
The chances the interoperability issues is less when you provide
clarified insight that this is already possible and to emphasize that
what is more important is the formal ABNF:
Reply-line = Reply-code [ SP text ] CRLF
and not:
Reply-line = Reply-code "-" [text ] CRLF
Which is what you are supporting that we still accommodate? Why even
bother with this?
C: command
S: 250-blah
S: 250 done
when the following is sufficient in your view I presume?
C: command
S: 250-blah
S: 250-done
All I am asking here is to clarify that is already existed - the formal
reply code does not have a DASH in character #4, and the first
non-continuation is the reply code per specification.
At the very least, the text should use "SHOULD" as a persistent reply
code suggestion, not a MUST.
--
HLS