[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