[NNTP] Extension snapshots 2

[Russ Allbery]

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

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

Hm.  Okay, maybe I'm worrying too much about that aspect of things.

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

In practice, this will also not cause any problems, since either GROUP is
going to fail before MODE READER or MODE READER is going to be a no-op.

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

Haven't we already covered this at great length in this discussion?

Would it help if we just said that MODE READER MAY (but is not required
to) reset the connection to the state that it was in immediately after the
initial connection?

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

Yes, I have a significant problem with that paragraph because "commands
that change the state of the server" is undefined.  We can't say something
like that unless we intend to define exactly what commands we're talking
about.

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

So the choice is between fiddling with capabilities some more behind the
back of the client or documenting that MODE READER may reset the state of
the server.  The latter is looking more attractive to me; why not go with
documenting the existing practice?

I guess I don't really care that much; all the solutions are ugly to me in
one way or another, but that's because MODE READER is ugly so that
shouldn't really be a surprise.

>>> 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 guess I don't care enough to argue this at length, and we need to get
past this and move forward with a last call.  I find the idea of
capabilities randomly changing behind the back of the client to be
abhorrent, but maybe it's just me.

IMAP appears to be completely silent on the issue.

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