Message-Id: <199603110654.BAA20559@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: djb@koobera.math.uic.edu (D. J. Bernstein)
cc: drums@cs.utk.edu, moore@cs.utk.edu
Subject: Re: Message format document outline 
In-reply-to: Your message of "07 Mar 1996 23:33:01 GMT."
             <19960307233301.19938.qmail@koobera.math.uic.edu> 
Date: Mon, 11 Mar 1996 01:54:40 -0500
Sender: moore@cs.utk.edu

> I meant something stronger: An 822bis parser should properly parse any
> valid 822 message.
> 
> In fact, I propose that this be an explicit requirement for DRUMS.
> 822bis should be free to resolve ambiguities, and to say that lots of
> valid 822 messages must not or should not be generated, but _every_
> unambiguously valid 822 message must have the same meaning in 822bis.
> 
> The reason, again, is that mail messages stick around forever.
> 
> Reactions?

Basically I agree with this.  However, where there is ambiguity
in 822, we can choose to resolve that ambiguity, and when
current or past practice deviates significantly from that 
recommended by 822, we might choose to change the specs to 
recognize that practice.  Thus:

a) we can say that any blank line (whether it contains spaces
or not) is a separator between header and body.  This isn't
strictly correct according to 822, but for the vast majority of messages
in which a spaces-only line immediately follows message header fields,
that line was intended to be a separator line.  This was necessary
because BITNET/NHE wouldn't transmit zero-length records.  
(One could of course argue that BITNET is nearly dead, but then again 
there are all of those old messages still "sticking around"...so it's 
probably best to legitimize that practice when reading messages, if
not when sending them)

b) we can change the grammar to say that "."s in phrases are legal
(done right, this changes the interpretation of previously invalid 
messages, but does not change the interpretation of previously valid ones)

c) we can clean up the definitions of the resent-* fields, even though
it might invalidate behavior of some UAs or MTAs.

Keith