Re: FWS problem

[Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>]

Charles Lindsey wrote:

> When they start to develop RFC 2922bis, please join in and
> get them to remove some of their stupidities. But not now,
> for USEFOR.

It's not too bad, we'll fix their msg-id for the real world.

The remaining problems for 2822bis are only NO-WS-CTL and a
mandatory FWS after the colon.  I'm not too happy with our
SP plus "MUST be non-empty" for the body of the first line.

The old 2822 obs-stuff could be moved to an appendix together
with NO-WS-CTL.  The new obs would be a missing FWS after the
colon, ready, submit this 2822bis this year or wait for 2005 ?

> "Supersedes:" is just the example I chose to give.

Yes, my general idea to fix a leading or trailing [CFWS] did
not work as expected.  In the cases of Lines: and Supersedes:
it was intentionally ( [CFWS] => [FWS] ) => *WSP, because I
didn't want the comments there.

> the problem arises eberywhere you propose to use *WSP

Not where it was meant to replace [FWS] (all 7 cases of [FWS]
plus Lines: and Supersedes:).  It did not work for References:
(msg-id-list) and Injection-Info (but at least there was still
a real problem also with your syntax).

 [2822 FWS in Date:]
> that was an explcit exception put into RFC 2822 after
> discussion. But everywhere else it was understood that
> comments would be allowed wherever WSP was allowed. You can't
> have them in some headers but not in others, because no-one
> can be expected to remember which cases are which.

ACK, that's a point.  And References: _is_ a real 2822-header,
you only need a new syntax for it because you modified msg-id
and added msg-id-core.  And maybe because no separator at all
between msg-ids is dubious, s-o-1036 had 1*WSP.

> only because of loud protests by the server implementors that
> we agreed to make exceptions for the Newsgroups and Path
> headers, etc, but only on account of the performance hits.

Supersedes: is relevant for news servers, like Control:, where
you also have only three [FWS] or in the fixed variant two *WSP
and still one [FWS] in control-message.  No [CFWS] in Control:

For Lines: you could say that it's now deprecated and the old
syntax was Lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF

That's no lie, and if somebody tries new tricks with deprecated
headers, then old software might fail for Lines: (huge)9999(!)

> If there is something you want to forbid in a standard (such
> as empty header lines, etc), then it is an exceedingly Bad
> Idea to have two mechanisms for forbidding it

Then let's use your CWSP and WSPC trick.  It's a worse idea to
say something as a MUST in the text and then something else in
the syntax.  The [FWS] problem is already solved for 7+2 cases,
or 7+1 cases if you insist on Lines: (over)999(lines)

Only 5 (or 6) similar [CFWS] cases, all solved by your idea:

| WSPC = *WSP [ comment [CFWS] ]

Replace all (5 or 6) "leading" (near colon) [CFWS] by WSPC.

| CWSP = [ [CFWS] comment ] *WSP

Dito 5 or 6 "trailing" [CFWS] => CWSP (near CRLF), ready.
For our most critical example of the References: I get

| references  = "References:" SP msg-id-list CRLF
| msg-id-list = CWSP msg-id-core *( CFWS msg-id-core ) WSPC

That's a variant enforcing at least either a comment or a WSP
between msg-ids, it allows (x)<y@z>(a)<b@c>(u)<v@w>(e) and
<y@z> <b@c> <v@w>, but not adjacent <y@z><b@c><v@w>.   The RfC
2822 syntax is very similar:

| references  = "References:" 1*msg-id CRLF
| msg-id      = [CFWS] "<" id-left "@" id-right ">" [CFWS]

You don't use it, because msg-id one of these overloaded terms:

| msg-id      = [FWS] msg-id-core [FWS]

IMHO you should get rid of your special USEFOR msg-id, there's
exactly one line where you use it:

| message-id  = "Message-ID:" SP msg-id CRLF

Why not simply delete the special msg-id, and use msg-id-core ?

  message-id  = "Message-ID:" SP *WSP msg-id-core *WSP CRLF

                              Bye, Frank