[NNTP] draft-ietf-nntpext-streaming-02

Andrew - Supernews andrew at supernews.net
Mon Oct 18 11:14:51 PDT 2004


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

 >> What I'm saying is that I know of no cases in which it makes sense
 >> for a server to return a deferral after the article body in either
 >> IHAVE or TAKETHIS.

 Clive> So your position is

My position is what _I_ said, not your misunderstandings of what I said.

 Clive> that the specification(s) should say something like:

 Clive>     If the server is unable to process the article
 Clive>     immediately, or runs into any problem when processing it,
 Clive>     it will reject the article and the client MUST NOT attempt
 Clive>     to re-send it *EVER AGAIN*.

I explicitly did not say that.

If the server can't accept the article for reasons that are specific
to that article, then re-sending it will be futile and therefore a
rejection rather than a deferral is appropriate.

If the server can't accept the article for reasons that are _not_
specific to the article, then those reasons will also apply to the
following articles in the stream, and returning a continuous stream of
deferrals is extremely client-hostile behaviour, since the client has
no way to know how long it will take before the articles can be
accepted again. Instead, the right action is for the server to close
the current connection with a 400 response, and then refuse the
client's attempts to re-establish it (or if it wishes to allow the
client to use non-feeding commands, allow the client to reconnect but
close the connection again on a subsequent TAKETHIS) until it is once
again able to accept articles. Note that in practice the server's
inability to accept articles could last from several minutes up to at
least a whole day.

This behaviour is already understood by clients because it is commonly
used in practice in existing implementations. The clients response to
it is to put all the currently in-flight articles (_including_ the one
that triggered the close since no 239 or 439 response was seen for it)
back into the queue and then try, at appropriate intervals, to re-open
the connection.

 Clive> If you disagree with this, then you're saying there needs to
 Clive> be a "defer" code.

I'm saying that in nine years of installing, running, maintaining and
writing from scratch NNTP implementations of various sorts, I've yet
to encounter a single case where returning a "defer" code _in response
to an article body_ was a reasonable thing to do. I also have
extensive experience of the things that go wrong when dealing with
implementations (that, obviously, I _didn't_ write) which attempt to
return such a response.

-- 
Andrew, Supernews
http://www.supernews.com




More information about the ietf-nntp mailing list