RFCs now use unicode rather than ASCII. I've been printing RFCs to read them for decades, when I did it last week the result didn't look pretty.
I found a new tool, u2ps, that almost does what a2ps and enscript do not. I had to make one small change, to make it interpret the form feeds in RFCs, then it worked exactly as I needed.
The script I use wraps u2ps to print RFCs double-sided, two RFC pages per A4 page (four per sheet). At heart it's like this short unix command:
u2ps -k -M A4 -s 11.5 --header-right=''
| psnup -2 2>/dev/null
| lpr -o sides=two-sided-long-edge
Be conservative in what you send and liberal in what you accept
does not mean what you probably think it does.
Jon Postel was talking about how to interpret RFCs. He was, after all, the RFC editor. When an RFC says that a particular protocol uses text lines with a maximum length of 512 bytes and CRLF as line terminators, you might be forgiven for wondering whether that's 510+2 or 512+2 bytes. In most cases there is some sentence that makes it clear, but that sentence can be easy to overlook.
If you overlook it, or you see it but think other implementers may overlook it, then Postel's Principle applies. In the example above being liberal
means accepting 512 bytes plus CRLF, and being conservative
means sending 512 including CRLF.
Postel's principle does not mean that you should accept 1024-byte lines or any other thing which the RFC forbids. Jon Postel was the RFC editor, he didn't want you to ignore the RFC's stated line length. His principle is about how to handle the boundary case whenever the boundary is underspecified or misunderstandable.
The worst of the nine RFCs I have written is doubtlessly 5465, IMAP NOTIFY, which should have been good but is a disaster. Its main characteristics are that it's complex (both in terms of number of rules in the RFC and the number of features needed in a server), that it's much more complex than the first of its input documents, and that noone implements it.
My best may be 4978, IMAP COMPRESS=DEFLATE, which is much shorter than 5465, roughly as complex as its first draft version was, contains an informative section with implementation advice, and is widely implemented. […More…]
Although it was published on April 1, I have been told (by someone who was there) that it was intended to be taken seriously. I quoted it for the first time on April 5 (working on metis), and like to quote it still; this post is a bit of faux history with link targets for each truth […More…]