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