ietf-nntp Alternative HDR parameter proposal

[Ken Murchison]

Charles Lindsey wrote:
> 
> In <3E8B2944.F9BEC725 at oceana.com> Ken Murchison <ken at oceana.com> writes:
> 
> >       HDR
> >       HDR ALL
> 
> >- In the first form, the set of headers that may be retrieved from the
> >server is limited and must be discovered by the client.  I propose that
> >this can be done by using either the HDR command with _no_ arguments or
> >a new LIST HEADERS command (I have no preference, this can be determined
> >by the WG).  In either case, the output of the command is a list of
> >available headers/metadata (identical to OVERVIEW.FMT without the
> >suffixes).
> 
> But it may not be possible for the server to supply that information.
> Suppose that the server actually implements by scanning the overview
> database. Suppose that the headers stored in that database have changed
> over time (the sysadmin keeps having "bright ideas"). Then there is no
> single list that could be returned that would be guaranteed to be correct
> for all articles currently stored on the server.

Right, this is a problem with implementations of OVER/OVERVIEW.FMT, not
the specification of it or HDR.  Worst case, it simply returns the list
of headers that it currently supports.


I _believe_ the advantage of my proposal (even with the wart caused by
random OVERVIEW.FMT), is that it supports implementations which only
allow a subset of overview and/or a superset of overview, without
leaving the client guessing as to what is available.


> Russ argues that my HDR OVERVIEW suffers from the same problem - that it
> does not tell the client whether any given header will be retrieved on
> _all_ articles stored. That may be true, but at least it tells the client
> what behaviours are possible.


I agree there is a problem with _any_ implementation that ties HDR to an
inconsistent overview db.  What _should_ be happening when a
server/admin decides to change the contents of the overview db, is that
either the db is rebuilt, or the server fetches non-existent headers on
the fly, so that the client can expect consistent results.  I know that
people will say that this isn't feasible because of X, Y, and Z -- then
you shouldn't be changing OVERVIEW.FMT on the fly.  IMO any
implementation that doesn't provide consistent results to the client is
broken.

I don't see where there is any easy way to change the protocol to
support poor/inconsistent implementations, short of changing OVER to use
a fixed set of headers/meta-data and dumping OVERVIEW.FMT.


-- 
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