[NNTP] Snapshot 6

[Ken Murchison]

Russ Allbery wrote:

> Ken Murchison <ken at oceana.com> writes:
> 
> 
>>We already do, its the OVER capability.  OVER mandates that LIST
>>OVERVIEW.FMT is available, the separate LIST OVERVIEW.FMT capability is
>>redundant and potentially confusing.
> 
> 
>>I really don't see why its useful.  I assume that a client would only
>>use LIST OVERVIEW.FMT if it intends to use OVER.
> 
> 
> Well, in the case of LIST OVERVIEW.FMT, the client may be intending to use
> XOVER, as Charles points out.  That being said, it's hard to construct an
> example of where that would imply that advertising LIST OVERVIEW.FMT but
> not OVER would be something a server would do.

But if a client is still using XOVER, it probably isn't going to use 
CAPABILITIES anyways, and advertising LIST OVERVIEW.FMT is pointless.

If the client does use CAPABILITIES and still uses XOVER rather than 
OVER, than I don't think we really care about this client (since it 
should be trivial to make an XOVER client an OVER client).


>>If a LIST variant is useful by itself, then I can see why we would
>>advertise it separately, but if it is implicitly tied to other
>>functionality which has its own capability, then its makes no sense to
>>me whatsoever.  In my experience, allowing for ambiguity in a protocol
>>is a *bad* thing.
> 
> 
> The problem is that we have two different things with which we can be
> consistent:  we can make a simple rule across the board that all list
> varients are advertised via the LIST capability, or we can have one
> capability per linked set of commands.  Either way we go, we break the
> other consistency principle.

My simple rule would be that all list variants not tied to other 
capabilities are advertised via the LIST capability.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp