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

[Ken Murchison]

Clive D.W. Feather wrote:

> 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.


FWIW, I agree with Clive on this point (regarding 436, I think the jury 
is still out on 432).  I'm all for trying to document existing practice, 
as long as existing practice isn't horribly broken.  Poor 
implementations should wither and die, not continue to exist because we 
retroactively make them compliant.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp