Errors-to: owner-drums@CS.UTK.EDU
Date: Thu, 1 Jun 1995 12:38:28 -0700 (PDT)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: Re: changes 
To: "Michael D'Errico" <michael.derrico@software.com>
Cc: drums@CS.UTK.EDU
In-Reply-To: <19950601192115375.AAA93@rome.software.com>
Message-Id: <MailManager.802035508.19114.mrc@Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Thu, 01 Jun 1995 12:21:46 -0700, Michael D'Errico wrote:
> This would certainly clean up my address parser, but there is at least one
> case that would not carry forward to the new definition.  Since <word> is
> defined to be either an <atom> or a <quoted-string>, you could no longer
> have something like:
>     From: "Michael D'Errico"."Technical Support"@Software.com
> Granted this format is rarely (if ever) used, but it would become illegal
> under the new definition.

Good point.  My parser swallows this OK, although it'll consolidate it into
one quoted string which isn't correct.  Most other parsers that I've seen do
much worse.  Is anyone actually is able to use this capability in real life?

> Also, any mailer that currently folds long lines based on tokens could break

> a new system that uses these rules.  For example, half of a domain name
> could be separated from the other half by CR LF SPACE (I believe zmailer
> used to do this).

C.2.1 in RFC-822 forbids this behavior; no LWSP is permitted between "." and
surrounding lexical tokens.

This is the basis of my claim that "." should be removed from specials,
because the only true effect that this complex set of rules has is to forbid
an atom from beginning or ending with ".".

This restriction is often violated (perhaps the most frequently violated).
Those of us who comply with it are repeatedly badgered by individuals who (1)
want their personal names to show their middle initial with the period and (2)
do not want their personal names to have quotes around them.  These people,
unfortunately, tend to be managers who have little sympathy for protocol
purity, especially when some other package "does it right".

> I'm in favor of these simpler rules, but we also need to make sure we
> consider all the effects.

Good point.