Message-Id: <v03101312af0ec02e349a@resnick1.isdn.uiuc.edu>
In-Reply-To: 
 <Pine.SOL.3.95.970124084752.16188B-100000@taurus.cus.cam.ac.uk>
References: <v03101301af0d8d0a06e8@resnick1.isdn.uiuc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 24 Jan 1997 13:46:53 -0600
To: Philip Hazel <ph10@cus.cam.ac.uk>
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: invisible continuation lines
Cc: Chris Newman <Chris.Newman@innosoft.com>,
        Detailed Revision/Update of Message Standards <drums@cs.utk.edu>

On 1/24/97 at 2:53 AM -0600, Philip Hazel wrote:

>(a) Looks like I'm getting stuck with this algorithm, though as Alan
>Barrett pointed out, it has actually been in use for many years.

Ah, you get a little fame....could be worse. :-)

>(b) I don't understand your remark about a two-pass parser. Exim (for
>example) reads header lines (including continuations a la RFC822) until
>it reaches either a line that is entirely empty, or a line that does not
>begin with a header name followed by colon. In the former case, the body
>starts at the next line; in the latter case the body starts at the
>non-header line. Just one pass...

I overstated what I meant. You're right, it's not two pass, but it does
require one line lookahead. That is, I've got to read the line, decide what
it is, and then act on it. I believe the current setup for Eudora is to be
in either "header" mode or "body" mode, and it has to know what mode it's
in *before* it reads the next line. It's not something that can't be
changed, but it's certainly scary old code to be mucking around in. The
reason I called this "two pass" is because in the current setup, Eudora
would have to "back up" one line and process it in the other mode, which is
something that it cannot presently do as far as I know.

Either way, I am certainly going to push to use the proposed alogirthm for
processing in filters and the like.

pr

--
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980