[NNTP] Re: [ietf-nntp] draft-ietf-nntpext-streaming-01.txt

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> OK, something like this?

> 			IHAVE	CHECK	TAKETHIS
> xferred OK:		235	NA	239
> send article:		335	238	NA
> not wanted:		435	438	[438]
> xfer not possible:	436	431	[431]
> xfer failed:		436	NA	[431]
> xfer rejected:	437	NA	439

> Simply reusing 431 and 438 for TAKETHIS.

If I understand your table correctly, "not wanted" is the decision made
before the article is sent, which isn't possible for TAKETHIS.  So that
column would be NA for TAKETHIS.  I think we only have one new code that
we need to come up with, where you currently have [431].

> This might invalidate your argument that the response codes need to be
> unique between CHECK and TAKETHIS, but I don't see where this breaks
> anything.  My guess is that a client wouldn't be pipelining CHECK and
> TAKETHIS together.  The client will pipeline the CHECKs, and process the
> results.  Then based on these results, it will pipeline TAKETHIS.  Am I
> missing something?  Hmm, even if a client *does* interleave CHECK and
> TAKETHIS this might still work (with a side-effect of trying TAKETHIS
> twice on an article that the server doesn't want).

I think, with the above correction, that this will work okay unless
clients really want to handle TAKETHIS deferrals different than CHECK
deferrals but don't want to do the bookkeeping to keep track of whether
the article was offered with TAKETHIS or with CHECK.  The really important
part is to keep 238, 438, and 439 distinct.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>