ietf-nntp OVER extension

[Russ Allbery]

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

> It is also worded very badly, since the first paragraph mixes up the
> overview.fmt file with a description of how OVER works.

> I think that 9.5.2 would be better written if it had the OVER command
> first, describing the overview database and how the fields
> appear. *Then* have the LIST OVERVIEW.FMT command, which describes which
> optional fields OVER offers.

I agree with this.

>> 9.5.2.2 (OVER) defines 8 obligatory fields which MUST appear, in order,
>> in every overview line. 5 of these correspond to headers in the
>> article, 3 of them (article number, byte count, line count) do
>> not. Question: are these obligatory entries supposed to be included in
>> the LIST OVERVIEW.FMT output?

> My reading of the wording for OVER is that they are *not*;

This is a bug in the wording for OVER, then; LIST OVERVIEW.FMT has always
included the mandatory headers (except for the article number).

> Whereas the OVER example does *not* have 8 fields even though 8 are
> mandatory ! Is it permitted for OVER to return less than 8 items ?

I haven't looked at the draft, so I'm not sure what you're referring to,
but it's allowable for some of the fields to be empty (but the fields must
still be delimited by tabs).

>> Also, what is the point of the "full" parameter (as in
>> 	"Xref: full"
>> I presume)? I thought all of the non-obligatory entries were REQUIRED
>> to include the header-name (in which case that "full" is redundant, or
>> have I got it wrong?). Either way, it would be a good idea to include
>> one of the non-obligatory entries (Xref is the obvious choice) in the
>> Example, together with its "full" (if that remains).

The full parameter is used internally by INN.  You're correct that it's
meaningless to the client since all optional fields must include the
header name, but again it's always been this way.

> (1) Should LIST OVERVIEW.FMT include the 8 mandatory fields ?

It should include all the fields except the article number.

> (2) If so, what are the names for the last two of the 8 ?

Bytes and Lines.

> (3) Can the mandatory fields have the header name prepended ?

No.  (I know of no server that does this, which means that it's almost
certain that clients won't be ready to deal with it.)

> (4) Can any optional fields have the header name prepended ?
> (5) Must any optional fields have the header name prepended ?

Yes, they must have the header name prepended.  (Which makes LIST
OVERVIEW.FMT really irrelevant, since by retrieving one overview record
one can tell what all is in the overview.  There's really no reason for
the command except for backward compatibility with clients that try to use
it for some reason.)

> (6) In LIST OVERVIEW.FMT, should "full" have a space before it ?

No.

>> P48. S9.5.2.2
>> I am slightly surprised that the OVER command does not have a
>> <message-id> alternative (since all the other commands with a [range]
>> parameter seem to have one).

> The overview databases (as I understand it) are per-newsgroup. There is
> no easy way (without fetching the article) to map an ID to a newsgroup,
> so this version is not provided.

Correct.

> I would not object to it being optional.

How many current servers support this?  I know that INN doesn't; it's
easy enough to fake up by retrieving the article and building the overview
information on the fly, but it seems a bit pointless since I don't know
why a client would do that rather than just sending a HEAD command.  The
whole point of OVER is that it gives you the essential information that
you need to thread and do similar things for a whole bunch of articles at
once much faster than using HEAD, but none of those reasons apply to
getting information for a single message ID.

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