ietf-822
[Top] [All Lists]

Re: Why the 822bis grammar is so painful

1999-02-09 12:05:03
Discussions about DRUMS topics on this list will not be taken into account
within the DRUMS WG.

The 822bis document passed WG last call -- meaning it had WG rough
concensus.  Unless the IESG determines something is unacceptable during
IETF last call and sends it back to the WG for revision, the subject is
closed in DRUMS. 

The parsing details of RFC 822 were widely misimplemented in numerous ways
in the field.  The only reasonable conclusion was that the grammar model
in 822 was inadequate for real world needs.

Personally, I think the 822bis grammar is a bit painful, but I believe it
is less painful than any alternative I saw and will result in fewer errors
in the field than the original 822 grammar model did.  While people with
academic backgrounds in parsing, such as myself, might find the split
tokenize-parse model attractive; a number of key software developers in
the email world lack this background and need something more
straightforward.

If someone had politely suggested a concrete and reasonable alternative in
1996/1997, perhaps we could have had something better.  But most of the
objections were of the form "I don't like this" and lacked a concrete
alternative.  Such comments have little value when trying to fix problems.

I actually figured out the 822bis grammar changes necessary to resolve the
one-atom-vs-two parsing distinction for fun.  But the problem is so minor
that fixing it isn't worth the complexity it would add to the grammar,
IMHO.  In the bigger scheme of things, the current grammar sufficies to
determine if headers are valid or invalid; and that's what's important. 

                - Chris