coolidge@brutus.cs.uiuc.edu (John Coolidge) (09/01/89)
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.
amanda@intercon.uu.net (Amanda Walker) (09/01/89)
In article <1989Sep1.044044.6996@brutus.cs.uiuc.edu>, coolidge@brutus.cs.uiuc.edu (John Coolidge) writes: > 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). I think, on the other hand, that the fact that Xref "needs" to be treated specially is prime evidence that the article header is the wrong place to put the information, since it is not information about the article itself, but about the article's history on a given system. Of course, I'm something of a radical in that I think that we should throw out the whole idea of "article numbers" and just do everything by message-id, but that will take even more of a complete rewrite than C news... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
coolidge@brutus.cs.uiuc.edu (John Coolidge) (09/02/89)
amanda@intercon.uu.net (Amanda Walker) writes: >In article <1989Sep1.044044.6996@brutus.cs.uiuc.edu>, I write: >> 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). >I think, on the other hand, that the fact that Xref "needs" to be treated >specially is prime evidence that the article header is the wrong place to >put the information, since it is not information about the article itself, >but about the article's history on a given system. I tend to agree here as well. As I think I mentioned somewhere, Xref: is more-or-less a performance hack (to avoid yet another side database). Of course, the history file entry should really be sufficient for this. The major problem with taking Xref: out is that it would break NNTP-based newsreaders --- a new command similar to XDHR which performs a lookup on the history file and returns the entry would probably be required in lieu of Xref: (actually, I think this may be a good idea, since it ties in well with some tentative ideas bouncing around my head about what a good newsreader should do). >Of course, I'm something of a radical in that I think that we should throw >out the whole idea of "article numbers" and just do everything by message-id, >but that will take even more of a complete rewrite than C news... Article numbers are useful if you're using a linearly oriented newsreader such as rn. They're not nearly as useful when using nn, for instance. They do tend to help performance, as it's fairly cheap to grab a couple of numbers and subtract. In addition, it costs a whole lot less to store article numbers in a file for use in determining what a given user has read. But in general I tend to agree that doing things by messageid is the "right" way to do things. I'm just not sure yet if it can be done cheaply enough. -------------------------------------------------------------------------- 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.