[NNTP] Extension snapshots 2

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:
> Russ Allbery said:

>> I got lost in the middle of that sentence.  Maybe this is a bit clearer?

>>     The client SHOULD NOT issue MODE READER after issuing any commands
>>     other than CAPABILITIES and MUST NOT issue it more than once or
>>     after any security or privacy commands are issued.  The server MUST
>>     NOT advertise the MODE-READER capabiliity after a successful MODE
>>     READER, privacy, or security command.

> Um, can I take a step back and try to look at the principles that we're
> trying to address?

> (1) When should the client issue MODE READER?
>   (a) If the server doesn't do CAPABILITIES, then it has to guess. We're
>       doing that wording in a separate sub-thread.
>   (b) We don't want the client to issue MODE READER after any kind of
>       server state change, because it means we have to either define, or
>       explicitly leave open, what happens to the server state.

> Therefore the easiest way to address this is:

>     The client MUST NOT issue MODE READER after any other command except
>     CAPABILITIES has been used in the session.

Yes, but I really strongly dislike changing CAPABILITIES in response to
anything other than AUTHINFO, STARTTLS, or MODE READER among our current
commands.  The capability list is something that we're telling the client
to rely on, remember, and use to determine what it should do, and we're
telling them explicitly to refresh it after they do something that might
change it.  I think those are the correct and valuable things to say, and
I don't want to introduce anything that weakens it.

In practice, note, sending MODE READER after doing a few other things will
work and will not pose any interoperability issues; the interoperability
issues only arise if MODE READER is sent after AUTHINFO or STARTTLS.

> Note: by making it a MUST NOT, we don't have to worry about violations
> of this rule. If we make it a SHOULD NOT, that suggests there are
> situations where it is sensible to violate it, and so client authors are
> entitled to know what the implications are so that they can decide if
> they are an exceptional case. That opens the whole internal state can of
> worms.

I don't think the worms are particularly significant.  I really do think
that my above text covers the situation and doesn't require any additional
worries about states.

Could you explain more what you're concerned about?

> This subsumes (b), but it hits Russ's objection about secretive state
> changes in the server. If we don't do it, however, then we could find
> MODE-READER being advertised when the client MUST NOT use it. We could
> fix this thus:

>     The client MUST NOT issue MODE READER after any other command except
>     CAPABILITIES has been used in the session, even if the server is
>     still advertising the MODE-READER capability.

> That feels like the wrong thing to do, because the whole point of
> capabilities is to tell clients what they can do.

Not to mention that we can't really justify a MUST NOT here on
interoperability grounds, since that action is actually quite well-defined
and doesn't pose interoperability problems.

> For that matter, the traditional implementation of LIST XXX is to look
> for the file XXX and, if found, dump it at the client. If a server
> operator adds a new file, should the LIST capability change or not? 
> Surely it should?

I wouldn't implement it that way, no.

> So, after merging sentences, this leaves me with two alternative
> wordings to offer:

I prefer my wording above to either of these.

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