Space after colon

On 2008-01-23, Tony Hansen wrote:
> 
> Pete Resnick wrote:
> > 
> > I'm separating out these two issues, as I want to hear yeas and nays 
> > (and explanations) from people other than Charles and Frank.
[...]
> > [On space after the ":"...]
> > 
> > [Charles originally wanted:]
> >>>> Although in all header fields the CFWS following the colon is 
> >>>> optional, it is customary to place at least one SP there; moreover 
> >>>> such a SP is mandatory in some related protocols (notably 
> >>>> [NETNEWS]). In order to facilitate interoperability with such 
> >>>> related protocols, that SP SHOULD normally be present.
> > 
> > [Frank suggested:]
> >>> Although all message header fields allow either [FWS] or [CFWS] after 
> >>> the colon, it is customary to place at least one white space 
> >>> character after the colon.  In NetNews articles [RFC xxxx] it's 
> >>> mandatory to use a space character after the colon, and in order to 
> >>> faciliate interoperability implementors might wish to separate the 
> >>> header field name plus colon from the header field body by a space in 
> >>> all Internet messages.
[...]

> Requiring a SP character after the : is a non-starter for me. I've used 
> a number of systems that use TAB instead of SP; they're still out there 
> and should not be considered invalid.

I tend to agree.  Moreover, as noted in draft-resnick-2822upd-04.txt
section 3.6.3, one use of the Bcc field is to leave the field body empty.
I have examined a large number of messages, and of those using the Bcc field
in this manner, only three included a space after the colon; the overwhelming
majority indeed had a truly empty field body (i.e. nothing between colon
and terminating CRLF.  Claiming space-after-colon as "customary" is flatly
wrong, at least for this widespread usage of the Bcc field.  It would be
silly and wasteful (using 7 octets to do what can be accomplished in 6) to
suggest that there should be a space in an otherwise empty field body.

If some non-normative text is included, it should be clearly labeled as
such AND it should be clearly reiterated that any message parser claiming 
conformance with the IMF specification MUST accept header fields with
an empty field body if permitted by the specific field syntax, with a
non-whitespace character immediately after the colon (including the
opening parenthesis of a parenthesized comment in structured fields which
use parentheses to delimit comments), with any reasonable (i.e. within
line length limits specified in the specification) number of space and/or
tab characters after the colon, and with line folding immediately following
the colon and preceding a non-empty field body.

It is also not correct to raise "interoperability" as an excuse for
attempting to push use of space-after-colon.  Gateways to/from other
protocols have to deal with a number of issues, and any specific
special-case requirements w.r.t. space-after-colon clearly fall into
the gateway implementors lap.

Since RFC 724 (May 1977, i.e. more than three DECADES!), whitespace
after the colon has been optional, and any implementation that does not
properly handle zero whitespace, or tab-after-colon is non-conforming
(i.e. broken) and therefore has no bearing on interoperability among
conforming implementations.  That said, it would be correct to point
out that both RFC 561 (the original IMF RFC) and RFC 680 (see RFC 724
for a discussion of RFC 680) did both require space-after-colon;
however, I would not want to burden readers of the next iteration of
the specification with such historical trivia as the specification
draft is already five dozen pages long, and there are far more important
issues that should be covered.