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

[Andrew - Supernews]

>>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:

 Ken> I just submitted the following updated draft which I believe
 Ken> addresses the issues discussed on the list since draft -01:

2.5. TAKETHIS Command

2.5.1. Usage

     Syntax
        TAKETHIS message-id

     Responses
        239 message-id   Article transferred OK
        432 message-id   Transfer failed; try again later
        439 message-id   Transfer rejected; do not retry

Any implementation that actually returns 432 will break several of the
existing streaming-mode feeders in use. As a rule, existing software
expects specific response codes only, and will behave badly (e.g. by
giving up on the connection) if an unexpected code is received.

Existing implementations exist that do return 431 in response to
TAKETHIS (bogusly; see below) and existing feeders do cope with that
to some extent (despite the fact that 431 is also used for CHECK).

However, the idea of returning a deferral in response to TAKETHIS (or
indeed as the final response after IHAVE) is in any event logically
somewhat flawed. The client in this case will always have sent the
entire article body, and it is not reasonable to expect a client to do
that repeatedly. Once the body is transferred once, the server has all
the information needed to decide whether to accept or reject the
article; transient errors at this point, such as "disk full", are
better handled by pausing or throttling the server (without sending
either 239 or 439 to the client). Some implementations do actually
return 431 in that case, but practical experience is that the
resulting behaviour is never good (some senders will discard the
articles, others will retry them indefinitely, potentially wasting
large bandwidth volumes; throttling the server works much better).

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