Date: Wed, 6 Mar 1996 14:56:51 -0800 (PST)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: Re: Message format document outline
To: John Gardiner Myers <jgm+@CMU.EDU>
Cc: drums@cs.utk.edu
In-Reply-To: <8lDVIWC00WBwQus20X@andrew.cmu.edu>
Message-Id: <MailManager.826153011.7721.mrc@Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Wed,  6 Mar 1996 17:43:46 -0500 (EST), John Gardiner Myers wrote:
> > Better would be to require field-body-contents to begin with non-LWSP,
> > something like:
>
> Depends on how important it is to allow contents of unstructured field
> bodies to start with a LWSP-char.  Effectively makes on difference to
> unstructured field bodies, modulo wording the boundary cases correctly.

Well, I don't think it's important for an unstructured field body to start
with an LWSP-char; in fact, most applications seem to strip LWSP after the
colon.  I think that it was certainly the intent that all these be equivalent:
	From:        Mark Crispin <MRC@Panda.COM>
	Subject:     blurdybloop
	Message-ID: <blurdy.bloop@sara.soop>

	From: Mark Crispin <MRC@Panda.COM>
	Subject: blurdybloop
	Message-ID: <blurdy.bloop@sara.soop>

	From       : Mark Crispin <MRC@Panda.COM>
	Subject    : blurdybloop
	Message-ID : <blurdy.bloop@sara.soop>


> Certainly can be discussed again.  Basically the problem is systems
> (such as VM/370-type dinosaurs) which add/remove trailing whitespace.
> Any software which generates header continuation lines which consist
> completely of whitespace would get their messages munged by such
> systems so that the line became a separator between header and body.

I understand the issue; the problem is that the change can introduce an
interoperability problem.  The issue for me is that I don't want to add a
requirement that a parser must recognize a headery/body delimiter line with
LWSP chars.

I recommend that both measures be done, specifically that:
	1) continuation lines without LWSP chars
	2) header/body delimiter lines with LWSP chars
both be outlawed, and that a header line with only LWSP chars is undefined.
That way, programs that treat it is a continuation line aren't retroactively
declared broken.

This may be your intent; in which case it's alright just to clarify that you
mean this.

> > Radical suggestion: remove ".", "[", and "]" from specials.  Move the
> > specification of a domain-literal to some other specification.
>
> Permits such thing as ".foo..bar.@host.do.main", which is known to
> break large numbers of parsers.  My syntax above is an attempt at a
> compromise.  I'm sure this topic will be revisited Friday.

Is this really so?  I know that a strict RFC-822 parser would be broken by
this, but is it really viable to have such a strict parser considering all the
violations of the rule with phrase?

My parser took this action a long time ago, although I turn around and
generate phrases properly.  It's seems to have been a positive measure.

Yes, I happen to believe that ".foo..bar.@host.do.main" should be valid, not
to mention "blurdybloop@host.do.main." (there's a UA reason for the latter; it
doesn't need to go out on the wire).