Re: Why does Gnus generates Lines: header in mail?

[Russ Allbery <rra@stanford.edu>]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> * Russ Allbery <rra@stanford.edu>  on Mon, 30 Sep 2002

> | Not to mention that roughly 10% of the Lines headers seen in the wild on
> | Usenet are completely wrong.

> Let's just say that I do not agree with this being a valid reason for
> deprecating it or eliminating it entirely.  Everything else, sure.  This,
> no.

The line of argument went like this on USEFOR, and I think the argument is
valid:

We looked around to see where Lines headers come from.  We found that many
of them are created by clients or the original server, that many servers
pass them on unchanged, and that some servers always replace them locally.
We also found that essentially no one enforces their accuracy (although
they may be replaced locally).

We thought about how to write up a specification for the Lines header
compatible with existing practice, and in order to make it useful, we
would have to mandate that each server generate its own and store it in
the article.  Generation of headers by the server is nasty; Xref already
requires special-case code in the news server, and adding another header
requires more special-case code.  Plus it means that there's more of the
article that may mutate as it passes around the net, which is bad except
where it's unavoidable (like Path and Xref).

So then we started looking at whether it really was worth fixing.  The
information is completely redundant with information in overview, which on
most servers is accurate whereas the header is not guaranteed to be.  We
then looked at the Lines headers in the wild, and found that they were
frequently so wildly inaccurate as to be worthless for any sort of
filtering; no property at all can be reliably assumed about an article
based on its Lines header.

So standardization of the header seemed pointless; it would just add
additional redundant information, when we could encourage people to use
overview or count lines themselves if they really want that information
and can't use NNTP.  Anyone using the header right now already is having
problems, due to the frequent inaccuracy of the header.  The current
existing practice was such a disaster that a lot of work would have to be
done to make the header reliable, and that effort seemed wasted.

We then considered just leaving it alone and not mentioning it at all, but
the disadvantage of that is that without any sort of clear statement,
people assume all sorts of cargo-cult things about the Lines header just
like they do now.  The reason why the current practice is such a mess is
because lots of different software authors have assumed lots of different
things about what the header even means.  So leaving the situation without
any documentation would just continue the confusion, and part of the goal
of standardization is to clean up areas like that.

So we made the decision to formally deprecate it and recommend that people
just stop supporting it.

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