[Top] [All Lists]

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

2007-04-22 17:24:07

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

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

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.


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