[NNTP] Extension snapshots 2

[Russ Allbery]

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

>> I'm not sure we need the bit after the "or"; I don't think that really
>> provides anything useful at this point.  It's not like the world ends
>> if they try it and the command fails, since we're already into
>> guesswork territory given that the server doesn't support CAPABILITIES.

> True. I was trying to write text that says "beware, the server might be
> mode-switching and so won't support both IHAVE and GROUP etc. at the
> same time".

Except that some of them do.  *sigh*.

> How about this?

>     o  if the client wishes to use the IHAVE command, it SHOULD NOT use
>        the MODE READER command, but should be prepared for some
>        commands to be unavailable;

> or "some READER commands".

Yeah, this is what I was worrying about in the other message.

I think we should invert the sense of this, because that's what actually
matches what people do in practice:

 o if the client wishes to use any reader commands, it SHOULD use the
   MODE READER command immediately after the initial connection;

 o otherwise, it SHOULD NOT use the MODE READER command, but should be
   prepared for some commands to be unavailable.

That avoids the issue that some reader servers do also provide IHAVE.

>> I don't think we need to allow for the server doing strange things in
>> response to a second MODE READER command.

> Remember that "strange things" includes forgetting the currently
> selected group. Put another way, does MODE READER reset the internal
> state or not?

It does not in INN.

> We never did resolve that, and that's what I'm trying to avoid having to
> do.

That's probably a good thing, because I can't be sure how other servers
might implement it.  However, I think I'd rather tell the client not to
send it twice than talk about what the server might do if it does.  I am
convinced by the above that it's probably worth telling the client not to
send it twice.

> Actually, given this whole thing is aimed at solving one very restricted
> problem, how about being prescriptive:

>     The client MUST NOT send this command, and the server MUST NOT
>     advertise the MODE-READER capability, after any other command except
>     CAPABILITIES has been used in the session.

Hm.  It's more complexity for the server to keep an internal state flag
and know if other commands have been used in the session.  That part of
this is kind of ugly; if it weren't for that, I'd like the idea.

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