ietf-nntp HDR

Ade Lovett ade at lovett.com
Fri Jan 4 19:41:38 PST 2002


On 01/04/02 10:43, "Charles Lindsey" <chl at clw.cs.man.ac.uk> wrote:

> In <ylitajjqry.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu>
> writes:
>> So do we want HDR to be able to retrieve non-header information?  That's
>> the fundamental question, isn't it?
> 
> Well we might, but only if the syntax makes it clear what is happening
> (hence CLive's :Lines and :Bytes, which I don't particularly like, BTW).

No.  You don't.  HDR should be intrinsically linked to LIST OVERVIEW.FMT, we
are providing this short-form command (HDR) to get individual items that
make more sense that getting the entire header (HEAD) and grabbing the bits
you need.

This then gives y'all the flexibility (via LIST EXTENSIONS) to implement a
further command (or modification to HDR thereof) to be able to pull
"non-standard" headers from those systems that choose to provide them,
without constraining server operators in any way.

A quick rewrite saying that before HDR can be used, a LIST OVERVIEW.FMT
MUST be carried out, and the client SHOULD be ready to work around issues if
the list of headers isn't what it wants (via HEAD) would clear the whole
mess up considerably.  Similarly for XPAT/PAT/whatever the hell you want to
call it.  The command with the extra searching parameter (hey, why can't
that be an optional parameter to HDR, if it exists, it returns only matches
to the regexp [to be defined] in that argument).  One less command to
implement/special case/whatever.

-aDe




More information about the ietf-nntp mailing list