ietf-nntp Wildmats (was: draft posted)

[Russ Allbery]

Charles Lindsey <chl at clw.cs.man.ac.uk> writes:

>>  The message-ids of all articles added to a set of newsgroups since the
>>  given date-time will be listed. The set consists of all newsgroups
>>  whose name matches the wildmat.  The format of the listing will be one
>>  message-id per line, as though text were being sent. Each message-id
>>  MUST appear only once in a response. The order of the response has no
>>  specific significance and may vary from response to response in the
>>  same session. Date and time are in the same format as the NEWGROUPS
>>  command.

> My question is why that "MUST appear only once in a response" is there.

The current draft actually says "SHALL appear only once."

This was discussed previously.  As near as I can tell, it was first raised
by Andrew Gierth in <87snsz749c.fsf at erlenstar.demon.co.uk> of 2000-07-24
where he says:

    (Note: we should probably add some qualifications to make it easier:
    specifically, an explicit statement that the output of NEWNEWS is not
    ordered, and may contain duplicates.)

Clive Feather agreed with this in <20001116120658.N47729 at demon.net> of
2000-11-16:

    The unordered bit is in there, but it has:
    
      Each message-id SHALL appear only once in a response.
    
    I'd agree with you that it should be changed to:
    
    ! A message-id MAY appear more than once in a response.

As near as I can tell, there was no further discussion.  RFC 977 is silent
on this point.  Does anyone remember why this was changed in our current
draft (relative to RFC 977)?

I'm inclined to agree with Clive's proposed change unless someone else has
a reason for leaving the current text as it is.

> Does any harm actually arise if it is repeated? The worst that can
> happen is that the (sucking) client fails to notice that it has already
> asked for this article once before, asks for it again, and then finds it
> doesn't need it after all. A little inefficient, perhaps, but nothing
> actually breaks.

This analysis seems correct to me.  Clients that really care could always
eliminate the duplicates themselves, and in general it's better to push
straightforward work like onto the client rather than the server since the
server is likely to have a higher load.

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