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

Andrew - Supernews andrew at supernews.net
Mon Oct 18 12:04:12 PDT 2004


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

 Clive> The realistic case is very simple: if the server can't accept
 Clive> the article now but has no objection to the article itself,
 Clive> then it needs some way to say so. There are only three ways to
 Clive> do this:

 Clive> (1) Declare that you can never defer an article: if sending it
 Clive> goes wrong for any reason, that article can NEVER EVER FOR
 Clive> ETERNITY be accepted.

This is obviously wrong.

 Clive> (2) Give a bogus response like 400 plus dropping the
 Clive> connection, at which point the client doesn't know what is
 Clive> wrong and will retry the same action.

This is not "bogus" because (a) it is the existing behaviour and (b) it
works well in practice.

 Clive> (3) A defer code.

 Clive> This is so obviously superior that RFC 977 did it and SMTP does it.

This is not SMTP, and there are some very important differences.

As for 977, the best you can say about it is that it is ambiguous. It fails
to distinguish well between codes that are used in response to the IHAVE
command itself, and those that are used in response to the article sent.
In the kind of environment in which 977 and the reference implementation
were written, having a "defer" response is actually of some value, but
that environment is very different from modern streaming feeds. This makes
it reasonable to keep the existing 436 response for IHAVE, but it doesn't
in any way justify breaking the streaming feed spec just to add a code that
is of no practical use.

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




More information about the ietf-nntp mailing list