ietf-nntp Summary/analysis of LIST OVERVIEW.FMT responses

Russ Allbery rra at stanford.edu
Fri Apr 18 17:12:20 PDT 2003


Ken Murchison <ken at oceana.com> writes:

> Maybe I don't either :)  Unless I misunderstood, you said that some
> clients use Newsgroups and Keywords from the XOVER response, but they
> don't use LIST OVERVIEW.FMT to verify that they will be in the XOVER
> response.

Right.

> If that is the case, then they are making the assumption that the
> headers will be present (since they are not part of the standard 7) and
> in the order that they expect.

No, they look at the overview response and see if it has a Newsgroups or a
Keywords header in it.  If it doesn't, and they're needed for something,
it falls back on some other approach or disables that optional feature.
That's why all headers in overview other than the first 7 are required to
include the name of the header as well as the value.

For Newsgroups, you know that every message has a Newsgroups header, so
you can make the assumption that if it isn't present, it's just not in the
overview database.  The primary use of Keywords in overview that I'm aware
of is in conjunction with server-generated keywords support in INN, where
you can make the same assumption.

>> Really, from the client perspective, it's functionally identical.  The
>> thing is, XOVER works.  If it weren't for the X, we probably wouldn't
>> have this discussion at all and would just standardize it as-is,
>> because the amount of brokenness is totally not worth making any
>> changes.

> OK, so why are we having this discussion?

Well, for this specific one, we're trying to figure out what to do about
LIST OVERVIEW.FMT and whether we should standardize it along with OVER or
leave it behind.  The reason why I raised the issue in the first place was
because it wasn't clear to me that LIST OVERVIEW.FMT was used, even by
clients that will use additional overview data when it's there.  If no one
uses it, or if people only use it as a LIST EXTENSIONS substitute, then
there's no reason to standardize it and add some additional complexity to
the standard.

> It sounds like it is a forgone conclusion that OVER will be a carbon
> copy of XOVER and LIST OVERVIEW.FMT will remain as-is.

Not a carbon-copy, certainly; we've narrowed the definition of exactly
what is done with headers containing non-printing characters, we've made
explicit what goes into the lines data in overview, and we've made a few
other tweaks.  We've also locked down just what the command *means*, which
wasn't as explicit before.

And I still think we could probably do without LIST OVERVIEW.FMT, and so
do a lot of other people that answered the survey.  I still think that's a
possible conclusion to draw.

> I'm fine with this, but I thought we were trying to clean things up a
> bit?  If backwards compatibility is key, then we'll just leave things
> alone.

I don't care of OVER is slightly different than XOVER on some servers;
what I care about is that the specified behavior for OVER be a subset of
the acceptable range for XOVER (so that people can, when implementing
OVER, just change XOVER to match) and not interfere with any significant
functionality that XOVER currently provides.  In other words, what I'd
like to see is for both clients and servers to be able to just switch from
XOVER to OVER and have the only differences be the elimination of various
nits and differences between servers that have plagued XOVER.

I don't really care about LIST OVERVIEW.FMT one way or the other; I don't
think it's important (although some of the responses made it clear that it
needs to stick around on servers that continue to support XOVER).

If we were really looking to clean things up a lot, we could propose
things like dropping the Lines data, but I think that any drastic changes
in what the command does would work better if deferred to a more
comprehensive proposal that addresses the major problem with XOVER (namely
that clients can have to download a ton of stuff that they don't care
about, like getting Message-ID and References headers when they don't care
about threading).

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



More information about the ietf-nntp mailing list