ietf-nntp HDR

Andrew Gierth andrew at erlenstar.demon.co.uk
Wed Jan 9 07:48:12 PST 2002


>>>>> "Russ" == Russ Allbery <rra at stanford.edu> writes:

 Russ> However, I think this is still more complicated than adding an
 Russ> optional header parameter to OVER.  The rule "if you want
 Russ> article headers, use HDR, and if you want overview data, use
 Russ> OVER" seems much simpler to me.  I suppose this falls down if
 Russ> we ever have metadata we want to make available that isn't
 Russ> included in the overview database, though.

I can think of lots of metadata that isn't part of the OVER response
but which I would like to have a consistent way to return. What is
"overview data", other than an implementation artifact?

Please, let's leave OVER alone, as simple standardization of existing
practice, and concentrate on defining HDR in a sane and useful
fashion. Once this draft is done, we can think about doing a HEADERS
extension along the lines of the proposal in n.s.nntp (which is what
this whole discussion is rapidly moving towards).

I _would_ prefer to see the article header and metadata namespaces
separated for HDR, because I think it would be more useful in the long
run (new extensions could add new metadata fields without worrying
about conflicts). But I'm not that bothered about it, and I definitely
think that having Lines/Bytes as a special case is better than hacking
with OVER.

(Another suggestion is whether there should be a LIST subcommand to
identify what headers are available via HDR. Along the same lines,
the extension keyword for HDR could have a parameter, say "ALL", if
HDR on arbitrary headers is supported.)

-- 
Andrew.



More information about the ietf-nntp mailing list