Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!coolidge
From: coolidge@brutus.cs.uiuc.edu (John Coolidge)
Newsgroups: news.software.b
Subject: Xrefs:, and the RFCs (was Re: Supersedes problems...)
Summary: philosophy vs. performance
Message-ID: <1989Sep1.044044.6996@brutus.cs.uiuc.edu>
Date: 1 Sep 89 04:40:44 GMT
References: <5200@looking.on.ca> <1989Aug30.052459.1166@vicom.com> <1989Aug30.204324.2675@paris.ics.uci.edu> <1989Aug30.225332.18770@brutus.cs.uiuc.edu> <1989Aug31.174054.15398@paris.ics.uci.edu> <1989Aug31.234545.23296@brutus.cs.uiuc.edu> <1989Sep1.005346.17308@utst
Sender: news@brutus.cs.uiuc.edu
Reply-To: coolidge@cs.uiuc.edu (John L. Coolidge)
Organization: U of Illinois, CS Dept., Systems Research Group
Lines: 66

geoff@utstat.uucp (Geoff Collyer) writes:
>Everyone who reads a specification must interpret it; the hope is that
>the specificition is clear and error-free.  Otherwise there will be
>different interpretations of it by well-meaning people.

>To avoid transmitting Xref:, the batcher would have to exclude Xref:s
>when forming batches.  It could be done at some cost in CPU cycles.
>I'll ask Henry when he gets back if he wants to do this.

My position philosophically is that a news site should never rewrite
a news article in any way unless such rewriting is clearly allowed under
whatever standards exist. Path: is clearly available for rewriting, as
is Xref: (but Xref: is not supposed to be propagated). No other fields,
it seems to me, are currently available for rewriting under the current
standards (RFCs 1036 and 850).

My position as a site-admin is that performance really matters --- if
C News wasn't so wonderfully high-performance, we wouldn't be able
to handle anywhere near the volume we're now carrying and still have
a machine left. As a by-product of this concern, I think that standards
for news should at least give consideration to performance, and not
mandate behavior that costs performance while giving no tangible
benefits (and the rule about not passing on Xref:s sems a violation of
this principle).

Philosophically, in terms of pure conformance to RFC1036, I don't
think Xref:s should be transmitted. However, if there was ever a 'safe'
header to rewrite and transmit, Xref: is it, since any site using Xref:
should be doing an internal rewrite of Xref:, and since the Xref: line
also includes with inself the name of the host for which it is valid.

Performance-wise, not transmitting Xref: is quite costly, since to be
really honest one SHOULD retransmit any Xref:s that were there when
the article came in originally (remember, the philosophical goal is
no rewriting at all). This really means keeping a pure copy of the
article for use in resending. The cost of doing this would vary
tremendously depending on the type of site involved: pure NNTP sites
running fast sends wouldn't need to cache too many articles, but sites
doing a once-a-day send are in trouble. Of course, if simple RFC1036
compliance is desired, Xref: could be simple deleted when forming
batches, as Geoff indicates. This follows the rule about not retransmitting
it, and 'fixes' the error made by an earlier site in sending it in the
first place.

All in all, I think Xref: is quite possibly a case where the RFC should
be changed to reflect the fact that rewriting it and passing changes on
is a 'safe' thing to do (this includes delete-and-pass-on). Any new
version of the RFC should clearly indicate which fields are strictly
hands-off and which fields it is possible to rewrite locally. IMHO,
any locally rewritable field should be allowed to be transmitted, since
the receiving site can, at its option, 1) rewrite again, 2) delete, or
3) ignore the fields in question.

Is anyone out there seriously working on rewriting the RFC? In view of
the arguments about the inadequacy of RFC1036 (and 850) it seems to me
that there should be a group formed, now, to work on a new, definitive
standard for news. Without it, there's nothing to appeal disputes to,
and both sides can legitimately claim 'victory', since they each decide
for themselves what the playing field is.

--John

--------------------------------------------------------------------------
John L. Coolidge     Internet:coolidge@cs.uiuc.edu   UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed.