[NNTP] Extension snapshots 2

[Clive D.W. Feather]

Russ Allbery said:
>>> And, actually, even worse than that, this says that the output of
>>> CAPABILITIES may change in circumstances other than the places we've
>>> documented that explicitly (AUTHINFO, STARTTLS, and MODE READER).  I don't
>>> think that's a good idea; the CAPABILITIES output shouldn't vary except as
>>> a result of specific commands that perform major state changes and are
>>> documented as possibly changing the server capabilities.
> 
>> What if we said something like this instead:
> 
>> The client MUST NOT send this command, and the server MUST NOT
>> advertise the MODE-READER capability, if the server is already in the
>> "reader" state (designated by the advertisement of the READER capability),
>> or if a privacy or security command has been issued successfully.
> 
> 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.

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.
Therefore it seems best to make it a MUST NOT.

(2) When should the server advertise MODE-READER? Well, advertising it
suggests to the client that MODE READER is something to think about doing.
So we get:
  (a) Not if the server isn't mode-switching.
  (b) Not if it opens the internal state can of worms.
  (c) Not if the client MUST NOT send it.

We can address (a) by:

    The server MUST NOT advertise the MODE-READER capability if it is not
    mode-switching.

We can address (b) by:

    The server MUST NOT advertise the MODE READER command after a
    successful MODE READER, authentication, or privacy command {or
    after any command that changes the server state}.

(the words in braces are an additional suggestion).

(c) is harder, however. It would be easy to address by:

    The server MUST NOT advertise the MODE READER command after the
    client has issued any command except CAPABILITIES.

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.

I must say that I'm not convinced by Russ's argument. Setting an internal
flag in the server might be a minor pain but is it that bad? As for
>>> the CAPABILITIES output shouldn't vary except as
>>> a result of specific commands that perform major state changes
I think that's too strong a statement. We've told the client that issuing
any other command makes MODE READER illegal, so this *is* an explicit state
change.

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?

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

(A) If you accept my arguments:

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

    The server MUST NOT advertise the MODE-READER capability unless it is
    mode-switching and the client has not used any command in the session
    except CAPABILITIES.

(B) If you don't accept them, but continue to support Russ's view:

    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.

    The server MUST NOT advertise the MODE-READER capability if it is not
    mode-switching, and MUST NOT advertise it after any command that
    changes the server state, including but not limited to a successful
    MODE READER, authentication, or privacy command.

Now what?

[In both cases, there is some additional wordsmithing like "except with the
-- modifier" that I'm leaving out to make this discussion clear.]

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |