headers
Simon Josefsson | 4 Dec 16:57
Favicon

Re: Format=Flowed/RFC 2646 Bis (-04)


Has anyone collected test vectors for format=flowed?  Considering the
amount of buggy implementations, I believe it would be useful to have
these available.  I'm writing a test harness for my implementation, so
I'd appreciate any pointers to existing test vectors I could adopt.

To give one (to me) problematic example, how to render this:

> foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo 
> foo 
> 
> 
> 
> foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
> bar 

Thanks,
Simon
Permalink | Reply | 4 comments |
headers
Charles Lindsey | 5 Dec 12:47
Picon
Picon

Re: ***SPAM-3*** Re: Format=Flowed/RFC 2646 Bis (-04)


In <ilur7zkfuek.fsf <at> latte.josefsson.org> Simon Josefsson <simon+ietf-822 <at> josefsson.org> writes:

>Has anyone collected test vectors for format=flowed?  Considering the
>amount of buggy implementations, I believe it would be useful to have
>these available.  I'm writing a test harness for my implementation, so
>I'd appreciate any pointers to existing test vectors I could adopt.

>To give one (to me) problematic example, how to render this:

>> foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo 
>> foo 
>> 
>> 
>> 
>> foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
>> bar 

Opera rendered it (no extra '>'s added) as

--------------------------

>foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo 
>   foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
>bar 

Thanks,
Simon

--------------------------
(Continue reading)

Permalink | Reply | 3 comments |
headers
Adam M. Costello | 6 Dec 06:57

Re: Format=Flowed/RFC 2646 Bis (-04)


Charles Lindsey <chl <at> clerew.man.ac.uk> wrote:

> Opera rendered it...

The lines consisting of just a greater-than sign and a space are fixed,
right?  (Because the space is a stuffing space.)  So there should be two
separate quoted "foo foo foo..." paragraphs separated by quoted blank
lines, right?

AMC
Permalink | Reply | 2 comments |
headers
Arnt Gulbrandsen | 7 Dec 17:42
Picon
Favicon
Gravatar

Getting RFC 2047 encoding right


Hi,

I have a tiny little problem that you chaps may be able to help me with.

Suppose that a mail client receives a message whose subject is encoded 
according to RFC 2047. Suppose further that the message is decoded and 
stored in a database somewhere - in RAM, on disk, on a server 
somewhere. Some time later, the same or a different program sends a 
reply.

Now, to be kind and courteous that program should use the same subject 
field, perhaps prefaced by "Re: " (or "Auto: "), such that if the 
recipient threads based on subject, everything work, no matter whether 
the recipient supports RFC 2047 or not.

That implies using the same character set, q/b encoding etc. as the original.

To be kind and courteous, the program should use a widely supported 
character set when 2047-encoding (whether it's composing original 
messages or replies), and use as few 2047-encoded words as possible.

To be kind and courteous, the program should observe all other rules set 
out in RFC 2047 and 2822 (including ones which were broken by an 
earlier message).

To be reliable and bug-free, the algorithm that does all this should be 
simple and straightforward.

There's a conflict here. How do you all address this?
(Continue reading)

Permalink | Reply | 27 comments |
headers
Simon Josefsson | 8 Dec 02:35
Favicon

Re: Format=Flowed/RFC 2646 Bis (-04)


"Adam M. Costello" <ietf-822.amc+0 <at> nicemice.net.RemoveThisWord> writes:

> Charles Lindsey <chl <at> clerew.man.ac.uk> wrote:
>
>> Opera rendered it...
>
> The lines consisting of just a greater-than sign and a space are fixed,
> right?  (Because the space is a stuffing space.)  So there should be two
> separate quoted "foo foo foo..." paragraphs separated by quoted blank
> lines, right?

I dunno.  -04 also says:

    If the line ends in a space, the line is flowed.  Otherwise it is
    fixed.  The exception to this rule is a signature separator line,
    described in Section 5.3.  Such lines end in a space but are neither
    flowed nor fixed.

This suggest the line is flowed.

Also of relevance may be that the document considers

> foo

and

>foo

to be logically the same during encoding.  I'm not sure if the lines
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam M. Costello | 8 Dec 08:42

Re: Format=Flowed/RFC 2646 Bis (-04)


Simon Josefsson <simon+ietf-822 <at> josefsson.org> wrote:

> > The lines consisting of just a greater-than sign and a space are fixed,
> > right?  (Because the space is a stuffing space.)
> 
> I dunno.  -04 also says:
> 
>     If the line ends in a space, the line is flowed.  Otherwise it is
>     fixed.
> 
> This suggest the line is flowed.

The sentences immediately preceeding that one are:

    If the first character of a line is a space, the line has been
    space-stuffed (see section 5.4).  Logically, this leading space is
    deleted before examining the line further (that is, before checking
    for flowed).

AMC
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 8 Dec 11:16
Picon
Picon

Re: Getting RFC 2047 encoding right


In <HuU1P1DxTyF2kH+Insj8JA.md5 <at> prosecco.oryx.com> Arnt Gulbrandsen <arnt <at> gulbrandsen.priv.no> writes:

>Now, to be kind and courteous that program should use the same subject 
>field, perhaps prefaced by "Re: " (or "Auto: "), such that if the 
>recipient threads based on subject, everything work, no matter whether 
>the recipient supports RFC 2047 or not.

By and large, user agents should (or SHOULD) decode the RFC2047 stuff
before doing anything "clever" with the header. Note that all the encoded
stuff is really for human consumption, so it should not matter (but of
course it does). The only thing that is even mentioned in any
standards-like document regarding interpreting the Subject-header is
"Re: " (it has a mention in RFC 2822, for example, and is likely to have
a slightly firmer mention in USEFOR).

However, one of the tasks the USEFOR WG is undertaking is a companion "Best
Current Practice" document, and in the initial draft for that I have
written that if you add a "Re: " to a Subject-header, then it SHOULD be in
the clear _before_ the start of any RFC 2047-encoded stuff. That seems
like a good practice to me, since it means that agents that want to strip
it off (before producing sorted lists of headers, for example) can at least
do that correctly.

>That implies using the same character set, q/b encoding etc. as the original.

Best practice is propably to store the original, and decode it on the fly
whenever it is needed for humans.

--

--
(Continue reading)

Permalink | Reply | 7 comments |
headers
Keith Moore | 8 Dec 16:41
Picon

Re: Getting RFC 2047 encoding right


The correct way to reply to a message that has an RFC 2047-encoded subject
is to use the same RFC 2047-encoded subject that appeared in the message
being replied-to.  That's very easy to do - just prepend "Re: " to that
subject line, and rewrap the header (leaving encoded-words intact) if 
necessary to accomodate RFC 2047 line-length restrictions.

> Suppose that a mail client receives a message whose subject is encoded 
> according to RFC 2047. Suppose further that the message is decoded and 
> stored in a database somewhere - in RAM, on disk, on a server 
> somewhere.

RFC 2047 encoded words were not intended to be used in this way.  Decoding
is only supposed to happen prior to display or printing, not prior to
storage.

Keith
Permalink | Reply | 15 comments |
headers
Keith Moore | 8 Dec 16:43
Picon

Re: Getting RFC 2047 encoding right


> >Now, to be kind and courteous that program should use the same subject 
> >field, perhaps prefaced by "Re: " (or "Auto: "), such that if the 
> >recipient threads based on subject, everything work, no matter whether 
> >the recipient supports RFC 2047 or not.
> 
> By and large, user agents should (or SHOULD) decode the RFC2047 stuff
> before doing anything "clever" with the header.

Nope, user agents SHOULD NOT decode RFC 2047 except for display purposes.

> However, one of the tasks the USEFOR WG is undertaking is a companion "Best
> Current Practice" document, and in the initial draft for that I have
> written that if you add a "Re: " to a Subject-header, then it SHOULD be in
> the clear _before_ the start of any RFC 2047-encoded stuff. 

Yes, but this happens naturally if you just prepend "Re: " to whatever
subject happens to be in the message being replied to (encoded or not).

> Best practice is propably to store the original, and decode it on the fly
> whenever it is needed for humans.

right.

Keith
Permalink | Reply | 6 comments |
headers
Pete Resnick | 8 Dec 18:25
Favicon

Re: Getting RFC 2047 encoding right


On 12/8/03 at 10:43 AM -0500, Keith Moore wrote:

>Nope, user agents SHOULD NOT decode RFC 2047 except for display purposes.

Do you consider sorting a "display purpose"? How about searching 
given some user input?

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 5 comments |

Gmane