[NNTP] Fwd: Gen-art review of draft-ietf-nntpext-streaming-05

[elwynd at dial.pipex.com]

Maybe I am missing something here, but the original reason for my raising this
query is that the streaming commands are different from the others.

Unless I have totally misunderstood (and I may have), the non-streaming commands
expect to generate a response from the server before the client sends another
command (that was apparently the whole point of the streaming commands to get
round this synchronicity).  My understanding was therefore that a server would
be able to quickly discard commands (and maybe drop the connection) if another
command arrived before it sent the response for commands other than the
streaming ones because it would be a protocol error.  The streaming ones on the
other hand could be legitimately sent as fast as the client could make them thus
leading to a potential drain on the server which it couldn't easily control.  As
far as I am aware all the counterexamples cited recently are from synchronous
protocols, rather than the asynchronous scheme which the streaming commands
introduce.  

Regards,
Elwyn

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

> Ken Murchison said:
> > Should we say something along the lines like "if the number of rejected 
> > TAKETHIS commands exceeds an implementation specific threshold, the 
> > server SHOULD/MAY terminate the session with a 400 response".
> 
> I won't scream if you add it, but as I've just written, I don't see this as
> being NNTP-specific.
> 
> If the client really is malicious, tarpitting it might be better than just
> issuing a 400.
> 
> -- 
> 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            |                            |
> 


--