ietf-nntp HDR

[Andrew Gierth]

>>>>> "Ade" == 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.

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

There isn't one. That doesn't mean that supporting HDR on arbitrary
headers isn't a valid implementation choice. Likewise, supporting
HDR on a restricted set of headers is also a valid implementation
choice.

 Ade> And I do not, and have never, supported the implementation of
 Ade> HDR as defined,

as defined where? It seems to be generally accepted that HDR on
arbitrary headers won't work everywhere, it's just a case of defining
the responses properly so that clients can do the right thing.

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

 Ade> I have no interest in playing semantic games when I know I'll
 Ade> win.  There is no challenge or honor in that.  The HDR command
 Ade> is intrinsically flawed,

how, exactly?

 Ade> made obvious by the fact that it needs PAT as a sibling, and
 Ade> thus must be rewritten.

now this is just getting silly. In current practice XHDR is vastly
more commonly used than XPAT, so it's clear that the "need" for PAT is
questionable. Furthermore, this list ran for some time with an attempt
to standardise PAT in place of HDR, and ran into difficulties that
were not resolved, hence the switch to HDR.

-- 
Andrew.