Hi Arnt, On Thu, Nov 05, 2020 at 06:39:35PM +0100, Arnt Gulbrandsen wrote: > On Thursday 5 November 2020 18:02:15 CET, Gero Treuner wrote: > > Then the logic and also my case is compliant to the standard, although > > it is not ideal to cut within plain text words when there is enough > > remaining space on the line, forcing the second part of the word to be > > encoded regardless of the content, to prevent the space after the first > > encoded block to be displayed. > > You could argue this either way... if some words are displayed incorrectly > because the receiver does not ignore linear-space as it should, do you want > that to happen commonly (so it's noticed and fixed) or seldom (so it's less > painful)? My own opinion, which is worth only what you paid to hear it, is > that whatever requires the smallest number of test cases is better. That has > a better chance of being noticed during routine testing.
Actually the behaviour on this specific receiver's side is worse: Display as (with a placeholder for invalid character instead of "ß"). So it really looks broken, but not caused on the sender's end. Sample: Gro�e wordxxxx word wordxx But as it happens at the boundary of Mutt's encoded words, I wanted to enlight whether splitting into words is (technically) correct, also watching at treatment of spaces. Reducing test cases would probably mean that words are not broken by the encoding without reason such as no more space on the line ... I plan to check this, but not with "bug" priority. (Reported the bug to Apple right now ;-) > I agree with Kevin's analysis BTW: The mention of CRLF SPACE is due to 822's > line length restruction, not due to anything in 2047. You can also see this > clearly in the ABNF grammars in 2047 and 5322 (the current successor to > 822). I knew that restriction, but missed the other piece clarifying whether it is the only option to continue encoded parts. Gero
