[NNTP] Snapshot 6

Ken Murchison ken at oceana.com
Wed Jan 12 06:56:28 PST 2005


Charles Lindsey wrote:
> In <41E41059.8040809 at oceana.com> Ken Murchison <ken at oceana.com> writes:
> 
> 
>>Clive D.W. Feather wrote:
> 
> 
>>>Here's the actual situation:
>>>
>>>  If server advertises             then it
>>>
>>>  * OVERVIEW.FMT argument          MUST provide LIST OVERVIEW.FMT
>>>
>>>  * OVER capability                MUST provide both commands
>>>                                   MUST advertise OVERVIEW.FMT argument.
>>>
> 
> 
>>Isn't providing LIST OVERVIEW.FMT or LIST HEADERS without OVER or HDR 
>>(respectively) nonsense?  I really don't see how the former are useful 
>>without the latter.
> 
> 
> Well I suppose a server that implemented only the old XOVER might still
> want to provide LIST OVERVIEW.FMT.
> 
> 
>>This goes back to my opposition to having OVERVIEW.FMT and HEADERS as 
>>arguments to the LIST capability.  By having these arguments, we open 
>>ourselves up to this kind of nonsense.
> 
> 
> No, I like them as arguments to the LIST capability, but it would be nicer
> if it could be arranged that this nonsense was forbidden by some other
> means. Though it will not be the end of the world if it isn't (I can't see
> any server in Real Life actually doing such things).

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.  If it intends to use 
OVER, it will be looking for the OVER capability, since it, and only it, 
dictates whether OVER is available.  All the client can glean from the 
presence of LIST OVERVIEW.FMT is that LIST OVERVIEW.FMT is available 
(which the OVER capability already tell us), it tells us nothing about OVER.

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.

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



More information about the ietf-nntp mailing list