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