[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