Comments on draft-ietf-nntpext-base-04.txt
tom at infosys.tuwien.ac.at
Wed May 13 05:34:35 PDT 1998
First of all, thanks for your internet drafts describing NNTP and the
extensions applied to RFC977. It helped me a lot when I started writing
my cache server for news (NewsCache).
While I was working on NewsCache, I found that some points are
SECTION 4. Basic Operation.
This section defines a limit on length of the command line and the
minimum/maximum size of a command. Is there also a limit on the length
of a newsgroup name?
Is one of these two assumptions correct?
> A NNTP server MAY have an inactivity autologout timer.
> When the timer expires, the server should close the TCP connection
> without sending any response to the client.
and later in section 8.1.3 Error responses from extended servers:
> If the server NNTP determines that the NNTP service is no longer
> available (e.g., due to imminent system shutdown), it must return
> code 400.
I think that the later paragraph can lead to misunderstandings. For
instance some versions of INN assume that 400 has also to be sent on a
timeout. Possibly, you should stress that in the case of a timeout
the server must not send the 400 response code.
SECTION 8.1 LIST EXTENSIONS
> the server NNTP MUST respond with one of codes 400, 402, 500 and 501.
Later in section 8.1.1 Successful response
> The LIST EXTENISONS command itself is not included in the list
> of features supported, support for the LIST EXTENSIONS command
> is indicated by return of a reply other than a 500 or 502
I think, response code 502 should be added in the paragraph above.
SECTION 8.1.3 Error responses from extended servers
> In the case of an error response, the client NNTP should issue
> the QUIT command (see section 11.1).
This means in the case of an unexpected error. Eg not in the case
411 no such news group
SECTION 9. The AUTHENTICATION Step
Is it possible to change the NNTP password via NNTP?
SECTION 10.1.1.1 GROUP
> If the group is not empty, the estimate MUST be at least the
> actual number of articles available, and MUST be no greater
> than one more than the difference between the reported low and
> high water marks. (Some implementations will actually count
> The set of articles in a group may change after the GROUP
> command is carried out. That is:
> . new articles may be added with article numbers greater than
> the reported high water mark (if an article that was the one
> with the highest number has been removed, the next new article
> will not have the number one greater than the reported high
> water mark).
Isn't there some contradiction in this section? If it is allowed to
add new articles, while the news client has selected a newsgroup, it
cannot be guaranteed that the number of articles is no greater than
one more than the difference between the reported watermarks.
Additionally, I think the setence in parentheses could be
misinterpreted because some news servers will decrease the high
watermark and some not, when the article with the high watermark is
In this section, you also explain that article reinstatement is
correct. This means that news readers must not mark deleted articles
as read. Possibly, this should also be stressed since many news readers
mark deleted articles as read.
SECTION 10.3.1 POST
Is it legal to specify an article id in an article submitted with the
POST command? (Some news readers provide their own article ids.) If yes,
it would be nice to have another response code if an article with this
id has already been posted (Eg 442 duplicate article).
This would allow a news reader to identify, whether a previous
posting, where the connection broke was already successful.
This could also be accomplished by using IHAVE. However, INN for
instance does not allow this command in ``NNRP mode'' (after the
client issued MODE READER)
Another response code could be used for an invalid article to
distinguish this kind of error.
SECTION 10.4.9 OVER
> A 502 response will be returned if the
> client only has permission to transfer articles.
May/Should the article/head/body/stat commands also return this response
Thomas Gschwind Email: tom at infosys.tuwien.ac.at
Distributed Systems Group Tel: +43(1)58801x4469
A-1040, Argentinierstrasse 8 Fax: +43(1)5058453
More information about the ietf-nntp