[ietf-nntp] LIST HEADERS

[Ken Murchison]

Clive D.W. Feather wrote:
> Okay, in the absence of comment pro or anti, I drafted text for a version
> of LIST HEADERS that treats both types of HDR command equally.
> 
> This is the last item I have outstanding. Once we've resolved it, I can
> publish draft 21 and then Russ can decide where we go from here.
> 
> Here is the new text with change flags.
> 
>    8.6 The HDR extension
> 
>    This extension provides two new commands: HDR and LIST HEADERS. The
>    label for this extension is HDR.
> 
>    The HDR extension provides access to specific headers and metadata
>    items (collectively "fields") of articles or groups of articles. In
>    the case of headers, an implementation MAY restrict the use of this
>    extension to a specific list of headers or MAY allow it to be used
> -  with any header. In the latter case it MUST use the argument "ALL"
> -  following the extension label in the output of LIST EXTENSIONS; in
> -  the former case (including the situation where the HDR command may be
> -  used with any header in some circumstances but only with specific
> -  headers in others) it MUST NOT use any argument.
> +  with any header; it may behave differently when the HDR command is
> +  used with a message-id argument and when it is used with a range or
> +  no argument. The server MUST use the appropriate argument following
> +  the extension label in the output of LIST EXTENSIONS:
> +
> +     +-----------------+------------+--------------------------+
> +     | with message-id | with range | LIST EXTENSIONS argument |
> +     +-----------------+------------+--------------------------+
> +     | restricted      | restricted | (none)                   |
> +     |                 |            |                          |
> +     | restricted      | any header | ALLRANGE                 |
> +     |                 |            |                          |
> +     | any header      | restricted | ALLMSGID                 |
> +     |                 |            |                          |
> +     | any header      | any header | ALL                      |
> +     +-----------------+------------+--------------------------+

Since we have already come up with a way to represent "all headers" in 
the LIST HEADERS output, I'm in favor of adopting the KISS principal and 
removing the extra keywords from the HDR capability.  I originally 
proposed the ALL keyword before we had come up with a bare ":" to 
represent "all headers" and before we had to have the range vs. msgid 
split.  Removing the extra cruft from the HDR capability and leaving the 
complexity in LIST HEADERS seems like a cleaner solution to me.

Again, without any input from client authors, we may be making things 
too complex.  Do we even know if clients care to fetch headers (or 
overview) by msgid?

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