ietf-nntp IHAVE response codes
Russ Allbery
rra at stanford.edu
Thu Jul 5 01:00:49 PDT 2001
The section on IHAVE in the current draft is very unclear on what reply
codes may be used in direct reply to the IHAVE command and what reply
codes are only valid after the article has been sent. This comes up
specifically because INN since version 2.0 has been replying directly to
the IHAVE command with a 436 reply to do deferrals in some circumstances,
and it's unclear from the standard whether this is permissable. (I think
it should be; deferrals are valuable and that reply code is unambiguous.
Note that it isn't the same reply code as a streaming deferral, which is
431.)
Section 9.3.2 currently has:
The IHAVE command informs the server that the client has an article
whose id is <message-id>. If the server desires a copy of that
article, it MUST return a response instructing the client to send the
entire article. If the server does not want the article (if, for
example, the server already has a copy of it), a response indicating
that the article is not wanted MUST be returned.
I think this should be reworded along the same lines as POST. Proposed
new text:
The IHAVE command informs the server that the client has an article
whose id is <message-id>. If the server desires a copy of that
article, it MUST return response code 335 instructing the client to
send the entire article. If the server does not want the article (if,
for example, the server already has a copy of it), response code 435
indicating that the article is not wanted MUST be returned. Finally,
if the article isn't wanted immediately but the client should retry
later if possible (if, for example, another client is in the process
of sending the same article to the server), response code 436 MUST be
returned.
Similarly, the next paragraph isn't entirely clear on allowed responses:
If transmission of the article is requested, the client MUST send the
entire article, including header and body, in the manner specified for
text transmission from the server. The server MUST return a response
code indicating success or failure of the transferal of the article.
I propose the following text instead:
If transmission of the article is requested, the client MUST send the
entire article, including header and body, in the manner specified for
text transmission from the server. The server MUST return either
response code 235, indicating that the article was successfully
transferred, response code 436, indicating that the transfer failed
but should be tried again later, or response code 437, indicating that
the article was rejected.
I believe that the final example is also wrong. It currently has:
Example of sending an article to another site that rejects it
[S] 200 NNTP Service Ready
[C] IHAVE <i.am.an.article.you.will.want at nowhere.to>
[S] 335 Send it. End with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: nobody at nowhere.to (Demo User)
[C] Newsgroups: misc.test
[C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Nowhere, To
[C] Message-ID: <i.am.a.test.article at nowhere.to>
[C]
[C] This is just a test article.
[C] .
[S] 435 Don't send it again
but 435 (a "refusal" in the standard terminology) should only be sent in
response to the initial IHAVE command; after the article has been sent,
437 (a "rejection") should be used. I think that example can be dropped,
as there's already an example of a 437 response.
I would also add two more examples:
Example of sending an article to a site that already has it
[S] 200 NNTP Service Ready
[C] IHAVE <i.am.an.article.you.have at nowhere.to>
[S] 435 Duplicate
Example of sending an article to a site that requests the article be
tried again later
[S] 200 NNTP Service Ready
[C] IHAVE <i.am.an.article.you.defer at nowhere.to>
[S] 436 Retry later
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the ietf-nntp
mailing list