[NNTP] STREAMING diffs (take 2)

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:

> Okay, I've lost track of what the original proposed addition was.

> I -do- think we should talk about the pre-commit caching a little more
> than we currently do (which is simply "if, for example, another client
> has offered to send the same article to the server").

You and I seem to be the only people who feel this way so far.  I'm
currently leaning still towards deciding that not enough other people
agree with me on this and letting it go, but maybe we can convince
others.  :)

> I agree implementors are -not required- to have such a cache.  But this
> is one of those cases we've discussed previously, where we wrote the
> document with domain-specific knowledge that has not been encoded in the
> text.  I think our justification for 431 should be clear from the
> specification without any special background.  (Does anyone feel that
> this -isn't- the reason for 431?)

I'm not sure I'd go so far to say that this is *the* reason for 431.  431
is a general mechanism for deferrals for whatever reason, including for
such reasons as very short-lived service outages or retryable errors in
storing an article.  I think that, in practice, this sort of feed
interaction problem is far and away the most common use of 431, but I'm
not sure that it's fundamental to the 431 specification.  In other words,
I could see inventing 431 even if we didn't have this problem (we added
deferrals for IHAVE, after all), but it wouldn't have happened as soon.

> However, I don't feel that we need to say much more about the security
> implications of this vs other commands.  I was originally somewhat
> convinced by the argument that a broken STREAMING client can
> inadvertently deny service by offering a message-id and then crashing
> before sending it, but with Andrew's description of a more intelligent
> caching system, I'm now leaning towards considering that an
> implementation detail.

Okay, it seems like we do have consensus on making no changes to the
security section, and the only question is over whether or not to add
additional documentation on the use of deferrals and a pre-commit cache.

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