ietf-nntp Commetns on draft-15.pdf

[greg andruk]

On Fri, Dec 28, 2001 at 06:00:27PM +0000, Charles Lindsey wrote:
> P33. S9.3.1.1 (POST responses)
> If an article is POSTed, and the server can discover, in real time, that
> it is syntactically invalid, or breached site policy, or whatever, does it
> return 441, or do we need to invent a 541 response (there would surely be
> no point in trying to send it again)?

441 is all there is at present.  I would be reluctant to change the
behavior of such an old command, except in the form of an extension that
also required either a parameter to the POST command or some sort of MODE
command to enable the extended responses.


> P41. S9.4.3 (LIST DISTRIBUTIONS)
> I am totally confused at to what the LIST DISTRIBUTIONS command is
> supposed to do, but then I do not have access to any server that provides
> it. What does it actually return in typical cases? Or do current servers
> actually provide any useful response at all?

This is a file used by the B News postnews program, as well as *rn's Pnews. 
postnews actually parses it.  Its format is similar to that of the
newsgroups file.

I see no evidence in the wild of Pnews or postnews modified to fetch remote
copies of the distributions file, and no evidence of programs that
synchronize the local distributions file with a remote NNTP server.

The command is perhaps best not included in the standard.  The historical
mention in RFC2980 should be sufficient.

Some other LIST commands are server-specific and aren't asking for
standardization.  LIST MODERATORS (hmm, it's missing from 2980) and LIST
DISTRIB.PATS are only really there to support the inews component of older
versions of INN.  The first feature (mailing to moderators directly instead
of delegating the job to POST) is questionable, and the second (preparing an
article for spooling to rnews) doesn't really make sense unless inews
resides with the server -- and that feature was dropped due to security
concerns anyway.

LIST MODERATORS also returns an entirely different format on, say, INN and C
News systems, and the proposed UTF group names would likely obsolete this
file, so...


> P47. S9.5.2.1 (LIST OVERVIEW.FMT)
> 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?

This command is doubly useless, and best left behind in RFC2980.  Ideally,
it mere duplicates information already provided by [X]OVER, and in real life
it can fail to provide correct information.  In its native implementation,
overview.fmt only describes how new records are being added to the overview
database.  A good client will still need to parse each record to guard
against the possibility of prior format changes.

> [...]  Also, what is the point of the "full" parameter (as in
> 	"Xref: full"
> I presume)?

It is of no real use to a client.  The NOV format is indeed fixed.  The
first seven fields always need to appear in the same order without keywords,
and additional fields always need to include the header keyword.  The "full"
is there for internal use by INN.


> 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).

There are arguments both for and against it.  Given the way overviews are
typically stored, OVER <msgid> implies that the actual article would need to
be fetched and parsed by the server, so it loses the efficiency advantage
over HEAD <msgid>.  One useful bit of information only available through
OVER is the byte field, and that might make OVER <msgid> worthwhile.