AFAIK, I have never used KOI8-R; I can't speak to what m$ outhouse may have done behind my back. Maybe it copied the charset from the message I was responding to?
Do you have human beings doing had encoding of messages? If not, then I'm obviously talking about software. Alas, while I know of validators for HTML and CSS, I don't know of any for e-mail. Cut-and-paste is beyond the scope of any RFC. However, the considerations are pretty clear; if the text has a New Line (LF for Eunix, CRLF for windows) then use a hard NL; if you split due to length, use a soft NL. Follow that and the rules for space stuffing and you get the code intact at the other end. Break them and all bets are off. If the receiver does not support F=F then he will get extraneous line breaks; I can't imagine what idiocy would cause extraneous line wrapping. BTW, the webmail application for this e-mail account uses m$ lookout, and I would not be surprised by any RFC violation that turns up. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Monday, July 2, 2018 2:16 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Formatting (was: JCL ERROR : IGD01022I) (Yaay! You're no longer using koi8-r!) On Mon, 2 Jul 2018 17:06:08 +0000, Seymour J Metz wrote: >Implementing any new RFC is a big order. If the mail clients on both ends >implement RFC 3676, then cut-and-paste works. If a brain dead application >simply slaps in format=flowed without following the specifications in the RFC, >then blame that application. Again, do you know of any problem when both ends >actually adhere to the specifications? > o By "the mail clients on both ends" do you mean only the software, or do you mean to include the human beings? It is not practical to expect human beings to conform all requirements of RFC 3676. o Is there an available validator and data suite for format-flowed for both sending and receiving ends? Human eyeball validation is impractical and error-prone. (And quis custodiet ipsos custodes?) o If such a validator were to exist, to whom would one report deviations? What's the realistic likelihood of resolutions other than "WAD"? o Does RFC 3676 guarantee round-trip integrity? Ed should be able to copy-and-past his Rexx snippet and Don to extract it, byte-for-byte identical to the original. Otherwise, the specification is a broken design. Format=flowed had two (more?) design objectives: o Support for comfortable viewing on hand-held fondleslabs. o Support for word processors which reserve CRLF for paragraph separation. These are pretty irrelevant to computer languages. Esmie's JCL was illegible to Lizette; Ed's Rexx was illegible to Don. If format=flowed imposes no requirement on the sending human being, it SHOULD be possible to move all the flow-function from the sending MUA to the receiving MUA and the receiving human being should be given a {FLOWED|FIXED} button for viewing and extracting code respectively. "Save as File" would suffice if that file could be guaranteed identical to what the originator attached. Many user agents do not allow disabling of "format=flowed". -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
