From: Bruce Lilly (blilly@erols.com)
Date: Sat May 24 2003 - 10:10:15 CDT
Charles Lindsey wrote:
> If there exists a feature (such as omitting the SP after the colon) that
> causes trouble in some systems (news systems as it happens), but which is
> never ever used (that I have seen) in either news or email,
[...]
> Or, in RFC
> 2822 terms, move it to the obs syntax in the next RFC 2822 revision. Would
> anyone notice or be inconvenienced by that?
Yes.
IETF-822 would surely notice, since it's their jurisdiction and not ours.
Such a substantive, far-reaching, fundamental change would almost certainly
require resetting such a 2822 successor to the initial rung on the standards
track ladder rather than permitting advancement to the next rung. That in
turn affects any documents that refer to the common message format RFC; a
Standards Track RFC cannot depend on a lesser document (in terms of progression
on the standards track) -- that is the reason why some recent RFCs
(e.g. RFC 3464) still use RFC 822 (a Standard) as the syntax base rather
than RFC 2822 (a Proposed Standard).
It would also lead to oddities such as a trailing space on
Bcc:
Anybody who has actually bothered to look surely must have seen many such
empty Bcc fields with no trailing space. Calling use of colon rather
than ": " as the field-name/field body delimiter, as colon has been since
RFC 724, "a feature" is peculiar; claiming that such syntax "is never ever
used" is blatantly wrong. RFCs for the message format clearly indicate that
the colon alone is the delimiter, and give examples where there is no
whitespace character following the colon. See RFC 733 V.D.2 (bottom of page 28)
and RFC 2822 A.5.
While the Bcc field can have field body content, there are other fields defined
where there is no field body at all (e.g. RFC 2156 Prevent-Nondelivery-Report).
Forcing a space into the field body where no field body is defined may have
unexpected consequences for parsers and will certainly require a change to
message generators.
All authors of all software generating messages in the common format for
all applications would be affected. X.400-822 gateways would certainly require
modification, as noted above.
The semantics of unstructured fields may be changed; currently any "text"
(including whitespace characters) following the colon is part of the field
body. You are effectively proposing changing the field-name/field body
delimiter from ":" to ": ", which moves a character from field body to
delimiter, producing a subtle and unexpected change in what comprises the
field body.
There remains the issue of header fields defined outside of RFC 2822, such as
those defined in RFCs 2045, 2156, 2557, 3282, 2369,... Many of those use
RFC 822 syntax rather than 2822 syntax. If you expect such fields to also
now require space-after-colon, all of the relevant RFCs have to be revised
(i.e. superseded) as well. That requires participation of other communities
(e.g. MHTML) as well.
Non-header fields (e.g. DSN and MDN fields) also use 822 syntax, so changes
also affect those fields and their defining RFCs (2298, 3464).
Obviously, under some circumstances there would be fields where, under your
proposed change, the first line would consist of the field name, the colon,
and a trailing space (as in the example of Bcc: above), possibly with a
continuation line. Trailing whitespace is known to be changed by some
transports and is known to cause problems in some cases.