ietf-nntp 8-bit NNTP suggestions

[Howard Swinehart]

There hasn't been much discussion about 8-bit NNTP and the problems with
long lines and embedded <CR><LF>s, so here's a few suggestions.

Suggestion #1 - Length/<CR><LF> kludge

Return the number of octets in the response line and append a <CR><LF> to
the data if necessary.  End with .<CR><LF>

C: BODY 123
S: 222 123 <abc123 at host.com> 1000 article retrieved - body follows
S: ...1,000 octets ...
S: <CR><LF>.<CR><LF>

Sending binary data whose last two bytes happen to be <CR><LF>:

C: BODY 123
S: 222 123 <abc123 at host.com> 1000 article retrieved - body follows
S: ...first 998 octets, <CR><LF> ...
S: .<CR><LF>

Problems: This doesn't deal with long lines.  Some readers might replace
embedded <CR><LF>s with <LF>s.

Suggestion #2 - Binary Mode

Add a binary mode that sends each line as a binary packet. Each packet would
be a length followed by the raw data.

C: MODE BINARY
S: 2xx Ok.  Send binary packets instead of lines
C: [10]BODY 123<CR><LF>
S: [66]222 123 <abc123 at host.com> 1000 article retrieved - body
follows<CR><LF>
S: [1000]...1,000 octets...


Suggestion #3 - Escaping

Keep the current line based protocol by escaping all <CR>s and <LF>s in
binary messages and breaking the escaped text into reasonably short lines
terminated with <CR><LF>

140 octets of binary data, "Hello, world!"<CR><LF> would be sent like:

S: about 70 octets of escaped binary data.<CR><LF>
S:.70 more octets of escaped binary data<CR><LF>
S: Hello, world!\r\n<CR><LF>
S: .<CR><LF>

The client then discards the <CR><LF> at the end of each line and restores
the escaped characters.  Current readers won't interpret the data correctly,
but they probably won't crash either.