ietf-nntp OVER and HDR parameter comments

[Ken Murchison]

Russ Allbery wrote:
> 
> Ken Murchison <ken at oceana.com> writes:
> 
> > My general observation of the current OVER text and the HDR parameter
> > proposal is that implemention is driving the protocol.
> 
> One general point here to keep in mind is that implementation is going to
> drive our protocol to a substantial degree because that's our charter.

I wasn't arguing against documenting existing practice, I agree that the
charter is correct.  My nit is with letting potential/suggested
implementation hints creep into the text.

> I have no inherent problems with wording changes along these lines to make
> the descriptions more generic.  At this stage in the development of the
> draft, it would probably be most useful if you could suggest specific
> wording changes to the current draft, though.  (In other words, "change
> the first sentence of the fourth paragraph of section X.Y to instead
> read....")

OK, as soon as the OVERVIEW.FMT issue is settled, I'll suggest some
text.

> > Similarly, its seems as if the HDR parameter proposal is a way of
> > linking HDR back to the OVER implementation (or some other
> > implementation decision).
> 
> No, it's an attempt to document a very widespread implementation choice.
> Servers have found a need in practice to restrict the use of HDR to
> particular headers that are already indexed.  I don't want to second-guess
> that decision; there's a great deal of operational experience behind it.

OK.  I won't argue with that.

> > Whether the particular header is cached in some way shouldn't be an
> > issue.  If the client really wants/needs a header, its going to get it
> > by grabbing the HEAD and then parsing it itself.
> 
> Yes, but clients expect that command to be slower, and that puts more work
> on the client.  The client can only retrieve one header at a time.  HDR on
> the other hand can be applied to thousands of articles with a single
> command, and can put an extremely disproportionate load on the server.

Yes, but if the client is going to fetch the header itself via thousands
of HEAD commands, that will eat bandwidth.  It comes down which is
cheaper.  I'm guessing that server CPU is cheaper than bandwidth, but I
could be completely full of shit.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp