ietf-nntp Alternative HDR parameter proposal

[Ken Murchison]

I have re-read the discussions, and believe that I have a firmer grasp
of why HDR is sometimes limited and/or coupled to OVER.  However, I
still don't like coupling the two in the actual protocol, and I don't
like designing a mechanism where clients have to guess what is
supported.  Given this, and the fact that OVERVIEW.FMT is still being
discussed, I propose the following:

- The label for the HDR extension can take one of the following two
forms:

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

- In the second form, the server can retrieve any and all
headers/metadata.  In this case, the header list discovery command
should either be disabled or return an error (since we can't reasonably
list all possible headers).


This proposal is clean, tells the client exactly what it can/can't do,
and seems to satisfy all of the requirements/desires discussed
previously.

Thoughts?

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