ietf-nntp Summary/analysis of LIST OVERVIEW.FMT responses
Ken Murchison
ken at oceana.com
Fri Apr 18 15:09:58 PDT 2003
Russ Allbery wrote:
>
> Ken Murchison <ken at oceana.com> writes:
>
> > Based on the fact that of the clients that actually used OVERVIEW.FMT,
> > they only used it to test for XOVER and/or check for the presence of
> > Xref, I propose that LIST OVERVIEW.FMT should be dropped from the new
> > base spec and that OVER should be standardized to return the following
> > fixed set of items:
>
> > article number
> > "Subject" header
> > "From" header
> > "Date" header
> > "Message-ID" header
> > "References" header
> > :bytes metadata item
> > :lines metadata item
> > "Xref" header (just the contents, NOT :full)
>
> I thought a lot about this approach, but the difficulty with it comes in
> with how a server would implement it in the face of an existing XOVER
> implementation. People actively use additional overview fields
> (Newsgroups and Keywords being the most common) for some applications;
> they just don't use LIST OVERVIEW.FMT to figure out that they're there.
Gee, more non-standard stuff. It's clear that the horse has been out in
front of the cart for far too long ;) Where does a client get off
_assuming_ that certain headers will be present and in a specific
order? IMO, that's a poorly written client.
Why would Newsgroups be needed in the overview data? The client already
knows what newsgroup they are in because it has to select it before
using [X]OVER. In any event, then lets just standardize whichever set
of headers/metadata are deemed important by the majority of clients. I
guess an important question that was missing in the poll, was which
fields do clients expect to be in [X]OVER.
If the output of [X]OVER _needs_ to be free-form, then I guess we're
stuck keeping OVERVIEW.FMT.
> While telling them to switch to HDR isn't a bad idea, servers that want to
> support those clients have to keep supporting XOVER until they all switch.
> But OVER wouldn't allow inclusion of those extra fields, which now makes
> implementing OVER quite a bit more difficult.
How so? If you already implement XOVER, OVER is trivial. Its either
the same output, or a subset of it. Are we back to implementation
driving the protocol again?
> (Similarly, dropping :full
> from Xref causes problems for transitioning server software.)
Its seems trival to strip off the header name, but I don't care either
way.
> Otherwise, yes, I'd definitely agree with you.
I guess this means that I'm not complete clueless ;)
--
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