Xref: utzoo news.admin:14510 news.software.b:7828 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!mcsun!ukc!slxsys!ibmpcug!mantis!mathew From: mathew@mantis.co.uk (CNEWS MUST DIE!) Newsgroups: news.admin,news.software.b Subject: Re: Really funny jokes being missed Message-ID: Date: 20 May 91 15:03:29 GMT References: <1991May18.211109.20401@zoo.toronto.edu> Organization: Mantis Consultants, Cambridge. UK. Lines: 107 henry@zoo.toronto.edu (Henry Spencer) writes: > In article mathew@mantis.co.uk (CNEWS MUST DIE!) w > >> It is not broken and consequently will not be fixed. > > > >It loses articles unnecessarily, without reporting its delivery failure to > >the originator. > >I call that broken. > > You may call it what you wish. Our experience is that all alternatives are > worse. Why, which have you tried? > The losses, while regrettable, are necessary. Why is it "necessary" to drop articles with the date written as Date: Mon 20 May 91 15:46 GMT instead of Date: Mon, 20 May 91 15:46 GMT then? Enquiring minds want to know. And why is it "necessary" to drop articles with a header line such as Keywords:news,errors or Summary: (blank, with no space after the ':') then? > They are reported > to the local sysadmin, which is the best that can be done safely. If you > want this to be changed, propose a workable, fully thought out alternative > without serious side effects. Outline algorithm for dealing with errors: a. If error can be corrected, correct it. b. If error cannot be corrected and involves the message-ID, drop the article and report failure. c. If error cannot be corrected and does not involved the message-ID, pass on the article. This is an idealized algorithm. In practise, I don't care if you drop all erroneous articles, so long as a failure report gets back to the originating site. Possible algorithms for reporting failure: 1. Mail to originator, or to Errors-To: address if one is specified. If the return address is not mailable, hard luck -- but at least we tried. 2. Mail to administrator of site which produced bad article. If sitename is mangled in return address, hard luck -- but at least we tried. 3. Send a report to a central error-reporting machine (say, UUNET). The central machine merges reports caused by articles with the same message-ID, and sends back a single error report to someone at the guilty site. 4. Propogate failure reports using the news software mechanisms. Alongside "control" and "junk" have an "errors" newsgroup. This at least makes sure that error reports get back to the source site. The message-ID can be generated in a fixed manner from the bad article's message-ID, and so duplicate error reports will be eliminated with virtually no impact on bandwidth. Alternatively, use "control" to report errors. This has the advantage that you don't need to worry about getting existing sites to carry the "errors" newsgroup. > (Hint: you're going to have to put some > serious effort into this, because all the obvious schemes occurred to us > long ago. Well, the above schemes are the ones I can come up with after about five minutes of not-too-painful thinking. I'd call them all "obvious". Number four is my current favourite, and I've not seen any argument which invalidates it. > You needn't bother repeating them, and I'm not going to bother > telling you yet again what's wrong with them.) Sorry? You're saying that: (a) You're not going to tell me what alternatives you've considered, not even by mailing me a file listing them; (b) That you've thought of all the obvious schemes; and (c) That if one of my schemes is obvious, you're not going to bother saying what's wrong with it but just reject it? I hate to inject a note of personal criticism, given that your fan club is already sending me hate mail, but isn't that just a little bit smug and self-satisfied? mathew