In <fd0unn$5t9$1(_at_)sea(_dot_)gmane(_dot_)org> "Frank Ellermann"
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
Charles Lindsey wrote:
| 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.
I'd put it slightly different, AFAIK Netnews is the only case where
that's necessary, and structured header fields defined outside of
2822upd tend to use [FWS] instead of [CFWS] after the colon. And
unstructured header fields like Subject: also use [FWS]. What I get is:
| 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.
I don't think there is any serious difference between our two wordings
(except that I would still prefer "SHOULD" to "might"). As to other
protocols than Netnews that might be affected, I don't know of any, but
thought it might be useful to allow for the possibility.
No SHOULD, and carefully avoiding the (in e-mail) sound cases "empty
header field body" or "colon immediately followed by a folding". It
would even cover "HT doesn't help" without explicitly mentioning it.
I never intended that the awkward cases around empty field bodies should
have any explicit mention. I was rather just pointing out why they should
be left out - is spite of a small residual risk of further
non-interoperability.
{[NETNEWS] would then be an informative reference to the current
USEFOR draft, which has already passed IESG review.}
BTW, what happens if 2822upd is ready before USEPRO, could you (= the
USEFOR RFC editors) then still adopt a simplified 2822upd Message-ID
syntax in AUTH48 ?
For informative references, I think the rules for mentioning drafts have
now been relaxed. But 2822-bis already has normative references to other
drafts which may delay its final adoption. If this ever becomes a serious
problem, an informative reference to RFC 1036 would suffice at a pinch
(but that would be better left to final negotiations with the RFC-Editor).
Wrt the Message-ID I'd be happy if we arrive at a syntax for the RHS
without quoted-pairs and without NO-WS-CTL. The approved USEFOR I-D
still allows \[, \\, and \]. Let's please get rid of this cruft, it
would be horrible in news-URLs (%5C%5B, %5C%5C, %5C%5D). Plausible
Message-IDs don't need quoted-pairs in the RHS. Please correct me
if you know a case (MIXER or similar) where that's not true.
Agreed. I would like to get rid of quoted-pair in no-fold-literal even
if it is retained in domain-literal. I have no problem in allowing '\'
as an allowed character in no-fold-literal - just so long as it has no
semantic significance different from any other allowed character.
Let's better stay away from "\" outside of quoted-pairs,...
My only reason for offering a naked '\' as an "other character" was to
allow any presently allowed no-fold-literal still to be syntactially
allowed, even though now semantically different. It is not a big deal.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5