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

[Andrew - Supernews]

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

 >> The distinguishing factor is whether the server has any reason to
 >> expect that an immediate following TAKETHIS for a different
 >> article, or a later following TAKETHIS for the same article, has
 >> any chance of success. If the server is getting errors (such as
 >> disk full) that aren't article-specific, then it should really
 >> fail in a way that also isn't article-specific (and closing the
 >> connection, possibly rejecting further connections until the
 >> problem is resolved, seems the better option).

 Clive> The problem is that the errors are only posting-specific; they
 Clive> don't stop clients from doing anything else. Therefore closing
 Clive> the connection is a draconian solution.

It's the only solution that works in practice. We have plenty of
experience with the "return 431 to every article body" scenario and
the mess it causes.

 Clive> The answer, perhaps, is to define the 431/432/436/441
 Clive> responses as "don't try to post anything else for a while",

Trying to redefine the meaning of responses that are already
recognized by existing code is a really bad idea.

 >> If it stays in the draft, then (a) it specifically needs to be the
 >> 431 code rather than a new one,

 Clive> Back in March Russ explained why CHECK and TAKETHIS need
 Clive> different status codes. I don't have the explanation to hand,
 Clive> but I see from my sent-mail archive that they convinced me at
 Clive> the time.

Superficially they do, and life would actually be a hell of a lot
simpler if they were still unique and no implementation ever returned
431 responses to TAKETHIS. Unfortunately that simplicity went away
years ago thanks to Diablo's misuse of 431. In practice, the only way
that works is to make sure that your servers never actually return
that 431 code. Changing it to 432 may sound sensible from the point of
view of uniqueness, but it founders on the problem of incompatibility
with existing software.

If no-one can actually come up with a realistic case for why a server
should ever need to return a defer in response to a TAKETHIS article
body, then I'd suggest dropping it out of the draft entirely.

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