Re: Non destructive folding/unfolding (ie, no insertion of whitespace in unfolding)

Pete Resnick <[email protected]>
Newsgroups gmane.ietf.rfc822
Message-ID <p06250103c354a82e57bc@[10.107.71.42]>
On 11/1/07 at 12:35 PM +1100, Mikel Lindsaar wrote:

>One situation I have is where a X-header field and Reply-To field 
>has a single piece of text that is longer than the 78 octet limit, 
>but has no white space break.
>
>For example:
>
>Reply-To: 
><1234-1234-1234-1234-1234-1234-1234-1234-1234@me-some-host-over-here.org>
>
>The library currently folds this line as:
>
>Reply-To:CRLF
>LWSP<1234-1234-1234-1234...blah-with-no-further-fold

That's OK.

>Now, I have two questions.
>
>1) I believe that putting the CRLF immediately after the : in the 
>header field name is in violation of 2822 specifically that the 
>header line should contain the name, a colon, the field and 
>terminated by a CRLF.  Would this be a correct interpretation?

No. Following every colon after the header field is "[CFWS]". It's OK 
to fold there.

>2) Irregardless of (1), what is the correct handling of a piece of 
>text in the field that is longer than 78 characters, but contains no 
>whitespace to fold?  ie, in unfolding, no whitespace can be inserted 
>back into the original text which would be destructive to the 
>original text.

In the X-header field case, if you've got longer than 78 in the field 
body, just leave it. If it's longer than 998, then you're going to 
have to break it.

In the Reply-To field case, you've got other options. You can put in 
the fold before or after the "<", the ">",  the "@", and any "," 
between addresses if there's more than one. That's destructive of the 
original sent form, but it won't be a problem semantically for 
anything parsing. This isn't a general rule, though. It only applies 
to fields that specifically take addresses. There are other similar 
situations.

>I saw one mention of doing this:
>
>Reply-To: <1234-1234-1234-1234-1234-12\CRLF
>LWSP34-1234-1234-1234
>
>But I can not find this in the RFC 2822 and my library breaks on 
>this when it tries to unfold, so I am not sure if my library's 
>unfolding function is at fault or if my folding implementation is 
>incorrect.

That's broken. It won't unfold correctly.
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.