Clive D.W. Feather
clive at demon.net
Thu Mar 24 00:36:38 PST 2005
Russ Allbery said:
>> Will the current article number (pointer) be set to the first article in
>> the group, as GROUP demands, or will it be set to the first article in
>> the range? I'm inclined to suggest the latter.
> After thinking about this for a moment, I have no strong opinion, except
> to say that if we want it to be range-dependent, we need to hammer out
> exactly what implication that has if there are no articles in the
> specified range.
And other questions, such as what are the effects of NEXT and LAST if they
would take the current article number out of the range?
I can live with the following:
* A range can only be provided if the group name is provided.
* The range acts as a filter on the returned results of the LISTGROUP
command, but does not affect the server state.
In other words, it's a way to reduce the size of the response by discarding
unwanted material, but that's all.
I am strongly against anything that tries to push the envelope beyond that.
>> If the newsreader cannot remember the most recently selected newsgroup,
>> it's broken, the standard should not take an interest in this SOEP(*).
Actually, I'm not so sure. Modularity of code means it's sometimes awkward
to keep track of this stuff, and having an enquiry facility can be useful.
Note how you *can* find the current article number by going STAT with no
Furthermore, LISTGROUP already needs to know the currently selected group
in case it's invoked with no arguments. This is a way to get the group name
but, of course, you then get the entire group listing dumped at you.
Can I suggest that GROUP with no arguments should be permitted? This would
improve the commonality between the two commands (to all intents and
purposes, LISTGROUP is already GROUP with more output).
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 | |
More information about the ietf-nntp