format=flowed not respected

format=flowed not respected

[Steinar Bang]

Messages received sent by Opera M2, has had format=flowed set in the
headers, but the lines haven't been broken when displayed by Gnus.

Here's an example of such an article:
	nntp://news.gmane.org/gmane.test/1013

Is there something I have to set to make format=flowed be used by
Gnus? 

Re: format=flowed not respected

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

> Messages received sent by Opera M2, has had format=flowed set in the
> headers, but the lines haven't been broken when displayed by Gnus.
>
> Here's an example of such an article:
> 	nntp://news.gmane.org/gmane.test/1013
>
> Is there something I have to set to make format=flowed be used by
> Gnus? 

Um, the lines should be "broken" by the sending client.  The receiving
client should "flow" together "broken" lines if they end with SPC, but
isn't required to do anything else.

So Opera is breaking a SHOULD in RFC 2646 when it does not break the
lines before the 80th column.  Gnus is behaving correctly in this
example, as far as I can tell.

4.1.  Generating Format=Flowed

   When generating Format=Flowed text, lines SHOULD be shorter than 80
   characters.  As suggested values, any paragraph longer than 79
   characters in total length could be wrapped using lines of 72 or
   fewer characters.  While the specific line length used is a matter of
   aesthetics and preference, longer lines are more likely to require
   rewrapping and to encounter difficulties with older mailers.  It has
   been suggested that 66 character lines are the most readable.

   (The reason for the restriction to 79 or fewer characters between
   CRLFs on the wire is to ensure that all lines, even when displayed by
   a non-flowed-aware program, will fit in a standard 80-column screen
   without having to be wrapped.  The limit is 79, not 80, because while
   80 fit on a line, the last column is often reserved for a line-wrap
   indicator.)

   When creating flowed text, the generating agent wraps, that is,
   inserts 'soft' line breaks as needed.  Soft line breaks are added
   between words.  Because a soft line break is a SP CRLF sequence, the
   generating agent creates one by inserting a CRLF after the occurance
   of a space.

   A generating agent SHOULD NOT insert white space into a word (a
   sequence of printable characters not containing spaces).  If faced
   with a word which exceeds 79 characters (but less than 998
   characters, the [SMTP] limit on line length), the agent SHOULD send
   the word as is and exceed the 79-character limit on line length.

   A generating agent SHOULD:

      1.  Ensure all lines (fixed and flowed) are 79 characters or
          fewer in length, counting the trailing space but not
          counting the CRLF, unless a word by itself exceeds 79
          characters.
      2.  Trim spaces before user-inserted hard line breaks.
      3.  Space-stuff lines which start with a space, "From ", or
          ">".
...

Re: format=flowed not respected

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> So Opera is breaking a SHOULD in RFC 2646 when it does not break the
> lines before the 80th column.  Gnus is behaving correctly in this
> example, as far as I can tell.

But the broken SHOULD isn't the culprit, right?  If the lines in
questions had had a trailing space, Gnus would have broken them?

Re: format=flowed not respected

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> So Opera is breaking a SHOULD in RFC 2646 when it does not break the
>> lines before the 80th column.  Gnus is behaving correctly in this
>> example, as far as I can tell.
>
> But the broken SHOULD isn't the culprit, right?  If the lines in
> questions had had a trailing space, Gnus would have broken them?

No, the receiving MUA only flow lines together, it doesn't break
lines.

E.g. if you receive

foo barSPC
baz fooSPC
bar

Gnus would flow that together into

foo bar baz foo bar

I don't recall the specification saying anything about breaking (even
overlong) lines, at the receiving end.

Re: format=flowed not respected

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> I don't recall the specification saying anything about breaking
> (even overlong) lines, at the receiving end.

Would it do any harm to do it?  In effect apply
gnus-article-fill-cited-article after doing whatever the the flowed
fill code does?

Re: format=flowed not respected

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> I don't recall the specification saying anything about breaking 
>> (even overlong) lines, at the receiving end.
>
> Would it do any harm to do it?  In effect apply 
> gnus-article-fill-cited-article after doing whatever the the flowed 
> fill code does?

I think that would do more damage than it would fix.  Even such a
simple thing as including a overlong protocol dump line would be
destroyed by unconditional g-a-f-c-a.  Consider this message and the
following line:

1047 UID FETCH 21421:21423 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])

The goal of format=flowed is to make soft/hard newlines work in mail, 
applying g-a-f-c-a or something like it would destroy that goal.

It is better to fix buggy MUAs like Opera...

Re: format=flowed not respected

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> It is better to fix buggy MUAs like Opera...

Yes.  However, even if it's fixed in Opera M2, there will probably be
many broken MUAs out there for a long time to come.  People don't
upgrade unless there's a reason for it.

Oh well.  It's back to typing 'W w' I guess...

The reasons you point out, are why I haven't added it to
gnus-part-display-hook. 

Re: format=flowed not respected

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> It is better to fix buggy MUAs like Opera...
>
> Yes.  However, even if it's fixed in Opera M2, there will 
> probably be many broken MUAs out there for a long time to come. 
> People don't upgrade unless there's a reason for it.

Start complaining to them, then they will have a reason. ;-)