ietf-nntp HDR

[Russ Allbery]

Andrew Gierth <andrew at erlenstar.demon.co.uk> writes:

> No, that's _not_ what the OVER response does! As I've explained on
> several occasions, collapsing whitespace in overview headers _does_
> confuse clients (because existing servers don't do it for XOVER, and the
> content of the mandatory overview fields are expected (by clients) to be
> the same for any given article regardless of the server).  Currently,
> overview responses _do_ differ when folding or strange control
> characters are present, which is why a) we need to define exactly how
> this should be done and b) we should ensure that for the
> no-control-characters, no-folding case, where current servers all behave
> the same anyway, we should stick with the existing behaviour.

> At some point when we discussed it before, we defined the "overview
> transformation" for any given header as follows:

>   - unfold the header by removing all CRLF pairs
>   - replace any remaining occurrences of CR,LF or TAB,NUL with spaces
>   - leave all other octets intact

> (my server, in addition, removes leading whitespace, and treats bare LF
> as a linebreak in addition to CRLF)

The current draft has:

    The content of each field is formed by taking the original content
    (such as the raw subject line from the article), removing all US-ASCII
    CRLF pairs, and then replacing each remaining US-ASCII NUL, TAB, CR,
    or LF character with a single US-ASCII space.

I think that's pretty much perfect, and believe that we should specify the
same thing for HDR.  We had a lot of discussion about this for OVER and
arrived at the above as the best approach.

I'm going to draft a replacement for the current HDR section incorporating
this and the other comments that have been posted, since there seem to be
a lot of different little changes to that section.

> Existing practice with XHDR/XPAT is (as I've repeatedly pointed out)
> broken in this respect: some servers (Typhoon and its ilk) behave as
> though the requested header were empty, other servers (e.g. INN, and
> mine) return a 501 error.

> I'd like to be able to allow HDR on arbitrary headers, but at the moment
> it's out of the question for performance reasons.

I think a 503 response is the best approach here, even though it isn't
anyone's existing practice right now.  501 doesn't make any sense, as it's
not a syntax error.  503 seems to be exactly what the situation needs.

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