Message-Id: <199603112155.QAA22383@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Mark Crispin <MRC@panda.com>
cc: John Gardiner Myers <jgm+@cmu.edu>, drums@cs.utk.edu, moore@cs.utk.edu
Subject: Re: Free insertion of linear-white-space 
In-reply-to: Your message of "Mon, 11 Mar 1996 10:35:21 PST."
             <MailManager.826569321.18793.mrc@Ikkoku-Kan.Panda.COM> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 11 Mar 1996 16:54:59 -0500
Sender: moore@cs.utk.edu

> > Same thing goes for whitespace
> > inside the domain.
> 
> This, I am pretty sure, was banned, although I forget where.  It may have been
> during the days when DCA could administratively ban protocol syntax that they
> didn't like, and such acts took precedence over any document.

I'd just as soon NOT prohibit comments/white-space inside a domain.
(they're pretty much the same problem from an implementation point-of-view.)

The rationale is: either you write your code to deal with comments and white 
space or you don't.  We're not going to do away with comments and white space 
altogether, so you have to deal with them in some cases if you're going to 
accept legal rfc822 messages.  Making special rules as to when you can and 
cannot insert white space or comments isn't so hard on something that 
*generates* 822, but it makes a parser more complicated than it would 
otherwise have been.  So I'd prefer that we require parsers to accept comments 
and/or white space between any two tokens of a structured field body. 
Alternatively, we put comments and white-space explicitly into the grammar, 
but that makes a real mess of the grammar.

> The best way to do accomplish this ban is to remove all the domain and domain
> literal syntax rules (which are wrong anyway!) from 822bis.  This can be done
> quite simply by taking ".", "[", and "]" out of specials.  I have done so in
> my parser, or rather, I have two separate specials; the one I use for parsing
> and the one I use for generating.

The working group agreed in Dallas to not change the set of specials.
The working group agreed in Los Angeles to permit the use of "."s in
phrases that preceed addresses.

These may be mutually conflicting.

I *think* this could be done while still keeping the grammar LALR(1)
if the productions for local-part and phrase were left-factored to
introduce a new production like:

dotted-word-list =  word / dotted-word-list "." word

...which was then used for both local-part and as part of a phrase.
But I haven't yet managed to do so without producing parsing conflicts.

(of course, spaces and comments are *significant* in a phrase, but
not within a local-part, so you still have to do some post-processing,
but this is no worse than the present rfc822 grammar)

My personal view is that the clearest way to write a specification is
to 

a) write the *grammar* according to what you have to be able to *accept*,
and 

b) to write *prose* that clearly specifies, for each field and/or 
grammar symbol, what you are allowed to *generate*.  

(This on the theory that you write a parser for 822 while looking at the 
grammar, but you follow the prose description when writing message generating 
code.)

At any rate, for every field, we somehow need to make a very clear distinction 
between what you must accept and what you may generate.


> It does not matter that 822bis permits
> 	blurdybloop@]sara[.soop.
> or not.  Separate rules for DNS syntax as applied to mail suffice to ban this
> practice, and since those rules may need tweaking for IPV6 anyway we might as
> well get them all vestiges of them out of 822bis.  You can't implement DNS
> names in a vacuum using just 822.

This will be the case no matter what we decide about "."s, comments, or
white space.  However, DNS itself is not very restrictive, so that might
not solve the problem by itself.

--------
Take the pledge! "I do not limit my speech to satisfy the whims of Congress."