[NNTP] STREAMING diffs (take 2)

[Jeffrey M. Vinocur]

On Jun 13, 2005, at 8:01 PM, Russ Allbery wrote:

> So, the whole reason why I wrote the text this morning is that, 
> thinking
> about it, I felt like there was an issue regarding pre-commit caches 
> that
> most everyone implements, that's necessary to avoid duplicate articles 
> in
> practice, but that the document doesn't talk about.  That's not 
> actually
> just a question of abuse, although it happens to also help with one
> particular abuse case.  So I think we're talking about multiple things
> here.

> [...] Could folks weigh in on what they think about both?


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").

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?)

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.




-- 
Jeffrey M. Vinocur
jeff at litech.org