[NNTP] LISTGROUP

Mark Crispin MRC at CAC.Washington.EDU
Mon Apr 18 17:36:38 PDT 2005


On Mon, 18 Apr 2005, Russ Allbery wrote:
> So... I've tried to explain a few times that NNTP does not use the 400 and
> 500 conventions of other protocols like SMTP.  NNTP can't be abusing
> something that it never followed and never even tried to follow in the
> first place.  Are you not agreeing with my point, not understanding it,
> not remembering it...?

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.

The issue isn't that NNTP has its own schema of response code; the issue 
is that NNTP has its own schema that overlaps a well-established scheme.

> If we were redoing the protocol from scratch, we'd use the same return
> code conventions as everyone else, but since we're not and since changing
> all the return codes obviously can't happen, I guess I don't see a lot of
> utility in discussing it.

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.

Eventually, we will have NNTPv2-only clients and servers which will 
disconnect if the other end isn't NNTPv2-compatible, and the old ways will 
be evil memories.

There is precedent for this in IMAP.

>> Can we get rid of that "estimated" from "estimated number of articles in
>> the group"?  As far as I am concerned, an estimated value is worse than
>> useless, and an NNTPv2 compliant server should be required to give an
>> exact value.
> 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?

> Anyway, no, we can't change this and stay within the
> charter of the working group (even putting aside the question of whether
> it's a feasible change to expect software to do).

Quality server software can do the right thing.  Protocols should not 
accomodate poorly-written server software.

And there is no charter reason why NNTPv2 can't require a quality 
implementation.

>> What is a "reported" high and low water mark as opposed to a high and
>> low water mark?
> Same thing.  I'm not sure why the word "reported" is there, but it's used
> fairly consistently through the rest of the draft as well.

If you can't justify it, it should be removed.

"Reported" means something totally meaningless that can be any arbitrary 
value or even a constant across all newsgroups.  According to the 
specification the way you have it written, a compliant server can respond 
with "211 4294967296 4294967296 0 <ngname>" for all newsgroups.

And yes, I mean an article count of "infinity", a "low water mark" of 
infinitity and a "high water mark" of zero.  After all, these are just 
"estimates" and "reported" values, so they can be anything.  Absurd?  Yes. 
Valid according to the specification?  Also yes.

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.

>> In a range, how is 5-1 interpreted?  Is it equivalent to 1-5?
> 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.

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

>> Your first example is really of a "never posted to group" instead of an
>> "empty group".  You probably should have a separate empty group example.
> It could be either; see 6.1.1 where this is discussed.

Nope.  That's the GROUP command, not the LISTGROUP command.  If you want 
the rules of 6.1.1.2 to apply, you have to have an explicit reference to 
those rules in the LISTGROUP description.

Otherwise, it is valid to claim that LISTGROUP works differently than 
GROUP.

> One of those
> places where we're documenting existing practice, and while we have some
> leeway to revisit some of this given the NNTPv2 capability, this is really
> not one that I want to reopen; we need to finalize and publish something
> soon.

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.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.



More information about the ietf-nntp mailing list