Re: Getting 2822 to Draft

Keith Moore wrote:

> > The one possible big thing has to do with the ABNF in 2822. Out of 
> > either altruism or insanity, some time ago Bruce Lilly had written up 
> > changes to the ABNF in 2822 to do some cool things. On the plus side, 
> > it seems to get rid of all of the [C]FWS shift-reduce conflicts, and 
> > it is already done. On the minus side, I don't know anyone (myself 
> > included) who has gone over it with a fine tooth comb, it is a 
> > significant number of ABNF changes, and it therefore might recycle us 
> > at Proposed. I am open to suggestions on this.
I can't comment on insanity (catch-22).  I decided to build a 
grammar-based parser because
I was tired of writing (and rewriting) application-specific 822 
parsers.  I started a couple
of months after 2822 was published, which was a big help primarily 
because of the formal
and explicit use of FWS and CFWS vs. 822's rather vague text.

> if the new grammar accepted the same language as the old one, I'd 
> consider it nothing more than a clarification of the spec, and a reset 
> to Proposed would be unnecessary.
> or if the only differences could be seen as minor bug fixes to the old 
> grammar, I'd consider it a minor bug fix to the spec.
The intent is to accept the same message text as the existing 2822 
grammar, modulo some minor
glitches in 2822.

> IMHO simplifying the grammar and getting rid of parsing conflicts 
> would both be highly desirable improvements.  if it then becomes 
> possible to feed the ABNF to a parser generator and generate a 
> verifier for 2822 messages, that's a huge win.
Whether it's "simpler" is perhaps debatable.  Shift/reduce conflicts are 
eliminated.  Generating
a verifier for 2822 [822/733/724/561/MIME/etc.] isn't quite as easy as 
feeding the ABNF to
a parser generator, but it is possible to feed something quite close to 
the ABNF to a parser
generator (http://users.erols.com/blilly/mparse). And that parser 
generator can be used to build
a message verifier.  The complete grammar (2822/822/MIME/various 
extensions/most of 733,
724, 561) has no unresolved shift/reduce conflicts and a single 
reduce/reduce conflict (due to
changing grammar of the MIXER Supersedes (formerly Obsoletes) field, 
resolved in favor of
the current (RFC 2156) definition).

> why not post the revised ABNF as an I-D so that others can go over it 
> with a fine tooth comb?  or has this already been done, and I missed it?
An earlier version of the revised ABNF has been posted to ietf-822 and 
the full version
(with encoded-word grammar) is available at the above URI.  Let the 
combing begin.