ietf-nntp Draft 17 pre-2

[Russ Allbery]

Clive D W Feather <clive at on-the-train.demon.co.uk> writes:
> Russ Allbery <rra at stanford.edu> writes

>> I think we should bypass this entire debate and just not standardize
>> LIST OVERVIEW.FMT at all.  The information that it provides isn't very
>> useful, and worse is deceptively useful (in other words, it looks like
>> it's more useful than it actually is).

> It's the only way to find out all of what is in the overview database -
> using OVER on any given article doesn't tell you that, it only tells you
> what fields are in that article. So it does have some use.

That's what I meant by saying that it's deceptively useful.  It doesn't
actually tell you what's in the database.  It only tells you what's being
added to the database for new incoming articles right at that moment.

> We could remove the legacy feature completely and just say existing
> servers are non-conforming. Or we could say that the first 7 lines can
> contain any old rubbish because the OVER command doesn't have a choice
> for the corresponding fields.

Well, I'm in the category of wanting to expend the minimal possible effort
on this particular command, since I don't consider it useful at all.  I
can't think of a situation in which it would be useful to use it and where
the information returned would actually be reliable.

I could see cases where it would be useful to know what fields one can
expect from overview, particularly in the area of allowing negative
assertions (if Content-Type is not present in the OVER response, the
article is guaranteed to not contain it, that sort of thing).  But I don't
see how we get there from LIST OVERVIEW.FMT.

> [Which reminds me, could we do something like require all future
> extensions to use 6xx for multiline responses? Or is that too far?]

I'm not sure that really buys anything, given the number of multiline
responses that we already have that don't use 6xx.

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