Message-ID: <YlDmTdO00WBw4vWk5I@andrew.cmu.edu>
Date: Thu,  7 Mar 1996 13:16:09 -0500 (EST)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: drums@cs.utk.edu
Subject: Re: Message format document outline
In-Reply-To: <MailManager.826153011.7721.mrc@Ikkoku-Kan.Panda.COM>
References: <MailManager.826153011.7721.mrc@Ikkoku-Kan.Panda.COM>

Mark Crispin <MRC@Panda.COM> writes:
> 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: and Message-ID: are equivalent because of the
free-insertion-of-whitespace rules.  (Modulo the fact that the rules
are stated as applying *between* tokens and this needs to be fixed to
properly specify behavior at the beginning and end.

The current 822 definition, strictly interpreted, specifies that the
two Subject heders above contain different values.  The first one has
a value that starts with 5 spaces, the second has a value that starts
with one.  This definition does not match reality.  The definition in
my outline makes the two values start with 4 and zero spaces
respectively.  If it is not considered important to have unstructured
field body values starting with whitespace, we could go with Mark's
suggestion.

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

These are all illegal per RFC 822 and should continue to be illegal.

> 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'm adding no such requirement.  I am adding a prohibition making
all-whitespace header continuation lines invalid.  Since they will be
invalid, a parser encountering such a line will have the freedom to
interpret it however it chooses.

> 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?

There are reports of widely deployed parsers which choke on such stuff
inside a local-part.  Inside a phrase, it's a different story.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up