[NNTP] LISTGROUP plus a fix for range descriptions

[Russ Allbery]

Mark Crispin <MRC at CAC.Washington.EDU> writes:

> I understood you the first time.  I disagree with the perpetuation of an
> arbitrary divergence from standard Internet protocol architecture which
> was clearly created by mistake rather than conscious decision.

Okay.  It's good to know that at least we've both understood each other,
even if we don't agree.  :)

> NNTPv2 offers a means to correct this mistake.  Given that a CAPABILITY
> (or whatever you're calling it) command will be the first thing that an
> NNTPv2 client will issue, this also informs the server that the client
> is NNTPv2 compatible.  So if you have any worries about pre-NNTPv2
> clients, you have a means to deal with it.

I'm not willing to support changing the NNTP return codes for this draft.

>> An exact value at the time that the command is issued that may have
>> changed a second later doesn't strike me as much more useful than an
>> estimated value.

> "Changed a second later"?  Are you allowing announcement of new
> articles?

No, I'm allowing articles to be withdrawn, which is the entire reason why
this is an estimate and not an exact number.  When articles are cancelled,
the number of available articles in the group decreases immediately; at
any point after the cancel, if a client attempts to read the message, it
will be told the message number is not valid.  This is true even if the
message number was previously returned by LISTGROUP, etc.

In practice, the estimate never errs on the low side, but does err on the
high side occasionally because it may or may not take into account all
cancels that have occurred in the group.  I don't see a lot of use in
requiring a guarantee that the number be accurate at the time of the GROUP
command when it may become inaccurate due to the arrival of a cancel
message an instant later.

> But, but, doesn't 6.1.1.2 ban that?  No, because that's the GROUP
> command response.  This is a different command response.  If you want it
> to have the same semantics as GROUP then you must *say* that.

So your feeling is that the statement:

   In all other aspects the LISTGROUP command behaves identically to the
   GROUP command.

is not adequate?  How does that fall short?  I'm happy to change the
wording to be more explicit; it is definitely my intention to defer to the
GROUP specification for all of these issues.

>> That's a very good question, and one that we also need to answer for
>> OVER, which has the same issue.  INN historically (all the way back to
>> 1.0!) has treated 5-1 as 5-, or in general n-m where m < n as
>> equivalent to n-.  I don't know if that's something we want to bless.
>> There is no error, though.

> Decide upon something, and specify it.  I don't care what is decided, as
> long as there's a decision and a specification of the decision.

Okay.  We've been using the standard language:

   The range argument may be any of the following:

   o  an article number
   o  an article number followed by a dash to indicate all following
   o  an article number followed by a dash followed by another article
      number

to describe ranges.  I propose adding the following sentence after this
wording everywhere it occurs in our draft:

   Any range specified as n-m where m is less than n is defined to be
   equivalent to the range n-.

>> I think they were intended to be examples that whitespace doesn't
>> matter (they're in the existing LISTGROUP writeup).

> In that case, the examples need to have a comment to that effect.

Sure, that's fine with me.

> Given how incredibly late this specification is already, I don't think
> that "lack of time" is justification to avoid fixing a real
> problem. There is no reason why the three zeros response should be
> allowed in an NNTPv2 compliant server.

There's certainly merit to what you're saying (one particular method of
representing an empty group is already singled out with a SHOULD), but I'd
like to see slam-dunk working group consensus both around reopening this
and around promoting the SHOULD to a MUST now that we have NNTPv2.  I
don't want to get bogged down in discussing it.

We may very well have that.  If people have an opinion, please speak up.

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