Re: smtpupd-12: <SP> optional in replies?

[John Beck <[e-mail]>]

Gregory> Section 4.2.1 states, "In many cases the SMTP client then simply
Gregory> needs to search for the reply code followed by <SP> at the beginning
Gregory> of a line."

Gregory> Earlier in section 4.2, the document claims the <SP> part of the text
Gregory> portion of the reply and is therefore optional (the ABNF backs up
Gregory> this fact).  The quoted text from 4.2.1 conflicts with this.

I agree that there are some minor inconsistencies here which should be
resolved.  4.2 says:

---
An SMTP reply consists of a three digit number (transmitted as three
numeric characters) followed by some text unless specified otherwise in
this document.  ...  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 section 4.2.1).  Since, in violation of this
specification, the text is sometimes not sent, clients which do not receive
it SHOULD be prepared to process the code alone (with or without a trailing
space character).  ...

In ABNF, server responses are:

  Greeting = "220 " Domain [ SP text ] CRLF
  Reply-line = Reply-code [ SP text ] CRLF
---

and 4.2.1 says:

---
The format for multiline replies requires that every line, except the
last, begin with the reply code, followed immediately by a hyphen, "-"
(also known as minus), followed by text.  The last line will begin with
the reply code, followed immediately by <SP>, optionally some text, and
<CRLF>.  As noted above, servers SHOULD send the <SP> if subsequent
text is not sent, but clients MUST be prepared for it to be omitted.

For example:
   123-First line
   123-Second line
   123-234 text beginning with numbers
   123 The last line

In many cases the SMTP client then simply needs to search for the reply
code followed by <SP> at the beginning of a line, and ignore all
preceding lines.  ...
---

If omitting the text is in violation of this spec, doesn't that mean that
servers MUST send the <SP> and that the [] indicating optional don't belong?
Furthermore, why does 4.2 say clients SHOULD be prepared to do one thing yet
4.2.1 say clients MUST be prepared to do something similar?

I would personally favor tightening the spec, but consistency is the main
thing.  If we can reach consensus on what to say, I'll volunteer to come
up with some text to say it.

-- John