[NNTP] Extension snapshots 2

[Clive D.W. Feather]

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.

[Charles notes that "other than CAPABILITIES" would be better worded as
"that change the state of the server".]

>>   (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.

This is still a major objective, as I see it.

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

I think you're being over-hopeful. On the contrary, what we say is:

    The response generated by this command MAY change during a session
    because of other state information (which in turn may be changed by
    the effects of other commands). An NNTP client is only able to get
    the current and correct information concerning available capabilities
    at any point during a session by issuing a CAPABILITIES command at
    that point of that session and processing the response.

That wording (which came from LIST EXTENSIONS, IIRC) certainly implies that
the available capabilities can change for reasons other than specific
commands.

In particular, I can imagine a server architecture where the administrator
can load and unload modules dynamically.

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

Or GROUP or LISTGROUP. Or anything else which sets state (admittedly, the
current selected group is the only state which comes to mind).

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

RFC 2119: "SHOULD ... the full implications must be understood and
carefully weighed ...". This requires the implementer to know what the full
implications are. In some cases these implications are obvious, but in this
case they aren't unless you're already experienced with NNTP. So what are
those implications?

Furthermore, as far as I can see, if a client violates the SHOULD, the
real-world implication is that the server isn't required to interoperate
properly with it (for example, it may forget the currently selected group).
Failure to interoperate, surely, is the very exemplar of a MUST NOT?

How about:

| The client MUST NOT issue MODE READER after issuing any commands that
| change the state of the server and, in particular, MUST NOT issue it
| more than once or after any security or privacy commands are issued.

Do you have a problem with MUST here? If so, I don't understand it.

On the server side, I don't believe it is right to advertise a capability
when it is unsafe for the client to make use of it. If the server state has
changed, then either:
* MODE READER MUST NOT be advertised, or
* we must document how MODE READER affects the state.

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

But should we be outlawing such implementations? If so, why?

I think you're wrong to say that capabilities can never change under the
feet of the client; certainly nothing in the present wording implies that.
It may be that we want to put restrictions on this but, if so, we need to
think them through and be able to justify them.

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