ietf-nntp Re: OVER extension

[Russ Allbery]

I agree with this proposed OVER text and would like to see it adopted,
with the caveats noted below:

Clive D W Feather <clive at demon.net> writes:

> (1) Allow (but don't require) a server to treat lone LF as CRLF.

Ugh, no.  Pick one or the other, but whatever we do, we cannot offer the
server a choice.  The goal is to get to the point where, for a given
article, every conforming server will produce exactly the same overview
information.

I see no reason for special treatment of a lone LF, so I prefer the text
without this change.  I'm not strongly opposed to mandating special
treatment of lone LF, although I don't see much point.  I am strongly
opposed to offering the implementor a choice.

> (2) In LIST OVERVIEW.FMT, choose between "Bytes:", "Bytes", or either
>     with the latter preferred [and ditto "Lines".]

Andrew argued that LIST OVERVIEW.FMT should be able to return exactly the
same as it currently does.  I don't consider the command useful enough to
warrant fiddling with it when there's a possibility that it could confuse
existing clients (and leaving off a syntactic element is the sort of
change that I could see doing that, for a poorly written client).

> There was a suggestion that OVER could take a message-ID. This would
> need to be optional; to allow it, include the lines prefixed with $,
> while to forbid it exclude those lines.

I don't think this has a lot of utility, but it does make things more
consistent with the other commands, so I don't object to it.

>   The byte count and line count MUST be decimal integers. They MUST
>   count the entire article, both header and body.

No, the line count only counts the body.  This is not something we should
change; too much reader software relies on this for things like killfiles.

I think the byte count includes the headers, although this portion of the
INN code is really difficult to read and I'm not positive that I've read
it correctly.  However, the byte count (as implemented in INN at least)
counts CRLF as a single byte.  *sigh*

>   The line count is the number of US-ASCII CRLF pairs, each of which
>   counts as two bytes.

Note that this, while a perfectly reasonable decision, invalidates all of
the existing overview databases of all INN servers even if the server is
upgraded to support the new standard for new articles.  I'm not sure what
to think about that.

What do other servers currently do?

>   These values MUST be returned; the corresponding fields MUST NOT be
>   empty.

Had we already discussed and/or voted on making lines mandatory?  I can't
remember now.  :/

> [Query: is the following paragraph needed, since this is a generic code.]
> ? If the information is not available, the server MUST return the 503
> ? response.

I don't think it's necessary.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>