Re: My open issues with RFC3028bis

Ned Freed <ned.freed@mrochek.com> Tue, 05 July 2005 15:01 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65F1fKq079464; Tue, 5 Jul 2005 08:01:41 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j65F1fRW079463; Tue, 5 Jul 2005 08:01:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j65F1dW4079453 for <ietf-mta-filters@imc.org>; Tue, 5 Jul 2005 08:01:40 -0700 (PDT) (envelope-from ned.freed@mrochek.com)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LQ54UN318W00004T@mauve.mrochek.com> for ietf-mta-filters@imc.org; Tue, 05 Jul 2005 08:01:36 -0700 (PDT)
Cc: Philip Guenther <guenther+mtafilters@sendmail.com>, ietf-mta-filters@imc.org
To: Kjetil Torgrim Homme <kjetilho@ifi.uio.no>
Message-id: <01LQ9C2178Q200004T@mauve.mrochek.com>
Date: Tue, 05 Jul 2005 07:48:15 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: My open issues with RFC3028bis
In-reply-to: "Your message dated Tue, 05 Jul 2005 15:11:30 +0200" <1120569090.4185.56.camel@chico.njus.no>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <E1Do7RW-0002QU-TU@nostromo.freenet-ag.de> <01LQ31LDKJ0200004T@mauve.mrochek.com> <20050701091231.GC10060@nostromo.freenet-ag.de> <01LQ44NF85CE00004T@mauve.mrochek.com> <200507020058.j620w4SP031225@lab.smi.sendmail.com> <1120569090.4185.56.camel@chico.njus.no>
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>


> On Fri, 2005-07-01 at 17:58 -0700, Philip Guenther wrote:
> > Works for me.  2.4.2.2 now reads: [...]
> >
> >    Folding of long header lines (as described in [IMAIL] 2.2.3) is
> >    removed prior to interpretation of the data.  The folding syntax (the
> >    CRLF that ends a line plus any leading whitespace at the beginning of
> >    the next line that indicates folding) are interpreted as if they were
> >    a single space.
> >
> > <pause>
> >
> > Hmmm, that last paragraph actually differs from RFC 2822, section 2.2.3,
> > which says:
> >    Unfolding is accomplished by simply removing any CRLF
> >    that is immediately followed by WSP.
> >
> > I.e., the leading whitespace should *not* be treated as a single space
> > but rather be left as is.  Unless I hear screams, I'm going to remove
> > the sentence that starts "The folding syntax..." as conflicting.

> that's fine, but I find it a bit misleading to only refer to [IMAIL],
> since RFC 2047 changes the folding rule in the presence of two
> encoded-words:  any folding whitespace between them must be removed (see
> section 6.2 paragraph 3).

Er, no. RFC 2047 makes no changes to how header fields are folded or
unfolded. Indeed, the word "fold" appears nowhere in RFC 2047.

What RFC 2047 does is state that white space between encoded words should
be ignored when displaying. That's a VERY different thing from changing
the unfolding rule to call for space to be removed entirely under some 
circumstances.

> e.g.,
>    Subject: =?utf-8?q?hell?=
>        =?utf-8?q?o?=
> should be presented as:
>    Subject: hello

And

  Subject: =?utf-8?q?hell?=     =?utf-8?q?o?=

should be displayed in the same way; there is no interaction between the
unfolding operation and the decoding of encoded words.

> on the other hand,
>    Subject: =?utf-8?q?hell?=
>        o
> should be folded into
>    Subject: hell    o

> my suggestion is to add the reference, perhaps like so

>         Long header lines are unfolded (as described in [IMAIL] 2.2.3
>         and [MIME] part 3 6.2) prior to interpretation of the data.

IMO it would be better to say something along the lines of

    Header lines are unfolded as described in [IMAIL] section 2.2.3.
    Interpretation of header data should be done according to [MIME3]
    section 6.2.

This makes the required sequence of operations clear. Note that I also removed
the term "long" - in practice it isn't only long lines that are folded.

				Ned