Project whiteboard

The obvious issue:

• The project on sourceforge seems dead; the mailing list seems dead
• The latest “test” release was from 10 years ago

Random issues gleaned from a quick grep at the source code:

• charset isn’t look at, at all
• doesn’t mention unicode or utf so it probably has no knowledge of these

Random usability issues from using it:

• help screens are hard to navigate and you can’t save or pipe the help screens

The alternatives:

Option	trn	tin	nn
Build experience	antiquated and hard to understand¹	ok²	broken³ (has to be fixed by hand)
First impression of UX	ok, bearable	extremely annoying and hard to use⁴	ok, bearable
MIME support	broken if not using NNTP⁵	works but very annoying/unhelpful⁴	non-existent
Unicode support	broken⁶	not sure because UX is too bad	completely broken⁷
Help system	inaccurate info, bad UI
Config files	badly documented

1. Perl-style interactive Configure
2. GNU configure
3. CPP-based makefile template – it has a Linux option that errors out immediately because the CPP templating was done wrong
4. Randomly launches unwanted programs like the web browser even if you say no
5. All multipart articles display as blank if reading from local news spool
6. Classic mojibake; often a few characters display correctly but the rest is garbage
7. Worse than mojibake, it treats everything outside the ASCII printable range as control codes so everything except ASCII looks like garbage

It looks like Debian is sort of maintaining it so it’s not completely dead. Ubuntu’s copy of the Debian tarball shows they have incorporated 9 patches, one of which deals with the header MIME decoder (conflicts with mine) but none of which deals with UTF-8

Pnews mime’ification strategy (?):

• pass 1: scan article to see if any non-ascii characters are present (This can be done because we know Pnews works from a file)
  • look at the headers to see if Content-Type is present, remember this and what’s the charset
• pass 2:
  • (a) if everything is ascii and every line is 79 characters or shorter just cat the whole thing
  • (b): if some non-ascii is present assume it's UTF-8 (until we can figure out how to do proper charset conversions)
    • read one header at a time (catting all continuation lines)
      • discard Mime-Version and Content-Transfer-Encoding
      • QP/B64-encode anything that’s not ascii
      • break lines at 79 character boundary.
    • insert Mime-Version: 1.0
    • insert Content-Transfer-Encoding: 8bit if all lines are 79 characters, Content-Transfer-Encoding: quoted-printable otherwise (?)
    • insert Content-Type if not already present
    • cat the separator line
    • read body one line at a time
      • QP-encode everything and break lines if we previously determined some line(s) are too long

problem: i just learnt about the -j option. Pnews wouldn’t know if -j has been used.

Notes:

• according to RFC 5536
  • a valid header, excluding the final newline, cannot be longer than 998 octets
  • RFC 2047 states that individual lines in any QP/B64-quoted header cannot be longer than 76 octets
  • all USENET posts must comply with RFC 2049 so the Mime-Version header is now mandatory
  • all USENET posts must comply with RFC 2231 which apparently means continuation lines are more complicated than commonly thought (but this is probably not important since I don’t think anyone is doing weird *0 *1 stuff)