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

[Clive D.W. Feather]

Andrew - Supernews said:
>  Clive> As I see it, the 432 response to TAKETHIS has exactly the same
>  Clive> meaning as the 436 response to IHAVE. We explicitly list 436
>  Clive> as being possible after the article body has been sent. So
>  Clive> when do existing servers generate this response?
> 
> INN never generates 436 after receiving an article body. Older diablo
> versions (haven't checked newer ones) generate 436 if they failed to
> store the article, which is bogus for the same reasons that I covered
> for the TAKETHIS case (it results in the sending end wasting a lot of
> effort).

No, you mean "which triggers undesirable behaviour in broken clients". It's
not at all a bogus response; on the contrary, it's a conforming one.

>  Clive> If they do, why shouldn't they generate 432 in the same
>  Clive> situation?
> I assume you mean "431" rather than "432", because generating 432
> under any circumstances whatever breaks existing streaming clients.

No, I mean 432 because that's what the specification say. Just because
some existing clients are broken (and crashing when they receive 432 is
broken) doesn't mean that we have to pander to them.

There may be grounds for not distinguishing the CHECK and TAKETHIS
responses, but you need a better argument than bogusware.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |