ietf-nntp HDR

[Ade Lovett]

On 01/04/02 22:33, "Russ Allbery" <rra at stanford.edu> wrote:
> INN supports XHDR on arbitrary headers and will support HDR on arbitrary
> headers.  That's a reality of existing implementation.  Deal with it.

Please cite the document that absolutely specifies INN as the reference
implementation.

> I do not support encoding your software limitations into the standard
> unnecessarily.  HDR on non-overview headers works fine for a variety of
> NNTP servers other than extremely high-end Usenet servers with huge client
> bases, and this standard is for those servers as well as yours.

And I do not, and have never, supported the implementation of HDR as
defined, since it is truly stuck in the world of infinite bandwidth,
infinite cpu, and a whole bunch of other things that render it useless for
any server of sufficient scale.

This is about best common practice.  Sure, there may be a relatively few
number of servers in the ultra-high-end class (I can really only think of
one), but until y'all remove the blinkers and accept that there are scaling
issues which render the more academic documents less effective over time,
and work within those outer limits that few (maybe 2 or 3) on this list have
ever seen required of a news server, then, and only then, are you qualified
to even comment upon what my servers do or do not.

> Don't play semantic games to try to avoid the issue when you know
> perfectly well what I'm talking about.  The origin of the HDR command in
> our draft is very well-documented in the archives.

I have no interest in playing semantic games when I know I'll win.  There is
no challenge or honor in that.  The HDR command is intrinsically flawed,
made obvious by the fact that it needs PAT as a sibling, and thus must be
rewritten.  Try  HDR <range>|<messageID> <header> [<match-regexp>]  for a
start.  Wow.  That was easy.  No PAT, either.

-aDe