ietf-nntp Standardization of LIST OVERVIEW.FMT

[Matthias Andree]

Russ Allbery <rra at stanford.edu> writes:

> Yeah, but those aren't protocol issues.  Servers that can't handle those
> articles can certainly reject them.  What I'm wondering is if we can
> change the article definition for the purposes of NNTP to MUST NOT have a
> NUL and SHOULD NOT have lone CR or LF.

I'd rather do the opposite and make the protocol really 8-bit clean no
matter what, and require that NNTP implementations

- MUST handle embedded NUL characters properly and NOT cause early line
  termination

- MUST handle lone CR and lone LF

- MUST NOT remove or add CR characters before LF characters

- MUST NOT remove or add LF characters before CR characters

and posting agents

- SHOULD NOT (or OUGHT NOT TO) post articles with bare LF, CR or NUL
  before adjusted servers that handle these bare characters are in wide
  use.

That way, NNTP could finally pave the way that was intended for
RFC-2045's "binary" identity encoding. I don't know yet what Usefor is
up to or what contraints they will impose on bare LF, CR or NULs -- but
as NNTP's main issue is to transport, it should not change the data
transported.

IMO, traditional design defects in the C standard, the fgets() function
in particular, should not be excuses for a poor protocol design.

One thing to keep in mind is that implementations WILL HAVE to check
that the line ends at CR LF and *ONLY* at CR LF, not at LF or CR. Some
implementations will goof this up for sure, but these are IMHO broken
and have always been, as CR LF has always been the "wire format" for
lines.

This is basically a migration issue -- IMO, the NNTP software MUST be
prepared to handle this, but user agents SHOULD NOT create such articles
before the new NNTP semantics are widespread.

Thoughts?

-- 
Matthias Andree