ietf-nntp draft-ietf-nntpext-streaming-00

[Jeffrey M. Vinocur]

On Thu, 5 Jun 2003, Charles Lindsey wrote:

> In <Pine.LNX.4.44.0306041908400.4175-100000 at puck.litech.org> "Jeffrey M. Vinocur" <jeff at litech.org> writes:
> 
> >I'm thinking about the optimization where TAKETHIS may be
> >used without an initial CHECK.  In that case, knowing the difference
> >between refusal and rejection is definitely useful.
> 
> But where these are useful differences of that sort, then normal practice
> would be to provide different response codes, surely?

I think I've gotten everyone confused by me talking about my ideal version
of this extension (if we didn't have existing implementations) and the
present draft at the same time.  Starting over from scrach, yes, I'd like
more response codes.  I don't think we can do anything useful now, though, 
unless we want to provide a different MODE that would result in new 
commands (or CHECK/TAKETHIS with additional return codes, I guess).  Seems 
like more trouble than it's worth though -- servers that would run into 
the only practical problem I can think of (below) can be manually 
configured to a desired behavior by out-of-band communication between 
admins.


> Is this information for humans, or are clients expected to react
> differently (e.g. by trying or not trying again)?

The additional arguments Ken suggested are for humans, as far as I know.  
That's why I have trouble working up enthusiasm for risking breaking some 
existing implementations.

In theory, I'd like to have return codes so that retrying is possible 
(although since this should only happen do to some sort of problem -- 
since with TAKETHIS-without-CHECK, unlike IHAVE, there's no point in 
deferring for the purposes of saving bandwidth -- perhaps 400 suffices for 
indicating retries?).  But the real reason is the situation I described 
earlier, where not being able to distinguish refuse/reject results in 
suboptimal adaptive feed behavior.


-- 
Jeffrey M. Vinocur
jeff at litech.org