ietf-nntp HDR

[Russ Allbery]

Ade Lovett <ade at lovett.com> writes:
> 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 didn't say that it was.  I said this to rebut your statement that I'm
arguing from some sort of ivory tower of standardization.  I'm not; I'm
arguing from a widely deployed existing implementation.

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

I believe you.

However, the NNTP standard is not only for servers of "sufficient scale."
It's also for internal servers handling a handful of groups.  Those
servers have found XHDR on arbitrary headers to be valuable.  Given that
there is no reason to put an arbitrary limit into the *protocol* provided
that the server has a way of saying "no, I don't support that on this
header" in a way that allows the client to fall back on another approach,
I don't see any reason why we should add such an arbitrary limit just
because you think that supporting such a feature is a bad idea on a huge
server.

In fact, I claim that XHDR on arbitrary headers has proven useful in
practice for medium-sized and even some large servers, and HDR on
arbitrary headers will be useful in the same circumstances.  You don't
have to support it; why do you wish to outlaw the rest of us supporting
it when our circumstances are different?

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

I'm very confused by this paragraph, given that no one is telling you to
support anything at all except possibly a new return code.  Is there
something about returning 503 for HDR on headers not in overview that you
don't like?  Could you be specific as to why you don't like that
description of the command response codes?

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

Please see the archives for the extensive discussion of why <match-regexp>
is sufficiently vague as to not be worth the time trying to standardize at
the present time.  I don't think it's a good idea to revisit that
discussion; this working group already reached consensus on the point and
I doubt there will be new arguments raised.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>