[NNTP] LISTGROUP

[Mark Crispin]

On Mon, 25 Apr 2005, Clive D.W. Feather wrote:
>> The benefit is compliance with standard Internet protocol architecture.
> Meaning what? Just where is this "standard Internet protocol architecture"
> documented?

It is not MY job to do YOUR research for you.  If you can not fufill your 
responsibilities as document editor, then please resign and allow someone 
who is more responsible to take over.

Ken Murchison would be a good choice.

> "A foolish consistency is the hobgoblin of little minds." [Emerson]

I'm afraid that you are the one who is being small-minded.  Time and time 
again, your response to any criticism is "will not change" or to put your 
fingers in your ears and scream "I'M NOT LISTENING!"

> Just what benefit does compliance with this "standard" produce? Client code
> still needs to understand specific codes or simply say "it begins 4 or 5,
> it failed, tough luck".

Client response to a 4xx is different than to a 5xx; or rather it is in 
protocols that comply with the standard theory of response codes.

> This is *not* the same as mail where retrying later
> can produce different results.

Why?  Have you rigorously considered all instances in which mail returns a 
4xx code and determined that these can never apply to NNTP?

> As I said, if we were starting from scratch I would agree with you, but it
> is COMPLETELY AND UTTERLY POINTLESS trying to change things now. That would
> be *foolish* consistency.

It is not pointless to free future implementors from the burden of the 
current non-standard ad-hoc system of response codes.

>>> LISTGROUP currently says:
>>>    (the arguments on the initial response line are the same as
>>>    for the GROUP command)
>>> and
>>>    In all other aspects the LISTGROUP command behaves identically to the
>>>    GROUP command.
>>> That text will be staying.
>>
>> That does not answer the objection.  The values (not "arguments" -- yet
>> another thing that needs fixes)
> Wrong: they are "arguments"; it says so in 3.2.

The text in 3.2 is not a definition; it's just more of the same misuse of 
the word "argument".

>> on the response line are documented
>> independently in LISTGROUP and with subtly different wording.
> Where? As far as I can see, 6.1.2.1 uses the same wording as 6.1.1.1, and
> 6.1.2.2 just has the text you quote.

The text in 8.3.1.2 describes the effect of LISTGROUP.  It goes into some 
detail in describing how LISTGROUP is similar to GROUP in various aspects 
but omits such text for other aspects.  That omission must be significant; 
so, for example, the text in the third paragraph of 6.1.1.2 doesn't apply.

You could rewrite 8.3.1.2 to say something like:
    The LISTGROUP command is an extended form of the GROUP command
    (see Section 6.1.1).  As such, it behaves and responds identically
    as the GROUP command, with the following extensions:

    The first extension is that the newsgroup argument is optional; if
    it is omitted, the currently selected newsgroup is used.  A 412
    response is returned if there is no currently selected newsgroup.

    The second extension is that, on success, a list of article numbers
    is returned as a multi-line response following the 211 response
    code (see Section 6.1.1.2 for the semantics of this code).  The
    list contains one number per line in ascending numerical order, and
    lists precisely those articles that exist in the newsgroup.

The above text is shorter, more precise, and lacks the ambiguity of what 
is currently there.

This reminds me of something else.  The entire document uses two different 
words, "group" and "newsgroup".  Although the author may have intended 
these terms to be interchangable, that isn't the effect.  The document 
clearly identifies "group" and "newsgroup" as being separate concepts, and 
thus there must be a difference.

Also, "current selected newsgroup" is a grammar error; it should be 
"currently selected newsgroup".  Even when a verb 
is used as an adjectival, the modifier of that verb must still be an 
adverb.

> I disagree. But I don't see the "subtly different wording" you do.

See above.  You have pieces of 6.1.1.2 in 8.3.1.2, but not the entirety of 
6.1.1.2.  That must mean that the omitted pieces do not apply.

Either copy all of 6.1.1.2 to 8.3.1.2, or have 8.3.1.2 reference 6.1.1.2 
and do not duplicate what is in 6.1.1.2.

> "the same" covers everything, not just some aspects.

Sorry, that is not the way that people reading the specification will 
interpret it.  They, not you, will ultimately determine the meaning.

True life example: IMAP once defined a range as "all values between the 
two given values inclusive."  That was not enough; someone insisted that 
this only applied to ascending ranges, and that "all" does not apply to 
descending ranges.

>>>> There is no reason why the three zeros response should be allowed in an
>>>> NNTPv2 compliant server.
>>> There is no reason why it should not be allowed.
>> The three zeros response implies that article numbers have been reset, and
>> that the client should discard all knowledge of article numbers.
> No it does not. It indicates an empty group.

You may say that it does, but the fact that it exists as a separate 
response indicates otherwise.

> On the contrary, a three zeros response does NOT invalidate the requirement
> that:
>   whenever a subsequent GROUP command for the same newsgroup is issued,
>   either by the same client or a different client, the reported low
>   water mark in the response MUST be no less than that in any previous
>   response for that newsgroup in any session, and SHOULD be no less
>   than that in any previous response for that newsgroup ever sent to
>   any client.  Any failure to meet the latter condition SHOULD be
>   transient only.
> We deliberately decided not to provide a way for a server to reset article
> numbers and start again at 1; it's too rare an event to clutter up the
> protocol.

Yet you cluttered up the protocol with a pointless three zeros response 
for which there is no need since there are other responses which fufill 
the same requirements.

A server manager, having a need to reset article numbers (perhaps after a 
catastrophic failure), will see the three zeros response as being the 
means to indicate that, no matter what you say.

You always fall back on the same set of arguments.  On the one hand, you 
use "it would clutter up the protocol" to shoot down a remedy for a 
problem; on the other, you defend the maintenance of clutter on the ground 
that old servers (which aren't going to advertise NNTPv2) had the clutter.

If you choose to abuse your position as document editor to stymie any 
revision to the status quo, this entire working group is pointless and the 
document is a failure.

The document does not describe the deployed protocol.  It describes a 
revision to that protocol which will require considerable effort on the 
part of both client and server implementors to comply.  On the other hand, 
it does at best a half-hearted job in remedying problems in the deployed 
protocol which have repeatedly caused problems for client implementors.

Let's just abandon the whole thing.

-- Mark --

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