From owner-ietf-usefor Tue Aug 31 11:05:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VI5Xrp050890 for ; Tue, 31 Aug 2004 11:05:33 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VI5X8Q050889 for ietf-usefor-skb; Tue, 31 Aug 2004 11:05:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VI5W60050877 for ; Tue, 31 Aug 2004 11:05:32 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 31 Aug 2004 19:11:12 +0100 Message-ID: <4134BDEE.8070502@isode.com> Date: Tue, 31 Aug 2004 19:05:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor@imc.org Subject: Welcome to the UseFor WG mailing list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Welcome to the UseFor WG [new] mailing list. If you are reading this messages, presumably you still care about the outcome of this working group. So I will remind people that they should concentrate on getting the USEFOR document (draft-ietf-usefor-usefor-00.txt) out of the door first. I you haven't reviewed it yet, I advise you to do so ASAP. Charles has submitted USEPRO-00 today, so it should be announced soon. There is some text from draft-ietf-usefor-article-13.txt, which is currently in neither USEFOR-00, nor in USEPRO-00. This should be sorted out later in September, when -01 revisions get published. Alexey From owner-ietf-usefor Tue Aug 31 11:16:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VIGM9E052519 for ; Tue, 31 Aug 2004 11:16:22 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VIGM17052518 for ietf-usefor-skb; Tue, 31 Aug 2004 11:16:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VIGLhh052509 for ; Tue, 31 Aug 2004 11:16:22 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 31 Aug 2004 19:22:00 +0100 Message-ID: <4134C076.2010602@isode.com> Date: Tue, 31 Aug 2004 19:16:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Bill Davidsen CC: ietf-usefor@imc.org Subject: Re: New UseFor headers (was Re: Document definitions) References: <87r7rzmqxq.fsf@windlord.stanford.edu><87r7rzmqxq.fsf@windlord.stanford.edu> <412DE042.8000304@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Davidsen wrote: >>> Complaints-To is arguably useful but isn't fully baked; it's a >>> standardization of an existing header that someone thought was a good >>> idea, but whose effectiveness is a bit dubious. I could, for instance, >>> make a strong argument that its contents should be a URL, not an e-mail >>> address. >> >> >> There was a proposal to merge it with Injection-Info, which is fine >> with me. If this happens, I withdraw my voice in favor of using URLs >> (i.e. I am fine with using the email address syntax for "complain" >> parameter inside the Injection-Info header. >> > > It's quite widely used now, I suggest that we have it written and it's > current practice, there are more contentious things we should settle. If the WG wants to standardize Complaints-To as is, this is fine with me. In which case the description of Complaints-To header can be in the USEFOR document. But the document should be clear that Complaints-To is already deployed and the document doesn't make any attempts to extend or fix (if fixing is required) it. Alexey From owner-ietf-usefor Tue Aug 31 12:40:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VJeJGV068738 for ; Tue, 31 Aug 2004 12:40:19 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7VJeJd7068737 for ietf-usefor-skb; Tue, 31 Aug 2004 12:40:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7VJeIsu068725 for ; Tue, 31 Aug 2004 12:40:18 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 31 Aug 2004 20:45:51 +0100 Message-ID: <4134D41C.9060707@isode.com> Date: Tue, 31 Aug 2004 20:40:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor@imc.org Subject: [Fwd: I-D ACTION:draft-ietf-usefor-usepro-00.txt] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The announcement went to the old mailing list, probably because the UseFor WG page contains wrong email address for the mailing list. I've sent a request to fix that. -------- Original Message -------- Subject: I-D ACTION:draft-ietf-usefor-usepro-00.txt Date: Tue, 31 Aug 2004 15:31:44 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: usenet-format@rkive.landfield.com A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Usenet Article Standard Update Working Group of the IETF. Title : News Article Architecture and Protocols Author(s) : C. Lindsey Filename : draft-ietf-usefor-usepro-00.txt Pages : 47 Date : 2004-8-31 This Draft, together with its companion draft [USEFOR], are intended as standards track documents, together obsoleting RFC 1036, which itself dates from 1987. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-usefor-usepro-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-usefor-usepro-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ietf-usefor Wed Sep 1 08:33:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81FXsxH079645 for ; Wed, 1 Sep 2004 08:33:54 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i81FXscd079644 for ietf-usefor-skb; Wed, 1 Sep 2004 08:33:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i81FXsko079636 for ; Wed, 1 Sep 2004 08:33:54 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: tw3PmruL1cNykIHdzcVzeYxMjsJi23C0w5Rr5lfyA1I= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1C2X7U-0001FB-00; Wed, 01 Sep 2004 11:33:56 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i81FXtr6009483(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Wed, 1 Sep 2004 11:33:55 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i81FXthl009482(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Wed, 1 Sep 2004 11:33:55 -0400 Message-ID: <4135EBE2.5040908@erols.com> Date: Wed, 01 Sep 2004 11:33:54 -0400 From: Bruce Lilly Reply-To: ietf-usefor Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-usefor@imc.org CC: USEFOR Subject: Message fragmentation via message/partial and news-specific header fields X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We had had some discussion about message fragmentation via the MIME media type message/partial,, and there was some text in earlier drafts, however the matter is conspicuously absent from the recently-produced usefor-usepro-00 draft. The rules for message fragmentation and assembly based on standard header fields are discussed in RFC 2046 as amended by RFC 3798. There was some discussion of the matter on the ietf-822 mailing list in June 2003 (q.v.). I also expect some relevant considerations to be reintroduced into ietf-822 mailing list discussion in the near future. There are several implications for message fragmentation and reassembly which appear not to have been adequately considered. I plan to mention several of these implications. First there are some questions that need to be considered: 1. a) Where is message fragmentation expected to occur (e.g. during transport between transfer agents when it is recognized that the receiving agent has some message size limit), and b) by what criteria (presumably some site-dependent size limit, but how is that communicated to that site's feeding agents)? 2. Where does reassembly take place? 3. How is multiple fragmentation to be handled? [e.g. a 1GB original message might be fragmented into 100 MB pieces at some point, which might then be further fragmented into 10 MB pieces, etc. That means that a given article may appear multiple times at various places in the network; unfragmented, and broken into various different-sized pieces -- the original message and the various pieces each having separate, unique message identifiers.) 4. a) During fragmentation, which message header fields are to be copied to the enclosing message header, and which are to be preserved in the enclosed first part message/partial header? b) Which fields need to be copied to the headers of each of the subsequent message fragments? 5. During reassembly, which fields of the first part message header are to be retained, which are to be discarded; likewise for the fields in the header of the enclosed first part? Specifically regarding question 5, I expect that Approved, Newsgroups, Distribution, Path, Followup-To, Expires, Summary, Organization, Injection-Date, Injector-Info, and User-Agent can be safely copied to the header of the first part and at least Approved, Newsgroups, Distribution, Path, Injection-Date, and Expires should be copied to the headers of subsequent parts. Copying these fields to the first part is expected behavior when fragmenting per RFC 2046 as amended by RFC 3798. I believe there may be difficulties with Control, Supersedes, Archive, Posted-And-Mailed, Mail-Copies-To, and possibly Complaints-To. From owner-ietf-usefor Thu Sep 2 01:27:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i828RWGm025754 for ; Thu, 2 Sep 2004 01:27:32 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i828RWrk025753 for ietf-usefor-skb; Thu, 2 Sep 2004 01:27:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i828RWCd025736 for ; Thu, 2 Sep 2004 01:27:32 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id i828RVwg014554 for ; Thu, 2 Sep 2004 01:27:32 -0700 Received: (qmail 3678 invoked by uid 1000); 2 Sep 2004 08:27:31 -0000 To: ietf-usefor Subject: Re: Message fragmentation via message/partial and news-specific header fields In-Reply-To: <4135EBE2.5040908@erols.com> (Bruce Lilly's message of "Wed, 01 Sep 2004 11:33:54 -0400") References: <4135EBE2.5040908@erols.com> From: Russ Allbery Organization: The Eyrie Date: Thu, 02 Sep 2004 01:27:31 -0700 Message-ID: <87ekllaxe4.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bruce Lilly writes: > We had had some discussion about message fragmentation via the MIME > media type message/partial,, and there was some text in earlier drafts, > however the matter is conspicuously absent from the recently-produced > usefor-usepro-00 draft. The rules for message fragmentation and > assembly based on standard header fields are discussed in RFC 2046 as > amended by RFC 3798. There was some discussion of the matter on the > ietf-822 mailing list in June 2003 (q.v.). I also expect some relevant > considerations to be reintroduced into ietf-822 mailing list discussion > in the near future. Is there really any point in talking about this in our drafts? It seems highly unlikely to me that we're going to get the people who fragment Usenet messages to adopt MIME to do so, even if it would be the right thing. There have been extensive discussions in news.software.nntp about this and the outcome was quite clear. Given that, I think this would mostly be an exercise in protocol design for its own sake, and I'm not sure that it's worth spending the time and effort on it given the unlikeliness of widespread use. I'd rather just not mention it and expend our resources on more pressing problems, unless there's some significant need to attack this problem and some reasonable belief that people will adopt a standardized solution in any significant numbers. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Thu Sep 2 09:02:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82G25H3099777 for ; Thu, 2 Sep 2004 09:02:05 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82G25Il099776 for ietf-usefor-skb; Thu, 2 Sep 2004 09:02:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82G25cQ099770 for ; Thu, 2 Sep 2004 09:02:05 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: qJDgAmarAYrwTp4TA94+SE/Is4uY5cPTdEgc3mbND/U= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1C2u2J-0001ZU-00; Thu, 02 Sep 2004 12:02:07 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i82G23CZ030892(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Thu, 2 Sep 2004 12:02:03 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i82G1WiZ030891(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Thu, 2 Sep 2004 12:02:03 -0400 Message-ID: <413743DC.4070301@erols.com> Date: Thu, 02 Sep 2004 12:01:32 -0400 From: Bruce Lilly Reply-To: ietf-usefor Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us MIME-Version: 1.0 To: Russ Allbery CC: ietf-usefor Subject: Re: Message fragmentation via message/partial and news-specific header fields References: <4135EBE2.5040908@erols.com> <87ekllaxe4.fsf@windlord.stanford.edu> In-Reply-To: <87ekllaxe4.fsf@windlord.stanford.edu> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: > Is there really any point in talking about this in our drafts? Yes, for the same reason that the issue was addressed in RFC 3798 (and 2298 before it). > It seems highly unlikely to me that we're going to get the people who > fragment Usenet messages to adopt MIME to do so, even if it would be the > right thing. 1. Message/partial fragmentation has already been used on Usenet. 2. Fragmented messages via message/partial may appear at mail-to-news gateways. 3a. Message/partial is, AFAIK, the only standardized method for message fragmentation and reassembly. And since it is part of MIME, it is widely applicable (e.g. to HTTP as well as Internet Message Format). 3b. If there is some other method of fragmentation/reassembly, the same sort of issues need to be discussed > There have been extensive discussions in news.software.nntp > about this and the outcome was quite clear. Clear to whom and from what perspective? Since the discussion didn't take place here, can you summarize the discussion or point to an archived summary? From owner-ietf-usefor Thu Sep 2 10:54:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HsIFu010232 for ; Thu, 2 Sep 2004 10:54:18 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82HsILZ010231 for ietf-usefor-skb; Thu, 2 Sep 2004 10:54:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82HsIMk010225 for ; Thu, 2 Sep 2004 10:54:18 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id i82HsLEk026572 for ; Thu, 2 Sep 2004 10:54:21 -0700 Received: (qmail 17508 invoked by uid 1000); 2 Sep 2004 17:54:20 -0000 To: ietf-usefor Subject: Re: Message fragmentation via message/partial and news-specific header fields In-Reply-To: <413743DC.4070301@erols.com> (Bruce Lilly's message of "Thu, 02 Sep 2004 12:01:32 -0400") References: <4135EBE2.5040908@erols.com> <87ekllaxe4.fsf@windlord.stanford.edu> <413743DC.4070301@erols.com> From: Russ Allbery Organization: The Eyrie Date: Thu, 02 Sep 2004 10:54:20 -0700 Message-ID: <87eklkimk3.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bruce Lilly writes: > Russ Allbery wrote: >> Is there really any point in talking about this in our drafts? > Yes, for the same reason that the issue was addressed in RFC 3798 (and > 2298 before it). What was that reason? I'm not familiar with either of those RFCs. > 1. Message/partial fragmentation has already been used on Usenet. > 2. Fragmented messages via message/partial may appear at mail-to-news > gateways. > 3a. Message/partial is, AFAIK, the only standardized method for > message fragmentation and reassembly. And since it is part of > MIME, it is widely applicable (e.g. to HTTP as well as Internet > Message Format). > 3b. If there is some other method of fragmentation/reassembly, the same > sort of issues need to be discussed This is all nice and good and my point is that message fragmentation is something that's only useful on Usenet for binary messages and 99.99% of the binary posters are never going to use it based on the *extensive* discussions that have been had with the authors of that software and with news administrators on news.software.nntp. So while this might be useful to someone, it is an extreme edge case and one with which we have little to no implementation experience, which makes me doubt in the extreme that this working group is going to be able to do an adequate job of handling the problem. >> There have been extensive discussions in news.software.nntp about this >> and the outcome was quite clear. > Clear to whom and from what perspective? Since the discussion didn't > take place here, can you summarize the discussion or point to an > archived summary? As mentioned above, the outcome of the discussion was a complete and utter lack of interest in anything MIME-related for message fragmentation, despite several of us pushing it pretty hard. What is being used is not something that we can or should standardize. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Thu Sep 2 11:30:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82IUZjW014071 for ; Thu, 2 Sep 2004 11:30:35 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i82IUZfJ014070 for ietf-usefor-skb; Thu, 2 Sep 2004 11:30:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from gatekeeper.tmr.com (mail.tmr.com [216.238.38.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i82IUXd7014064 for ; Thu, 2 Sep 2004 11:30:34 -0700 (PDT) (envelope-from news@gatekeeper.tmr.com) Received: (from news@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) id OAA24440; Thu, 2 Sep 2004 14:23:57 -0400 To: usenet-format@landfield.com, ietf-usefor@imc.org Path: not-for-mail From: Bill Davidsen Newsgroups: mail.usenet-format Subject: Re: Message fragmentation via message/partial and news-specific header fields Date: Thu, 02 Sep 2004 14:30:36 -0400 Organization: TMR Associates, Inc Lines: 64 Message-ID: References: <413743DC.4070301@erols.com><4135EBE2.5040908@erols.com> <87eklkimk3.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gatekeeper.tmr.com 1094149437 24405 192.168.12.100 (2 Sep 2004 18:23:57 GMT) X-Complaints-To: abuse@tmr.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en In-Reply-To: <87eklkimk3.fsf@windlord.stanford.edu> Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: > Bruce Lilly writes: > >>Russ Allbery wrote: > > >>>Is there really any point in talking about this in our drafts? > > >>Yes, for the same reason that the issue was addressed in RFC 3798 (and >>2298 before it). > > > What was that reason? I'm not familiar with either of those RFCs. > > >>1. Message/partial fragmentation has already been used on Usenet. >>2. Fragmented messages via message/partial may appear at mail-to-news >> gateways. >>3a. Message/partial is, AFAIK, the only standardized method for >> message fragmentation and reassembly. And since it is part of >> MIME, it is widely applicable (e.g. to HTTP as well as Internet >> Message Format). >>3b. If there is some other method of fragmentation/reassembly, the same >> sort of issues need to be discussed > > > This is all nice and good and my point is that message fragmentation is > something that's only useful on Usenet for binary messages and 99.99% of > the binary posters are never going to use it based on the *extensive* > discussions that have been had with the authors of that software and with > news administrators on news.software.nntp. > > So while this might be useful to someone, it is an extreme edge case and > one with which we have little to no implementation experience, which makes > me doubt in the extreme that this working group is going to be able to do > an adequate job of handling the problem. > > >>>There have been extensive discussions in news.software.nntp about this >>>and the outcome was quite clear. > > >>Clear to whom and from what perspective? Since the discussion didn't >>take place here, can you summarize the discussion or point to an >>archived summary? > > > As mentioned above, the outcome of the discussion was a complete and utter > lack of interest in anything MIME-related for message fragmentation, > despite several of us pushing it pretty hard. What is being used is not > something that we can or should standardize. > Hell, yENC is even standardized in practice, about 20% of all postings I am asked to exampne for inappropriate content defy any decode to which I have access. If there's one for UNIXen which will handle these posts, which don't follow the "standard" at yenc.org, I haven't found it. People will do what they choose, and to date they choose hacks. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From owner-ietf-usefor Fri Sep 3 10:39:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83HdeBp041532 for ; Fri, 3 Sep 2004 10:39:40 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83HdeYc041531 for ietf-usefor-skb; Fri, 3 Sep 2004 10:39:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83Hddn9041525 for ; Fri, 3 Sep 2004 10:39:40 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: Jb3DvTykdqyn6LtPa5jBAJrIkmfRGXOVT5JslxeYFL4= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1C3I2I-0003mU-00; Fri, 03 Sep 2004 13:39:43 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i82IjAf2032445(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Thu, 2 Sep 2004 14:45:35 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i82Iinn2032419(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Thu, 2 Sep 2004 14:45:04 -0400 Message-ID: <41376A21.5070904@erols.com> Date: Thu, 02 Sep 2004 14:44:49 -0400 From: Bruce Lilly Reply-To: blilly@erols.com Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us MIME-Version: 1.0 To: Russ Allbery CC: ietf-usefor Subject: Re: Message fragmentation via message/partial and news-specific header fields References: <4135EBE2.5040908@erols.com> <87ekllaxe4.fsf@windlord.stanford.edu> <413743DC.4070301@erols.com> <87eklkimk3.fsf@windlord.stanford.edu> In-Reply-To: <87eklkimk3.fsf@windlord.stanford.edu> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: > Bruce Lilly writes: > >>Russ Allbery wrote: > > >>>Is there really any point in talking about this in our drafts? > > >>Yes, for the same reason that the issue was addressed in RFC 3798 (and >>2298 before it). > > > What was that reason? I'm not familiar with either of those RFCs. Briefly (this was discussed on ietf-822 in June 2003) the DSN RFC introduced header fields which need to be treated similarly to Message-ID w.r.t. first part message header and enclosed message header for fragmentation and reassembly. Several of the news- specific fields will also need to be treated differently than what is the case per RFC 2046 rules in lieu of any amendments to those rules. To take one particular example, the Control field par RFC 2046 rules would have to be copied to the first part message header in order to survive fragmentation/reassembly (only specific fields in the enclosed message header from the original message header which is encapsulated in the first part are copied during reassembly). That means that that first part will be interpreted as if it were a (complete) control message. If RFC 2046 rules were to be amended (as they were for DSN-specific fields by RFCs 2298/3798) then the Control field could remain encapsulated within the first part, not copied to the first part message header, the partial messages would not be treated as control messages (only the reassembled whole would be treated as such). > This is all nice and good and my point is that message fragmentation is > something that's only useful on Usenet for binary messages No, it's useful for any message whose size exceeds some threshold, including large text documents (such as, oh, maybe draft-ietf-usefor-article-13.txt for example). > and 99.99% of > the binary posters are never going to use it If the functionality is built into UAs and/or injection agents and/or transport agents is can be transparent to the users. Especially bearing in mind the fact of common mail/news UAs not to mention web browser/messaging UAs -- MIME message/partial applies to mail, news, and HTTP, so support for message/partial by any one component of such common-use UAs becomes available to the others; provided the news-specific issues are properly addressed. > based on the *extensive* > discussions that have been had with the authors of that software and with > news administrators on news.software.nntp. Exactly which "that software" are you talking about -- some NNTP implementation? > So while this might be useful to someone, it is an extreme edge case and > one with which we have little to no implementation experience, which makes > me doubt in the extreme that this working group is going to be able to do > an adequate job of handling the problem. This group is likely the only group which can determine how its news-specific header fields should be handled during fragmentation and reassembly. >>Clear to whom and from what perspective? Since the discussion didn't >>take place here, can you summarize the discussion or point to an >>archived summary? > > > As mentioned above, the outcome of the discussion was a complete and utter > lack of interest in anything MIME-related for message fragmentation, > despite several of us pushing it pretty hard. If the discussion was only in a narrow special-interest area for NNTP software, it likely missed UA authors as well as implementors of transport methods other than NNTP. > What is being used is not > something that we can or should standardize. Then we should stick to the implications for message/partial. From owner-ietf-usefor Fri Sep 3 11:11:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IBkSt044089 for ; Fri, 3 Sep 2004 11:11:46 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i83IBkCK044088 for ietf-usefor-skb; Fri, 3 Sep 2004 11:11:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i83IBkRg044082 for ; Fri, 3 Sep 2004 11:11:46 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i83IBkLR032488 for ; Fri, 3 Sep 2004 11:11:47 -0700 Received: (qmail 17596 invoked by uid 1000); 3 Sep 2004 18:11:46 -0000 To: ietf-usefor Subject: Re: Message fragmentation via message/partial and news-specific header fields In-Reply-To: <41376A21.5070904@erols.com> (Bruce Lilly's message of "Thu, 02 Sep 2004 14:44:49 -0400") References: <4135EBE2.5040908@erols.com> <87ekllaxe4.fsf@windlord.stanford.edu> <413743DC.4070301@erols.com> <87eklkimk3.fsf@windlord.stanford.edu> <41376A21.5070904@erols.com> From: Russ Allbery Organization: The Eyrie Date: Fri, 03 Sep 2004 11:11:46 -0700 Message-ID: <87oekn6x3x.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bruce Lilly writes: > Briefly (this was discussed on ietf-822 in June 2003) the DSN RFC > introduced header fields which need to be treated similarly to > Message-ID w.r.t. first part message header and enclosed message header > for fragmentation and reassembly. Several of the news-specific fields > will also need to be treated differently than what is the case per RFC > 2046 rules in lieu of any amendments to those rules. To take one > particular example, the Control field par RFC 2046 rules would have to > be copied to the first part message header in order to survive > fragmentation/reassembly (only specific fields in the enclosed message > header from the original message header which is encapsulated in the > first part are copied during reassembly). That means that that first > part will be interpreted as if it were a (complete) control message. If > RFC 2046 rules were to be amended (as they were for DSN-specific fields > by RFCs 2298/3798) then the Control field could remain encapsulated > within the first part, not copied to the first part message header, the > partial messages would not be treated as control messages (only the > reassembled whole would be treated as such). Ah, I see. Yes, that makes sense. I don't personally find work on message/partial important enough to spend time on it, but if you come up with language to deal with these issues, I'd be willing to review it and say whether I think it makes sense. > No, it's useful for any message whose size exceeds some threshold, > including large text documents (such as, oh, maybe > draft-ietf-usefor-article-13.txt for example). Splitting text messages that small is obnoxious and anti-social and is something that I'd filter out on my news server. General consensus in news.software.nntp among news administrators (this came up as well) pretty much matched that feeling. Nothing smaller than 1MB should be split on Usenet, and preferrably as far as I'm concerned nothing smaller than 10MB (although 1MB is the more common metric). >> and 99.99% of the binary posters are never going to use it > If the functionality is built into UAs and/or injection agents and/or > transport agents is can be transparent to the users. Yes, I know. The authors of the many different software packages used in binary newsgroups, which is by and large the only place that news administrators want to ever see fragmented posts, are uninterested in implementing it. This was literally a two year long discussion, involving a much larger number of people than have ever participated in this working group. You can see the conclusion in effect on Usenet right now, namely widespread implementation of yEnc. >> based on the *extensive* discussions that have been had with the >> authors of that software and with news administrators on >> news.software.nntp. > Exactly which "that software" are you talking about -- some NNTP > implementation? No, software used in binary newsgroups (for posting, serving, and reading). > If the discussion was only in a narrow special-interest area for NNTP > software, it likely missed UA authors as well as implementors of > transport methods other than NNTP. Quite possibly. It won't make any difference, but hey, until I actually took part in the two year long discussion, I didn't believe it either. You can trust me or you can tilt at the windmill, your choice. Given how long I spent tilting at the windmill, I'm certainly not going to begrudge anyone else the opportunity. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Mon Sep 13 06:09:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8DD9mSR020876 for ; Mon, 13 Sep 2004 06:09:48 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8DD9mZu020875 for ietf-usefor-skb; Mon, 13 Sep 2004 06:09:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp808.mail.ukl.yahoo.com (smtp808.mail.ukl.yahoo.com [217.12.12.198]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8DD9i1q020827 for ; Mon, 13 Sep 2004 06:09:47 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-66-246.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.66.246 with poptime) by smtp808.mail.ukl.yahoo.com with SMTP; 13 Sep 2004 13:09:31 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8DD8io19091; Mon, 13 Sep 2004 14:08:44 +0100 (BST) To: usenet-format@landfield.com, ietf-usefor@imc.org Xref: clerew local.usefor:20137 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: The great mailing list muddle Message-ID: X-Newsreader: NN version 6.5.2 (NOV) Date: Mon, 13 Sep 2004 12:57:36 GMT Lines: 50 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If seems that our Chair has switched to the new mailing list without at the same time posting a warning message to the old list for the benefit of those who had omitted, or more likely who had tried and failed, to subscribe to the new. So here is a heads up that the submission address for the Usefor Working Group list is now ietf-usefor@imc.org and requests to subscribe should be sent to ietf-usefor-request@imc.org with the single word 'subscribe' in the body of the message. Well, actually, it is a majordomo system, so the usual majordomo commands will work. But, if you try to do anything fancy, like having a different subscription address (such as a gateway to a local mailing list) but still want to post as from your usual mail address, then you will get a reply like Your request to majordomo@vpnc.org: subscribe ietf-usefor local.usefor@clerew.man.ac.uk has been forwarded to the owner of the "ietf-usefor" list for approval. and after that, you will hear nothing even if, as I did, you ask our Chair to ensure that your subscription is processed promptly and he assures you that he has done so. Sadly, this seems to be a common situation with mailing lists hosted at imc.org. So now we have the ridiculous situation of a Working Group whose Editor is not on the mailing list. And our Chair has gone on holiday until September 21st. For the moment, I am sending messages to both lists, and I suggest that others do the same. And on top of all that, as you may have observed, the automatic archiving process at landfield.com stopped working on August 13th. I phoned Kent as soon as I noticed it and he promised to fix it, but evidently did not do so. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Tue Sep 14 03:54:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EAswHb055079 for ; Tue, 14 Sep 2004 03:54:58 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EAswnO055078 for ietf-usefor-skb; Tue, 14 Sep 2004 03:54:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from gatekeeper.tmr.com (mail.tmr.com [216.238.38.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EAsvW8055071 for ; Tue, 14 Sep 2004 03:54:57 -0700 (PDT) (envelope-from news@gatekeeper.tmr.com) Received: (from news@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) id GAA02372; Tue, 14 Sep 2004 06:48:00 -0400 To: usenet-format@landfield.com, ietf-usefor@imc.org Path: not-for-mail From: Bill Davidsen Newsgroups: mail.usenet-format Subject: Re: The great mailing list muddle Date: Tue, 14 Sep 2004 07:00:19 -0400 Organization: TMR Associates, Inc Lines: 55 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gatekeeper.tmr.com 1095158879 2371 192.168.12.10 (14 Sep 2004 10:47:59 GMT) X-Complaints-To: abuse@tmr.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en In-Reply-To: Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the heads-up, it explains why I no longer get any mail for this list. I've sent the subscribe several times, and even gotten ack the first time IIRC, but clearly the new list is more bozo'd than the old. Pity it couldn't have been moved to somewhere competent, like lists.debian.org or such. Nice to know this has become a closed list, rather than dead. Charles Lindsey wrote: > If seems that our Chair has switched to the new mailing list without at > the same time posting a warning message to the old list for the benefit of > those who had omitted, or more likely who had tried and failed, to > subscribe to the new. > > So here is a heads up that the submission address for the Usefor Working > Group list is now ietf-usefor@imc.org and requests to subscribe should be > sent to ietf-usefor-request@imc.org with the single word 'subscribe' in > the body of the message. Well, actually, it is a majordomo system, so the > usual majordomo commands will work. > > But, if you try to do anything fancy, like having a different subscription > address (such as a gateway to a local mailing list) but still want to post > as from your usual mail address, then you will get a reply like > > Your request to majordomo@vpnc.org: > > subscribe ietf-usefor local.usefor@clerew.man.ac.uk > > has been forwarded to the owner of the "ietf-usefor" list for approval. > > and after that, you will hear nothing even if, as I did, you ask our Chair > to ensure that your subscription is processed promptly and he assures you > that he has done so. > > Sadly, this seems to be a common situation with mailing lists hosted at > imc.org. > > So now we have the ridiculous situation of a Working Group whose Editor is > not on the mailing list. And our Chair has gone on holiday until September > 21st. > > For the moment, I am sending messages to both lists, and I suggest that > others do the same. > > And on top of all that, as you may have observed, the automatic archiving > process at landfield.com stopped working on August 13th. I phoned Kent as > soon as I noticed it and he promised to fix it, but evidently did not do > so. > -- bill davidsen CTO TMR Associates, Inc Doing interesting things with small computers since 1979 From owner-ietf-usefor Tue Sep 14 09:12:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EGCb1k089866 for ; Tue, 14 Sep 2004 09:12:37 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EGCb5n089865 for ietf-usefor-skb; Tue, 14 Sep 2004 09:12:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp804.mail.ukl.yahoo.com (smtp804.mail.ukl.yahoo.com [217.12.12.141]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8EGCaLo089856 for ; Tue, 14 Sep 2004 09:12:36 -0700 (PDT) (envelope-from chl@clerew.man.ac.uk) Received: from unknown (HELO host62-172-30-7.midband.mdip.bt.net) (ietf-usefor@imc.org@62.172.30.7 with poptime) by smtp804.mail.ukl.yahoo.com with SMTP; 14 Sep 2004 16:12:32 -0000 Received: (from chl@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8EDMW327625; Tue, 14 Sep 2004 14:22:32 +0100 (BST) Date: Tue, 14 Sep 2004 14:22:32 +0100 (BST) From: Charles Lindsey Message-Id: <200409141322.i8EDMW327625@clerew.man.ac.uk> To: ietf-usefor@imc.org Subject: Message fragmentation via message/partial and news-specific header fields X-Newsreader: NN version 6.5.2 (NOV) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message, posted to the old list, is now reposted to the new list for the benefit of anyone no longer reading the old one. >From: "Charles Lindsey" >Subject: Re: Message fragmentation via message/partial and news-specific header fields >Message-ID: >X-Newsreader: NN version 6.5.2 (NOV) >References: <4135EBE2.5040908@erols.com> >Date: Thu, 2 Sep 2004 16:05:18 GMT In <4135EBE2.5040908@erols.com> Bruce Lilly writes: >We had had some discussion about message fragmentation via the MIME media type >message/partial,, and there was some text in earlier drafts, however the >matter is conspicuously absent from the recently-produced usefor-usepro-00 >draft. I think it is a matter for usefor rather than usepro, and yes it needs some mention there. >First there are some questions that need to be considered: >1. a) Where is message fragmentation expected to occur (e.g. during transport > between transfer agents when it is recognized that the receiving agent > has some message size limit), and b) by what criteria (presumably some > site-dependent size limit, but how is that communicated to that site's > feeding agents)? At the injecting agent, at the latest. >2. Where does reassembly take place? At each recipients reading agent, or later (i.e. he manually feeds it into a reassembly program, since many reading agents are unlikely to provide the facility). >3. How is multiple fragmentation to be handled? [e.g. a 1GB original > message might be fragmented into 100 MB pieces at some point, which > might then be further fragmented into 10 MB pieces, etc. That means > that a given article may appear multiple times at various places in > the network; unfragmented, and broken into various different-sized > pieces -- the original message and the various pieces each having > separate, unique message identifiers.) It MUST NOT happen. Relaying agents MUST NOT modify articles in this manner as they pass through them. Either they pass them unchanged, or they drop them on the floor (and it it floods around via some slower path, then well and good). But it is a fundamental principle of Usenet that all copies of a particular article are supposed to be identical, apart from variant headers (though if different copies have passed via different gateways, that might not be possible). As far as transport and serving within Usenet is concerned, each part is a distinct article with its own distinct msg-id. >4. a) During fragmentation, which message header fields are to be copied > to the enclosing message header, and which are to be preserved in > the enclosed first part message/partial header? b) Which fields > need to be copied to the headers of each of the subsequent message > fragments? >5. During reassembly, which fields of the first part message header > are to be retained, which are to be discarded; likewise for the > fields in the header of the enclosed first part? >Specifically regarding question 5, I expect that Approved, Newsgroups, >Distribution, Path, Followup-To, Expires, Summary, Organization, >Injection-Date, Injector-Info, and User-Agent can be safely copied to >the header of the first part and at least Approved, Newsgroups, >Distribution, Path, Injection-Date, and Expires should be copied to >the headers of subsequent parts. Copying these fields to the first >part is expected behavior when fragmenting per RFC 2046 as amended by >RFC 3798. I believe there may be difficulties with Control, >Supersedes, Archive, Posted-And-Mailed, Mail-Copies-To, and possibly >Complaints-To. No, you certainly don't copy Path. It grows as the various parts propagate through the network, and different parts may arrive at a given host via different routes. OTOH, any pre-injection portion of the Path, including the tail entry, present before the split might well be retained in the Paths of all the parts. Likewise, Injection-Date and Injection-Info could well be different for the various parts, depending on where the splitting was done. The rest of your suggestions seem about right. Incidentally, what happens with Received headers in email? Presumably the final reassembled message sees the Received headers from the first part, and all the rest of them get lost. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Tue Sep 14 11:03:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EI3RmR001213 for ; Tue, 14 Sep 2004 11:03:27 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8EI3RF3001212 for ietf-usefor-skb; Tue, 14 Sep 2004 11:03:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8EI3Qbv001206 for ; Tue, 14 Sep 2004 11:03:26 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8EI3TxP020099 for ; Tue, 14 Sep 2004 11:03:29 -0700 Received: (qmail 3932 invoked by uid 1000); 14 Sep 2004 18:03:29 -0000 To: ietf-usefor@imc.org Subject: Re: Message fragmentation via message/partial and news-specific header fields In-Reply-To: <200409141322.i8EDMW327625@clerew.man.ac.uk> (Charles Lindsey's message of "Tue, 14 Sep 2004 14:22:32 +0100 (BST)") References: <200409141322.i8EDMW327625@clerew.man.ac.uk> From: Russ Allbery Organization: The Eyrie Date: Tue, 14 Sep 2004 11:03:29 -0700 Message-ID: <871xh4k9se.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > This message, posted to the old list, is now reposted to the new list > for the benefit of anyone no longer reading the old one. This is the first time I've seen this message, so either the old list is no longer working or I've been silently unsubscribed from it for some reason. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Sep 14 19:12:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8F2CTxg037847 for ; Tue, 14 Sep 2004 19:12:29 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8F2CTRg037846 for ietf-usefor-skb; Tue, 14 Sep 2004 19:12:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp807.mail.ukl.yahoo.com (smtp807.mail.ukl.yahoo.com [217.12.12.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8F2CRr9037829 for ; Tue, 14 Sep 2004 19:12:28 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-64-249.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.64.249 with poptime) by smtp807.mail.ukl.yahoo.com with SMTP; 15 Sep 2004 02:12:28 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8EGCaO28940; Tue, 14 Sep 2004 17:12:36 +0100 (BST) To: usenet-format@landfield.com, ietf-usefor@imc.org Xref: clerew local.usefor:20146 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Message fragmentation via message/partial and news-specific header fields Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4135EBE2.5040908@erols.com> <87ekllaxe4.fsf@windlord.stanford.edu> <413743DC.4070301@erols.com> <87eklkimk3.fsf@windlord.stanford.edu> <41376A21.5070904@erols.com> <87oekn6x3x.fsf@windlord.stanford.edu> Date: Tue, 14 Sep 2004 13:41:32 GMT Lines: 75 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <87oekn6x3x.fsf@windlord.stanford.edu> Russ Allbery writes: >Bruce Lilly writes: >> Briefly (this was discussed on ietf-822 in June 2003) the DSN RFC >> introduced header fields which need to be treated similarly to >> Message-ID w.r.t. first part message header and enclosed message header >> for fragmentation and reassembly. Several of the news-specific fields >> will also need to be treated differently than what is the case per RFC >> 2046 rules in lieu of any amendments to those rules. To take one >> particular example, the Control field par RFC 2046 rules would have to >> be copied to the first part message header in order to survive >> fragmentation/reassembly (only specific fields in the enclosed message >> header from the original message header which is encapsulated in the >> first part are copied during reassembly). That means that that first >> part will be interpreted as if it were a (complete) control message. If >> RFC 2046 rules were to be amended (as they were for DSN-specific fields >> by RFCs 2298/3798) then the Control field could remain encapsulated >> within the first part, not copied to the first part message header, the >> partial messages would not be treated as control messages (only the >> reassembled whole would be treated as such). >Ah, I see. Yes, that makes sense. I don't personally find work on >message/partial important enough to spend time on it, but if you come up >with language to deal with these issues, I'd be willing to review it and >say whether I think it makes sense. Well it would be stupid to split a control message using message/partial, but in the event that it did happen, it would be better to have the Control-header in the first part (I don't care whether it is also included in the encapsulated article, though it would be illogical not to do so). The point is that most agents receiving the message, and particularly serving agents which are the ones that would implement any control action, are most unlikely to possess the capability of reassembling the various parts, or even to have any concept of message/partial at all. Therefore it is essential that they see the first part as an ordinary control message and act upon it accordingly. The subsequent parts would then appear in the relevant groups as ordinary articles, which might be confusing but would not be likely to do any harm. In the event that some serving agent did have reassembly capability, then either 1) It would notice the Control-header first and act upon it. It should then be smart enough not to bother with reassembly or, if it did reassemble, to know that it had already done the Control stuff. But even if it tried to act upon the Control message twice, that would not actually cause any harm. Or: 2) It would notice the Content-Type: message partial first, in which case it would then reassemble the message and insert it back into the system, in which case it would be acted upon as a control message. >Splitting text messages that small is obnoxious and anti-social and is >something that I'd filter out on my news server. General consensus in >news.software.nntp among news administrators (this came up as well) pretty >much matched that feeling. Nothing smaller than 1MB should be split on >Usenet, and preferrably as far as I'm concerned nothing smaller than 10MB >(although 1MB is the more common metric). And indeed there is a NOTE in draft-13 which makes that point. I don't think it has found its way into the new drafts yet, but it should. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Sep 15 12:58:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJwOdZ037237 for ; Wed, 15 Sep 2004 12:58:24 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8FJwOpg037236 for ietf-usefor-skb; Wed, 15 Sep 2004 12:58:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8FJwNNC037230 for ; Wed, 15 Sep 2004 12:58:23 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04399; Wed, 15 Sep 2004 15:58:24 -0400 (EDT) Message-Id: <200409151958.PAA04399@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-usefor@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-usefor-usefor-01.txt Date: Wed, 15 Sep 2004 15:58:24 -0400 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Usenet Article Standard Update Working Group of the IETF. Title : News Article Format Author(s) : C. Lindsey Filename : draft-ietf-usefor-usefor-01.txt Pages : 24 Date : 2004-9-15 This document specifies the syntax of network news articles in the context of the "Internet Message Format" (RFC 2822) and "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This document supersedes RFC 1036, updating it to reflect current practice and incorporating incremental changes specified in other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-usefor-usefor-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-usefor-usefor-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-15154507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-usefor-usefor-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-usefor-usefor-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-15154507.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-usefor Wed Sep 15 20:12:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G3Cb9H080560 for ; Wed, 15 Sep 2004 20:12:37 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G3CbpE080559 for ietf-usefor-skb; Wed, 15 Sep 2004 20:12:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp800.mail.ukl.yahoo.com (smtp800.mail.ukl.yahoo.com [217.12.12.142]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8G3Ca8U080544 for ; Wed, 15 Sep 2004 20:12:36 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-77-138.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.77.138 with poptime) by smtp800.mail.ukl.yahoo.com with SMTP; 16 Sep 2004 03:12:23 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8FGCDg06546; Wed, 15 Sep 2004 17:12:13 +0100 (BST) To: usenet-format@landfield.com, ietf-usefor@imc.org Xref: clerew local.usefor:20150 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: The great mailing list muddle Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: Date: Wed, 15 Sep 2004 14:24:42 GMT Lines: 27 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Bill Davidsen writes: >Thanks for the heads-up, it explains why I no longer get any mail for >this list. I've sent the subscribe several times, and even gotten ack >the first time IIRC, but clearly the new list is more bozo'd than the >old. Pity it couldn't have been moved to somewhere competent, like >lists.debian.org or such. >Nice to know this has become a closed list, rather than dead. Well I am now cleanly on the new list, but it took a direct appeal to Paul Hoffman to fix it. He apoloigised that my previous request had "somehow got lost" and subscribed me by hand. I think we had better continue to post articles to both lists for a while longer. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Sep 15 23:25:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G6PVVD025169 for ; Wed, 15 Sep 2004 23:25:31 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8G6PVt9025168 for ietf-usefor-skb; Wed, 15 Sep 2004 23:25:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8G6PTWo025148 for ; Wed, 15 Sep 2004 23:25:30 -0700 (PDT) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C7phw-0006Oo-00 for ; Thu, 16 Sep 2004 08:25:28 +0200 Received: from du-001-249.access.de.clara.net ([212.82.227.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2004 08:25:28 +0200 Received: from nobody by du-001-249.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2004 08:25:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: I-D ACTION:draft-ietf-usefor-usefor-01.txt Date: Thu, 16 Sep 2004 08:24:51 +0200 Organization: Lines: 15 Message-ID: <414931B3.729E@xyzzy.claranet.de> References: <200409151958.PAA04399@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-249.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Internet-Drafts@ietf.org wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-01.txt | When an article is posted to more than one newsgroup, it is | said to be "crossposted"; note that this differs from posting | the same text as part of each of several articles, one per | newsgroup. Should we say [...] "articles with different Message-Ids" here, instead of "one per newsgroup" ? Bye, Frank (testing the write access via gmane) From owner-ietf-usefor Thu Sep 16 06:36:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GDahMA036980 for ; Thu, 16 Sep 2004 06:36:43 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GDahh5036979 for ietf-usefor-skb; Thu, 16 Sep 2004 06:36:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from oddball.prodigy.com (prgy-npn1.prodigy.com [207.115.54.37]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GDagDA036970 for ; Thu, 16 Sep 2004 06:36:42 -0700 (PDT) (envelope-from davidsen@tmr.com) Received: from [127.0.0.1] (oddball.prodigy.com [127.0.0.1]) by oddball.prodigy.com (8.11.6/8.11.6) with ESMTP id i8GDamG20566; Thu, 16 Sep 2004 09:36:59 -0400 Message-ID: <414996EF.3020105@tmr.com> Date: Thu, 16 Sep 2004 09:36:47 -0400 From: Bill Davidsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Lindsey CC: usenet-format@landfield.com, ietf-usefor@imc.org Subject: Re: The great mailing list muddle References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: > In Bill Davidsen writes: > > >>Thanks for the heads-up, it explains why I no longer get any mail for >>this list. I've sent the subscribe several times, and even gotten ack >>the first time IIRC, but clearly the new list is more bozo'd than the >>old. Pity it couldn't have been moved to somewhere competent, like >>lists.debian.org or such. > > >>Nice to know this has become a closed list, rather than dead. > > > Well I am now cleanly on the new list, but it took a direct appeal to Paul > Hoffman to fix it. He apoloigised that my previous request had "somehow > got lost" and subscribed me by hand. > > I think we had better continue to post articles to both lists for a while > longer. > That probably explains why your posts are the only ones I am getting any more. I tried again to subscribe, but it told me I was already subscribed. If that's true you are the only one posting, which I doubt. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From owner-ietf-usefor Thu Sep 16 22:28:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H5SDLi022967 for ; Thu, 16 Sep 2004 22:28:13 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8H5SDgC022966 for ietf-usefor-skb; Thu, 16 Sep 2004 22:28:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8H5SBwo022941 for ; Thu, 16 Sep 2004 22:28:11 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8H5RwcC024099; Fri, 17 Sep 2004 01:27:58 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8H5RwUC024098; Fri, 17 Sep 2004 01:27:58 -0400 (EDT) Date: Fri, 17 Sep 2004 01:27:58 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List cc: Usefor Mailing List Subject: Re: I-D ACTION:draft-ietf-usefor-usefor-01.txt In-Reply-To: <414931B3.729E@xyzzy.claranet.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 16 Sep 2004, Frank Ellermann wrote: > | When an article is posted to more than one newsgroup, it is > | said to be "crossposted"; note that this differs from posting > | the same text as part of each of several articles, one per > | newsgroup. > > Should we say [...] "articles with different Message-Ids" here, > instead of "one per newsgroup" ? I think "per newsgroup" is the important issue here and shouldn't be omitted. Henry Spencer henry@spsystems.net From owner-ietf-usefor Fri Sep 17 19:12:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8I2Cagt027657 for ; Fri, 17 Sep 2004 19:12:36 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8I2CaLu027656 for ietf-usefor-skb; Fri, 17 Sep 2004 19:12:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp803.mail.ukl.yahoo.com (smtp803.mail.ukl.yahoo.com [217.12.12.140]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8I2CZka027639 for ; Fri, 17 Sep 2004 19:12:35 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-78-167.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.78.167 with poptime) by smtp803.mail.ukl.yahoo.com with SMTP; 18 Sep 2004 02:12:26 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8HGCOW24659; Fri, 17 Sep 2004 17:12:24 +0100 (BST) To: usenet-format@landfield.com, ietf-usefor@imc.org Xref: clerew local.usefor:20154 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: The great mailing list muddle Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <414996EF.3020105@tmr.com> Date: Fri, 17 Sep 2004 13:34:47 GMT Lines: 29 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <414996EF.3020105@tmr.com> Bill Davidsen writes: >Charles Lindsey wrote: >> >That probably explains why your posts are the only ones I am getting any >more. I tried again to subscribe, but it told me I was already >subscribed. If that's true you are the only one posting, which I doubt. Paul Hoffman tells me that anyone still having problems may contact him at Paul Hoffman / IMC . It seems that he has a lot of spam to wade through and sometimes he misses some messages relating to management of his lists. Is anyone other than Bill still having problems? If so, please report here (on either list, since I still read and post to both). I hope shortly to be transferring all the documents and old list archives to the new site, since Paul has given me ftp access. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Tue Sep 21 09:12:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LGCW2a046116 for ; Tue, 21 Sep 2004 09:12:32 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LGCWnn046115 for ietf-usefor-skb; Tue, 21 Sep 2004 09:12:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp806.mail.ukl.yahoo.com (smtp806.mail.ukl.yahoo.com [217.12.12.196]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8LGCVd7046095 for ; Tue, 21 Sep 2004 09:12:31 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-119-30.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.119.30 with poptime) by smtp806.mail.ukl.yahoo.com with SMTP; 21 Sep 2004 16:12:24 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8LCBWE24996; Tue, 21 Sep 2004 13:11:32 +0100 (BST) To: usenet-format@landfield.com, ietf-usefor@imc.org Xref: clerew local.usefor:20155 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: draft-ietf-usefor-usepro-01 Message-ID: X-Newsreader: NN version 6.5.2 (NOV) Date: Tue, 21 Sep 2004 11:33:26 GMT Lines: 761 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There was some discussion a while back as to whether various bits or protocol material specific to particular headers should remain with those headers after the Usefor/Usepro split, or be extracted and placed in Usepro. Our Chair has now asked that they be moved to Usepro, and this draft implements that change. The draft is now (or soon will be) on www.landfield.com/usenet-format/drafts/draft-ietf-usefor-usepro-01.txt www.landfield.com/usenet-format/drafts/draft-ietf-usefor-usepro-01.unpaged and is also on its way to the drafts editor. It makes no changes wrt the earlier drafts apart from the items listed below, though the wording is revised to suit the new environment. Full diffs are at the end of this message. The (possible) changes are as follows: 1. In 7.3, I have demoted the MUST in the first para of draft-13:5.5 which seemed a bit limiting on those relaying agents which tend to fire off articles whether on not the receiving site wanted them. Surely SHOULD is sufficient, but I could be persuaded I have gone too far. 2. In 7.3 Steps 3 and 4 it said that Relaying agents MUST check the legality of all mandatory headers and SHOULD check the legality of the optional ones as well. I doubt that all relaying agents do such full checks (surely the injecting and serving sites are the ones that should check everything), and I suspect something nearer to SHOULD and MAY would be better. Comments? 3. I have added a section on "Duties of a Reading Agent". The prime reason for this was to find a home for the bit in draft-13:6.6 that "... reading agents MAY be configured so that unwanted distributions do not get displayed" - this was part of our grand attempt to make the Distribution-header more effective by encouraging it to be checked by both senders and receivers. I have padded this out with other obvious duties for the reading agent. 4. In draft-13:5.6.1 (the Path-header) it said: A relaying agent SHOULD NOT pass an article to another relaying agent whose path-identity (or some known alias thereof) already appears in the Path-content. ... A relaying agent MAY decline to accept an article if its own path- identity is already present in the Path-content or if the Path- content contains some path-identity whose articles the relaying agent does not want, as a matter of local policy. NOTE: This last facility is sometimes used to detect and decline control messages (notably cancel messages) which have been deliberately seeded with a path-identity to be "aliased out" by sites not wishing to act upon them. The first para reflects current practice AIUI, but is the 2nd para correct? Surely it would be the serving agent that might do that? For example, if someone "aliases out" some site (e.g. the $alz or cybercancel conventions used by spam cancellers, is it the final serving agent that notices that the pseudo-site 'cybercancel' is present (supposing it does not want to honour those cancels), or is it the final relaying site that does not send the article to it? I suspect the former, and have moved the 2nd para and the NOTE to serving agents (with copious pseudo comments to draw attention to the matter). Please advise me what the correct current practice is. So finally, here are the diffs: *** draft-ietf-usefor-usepro-00.unpaged Thu Sep 2 18:26:27 2004 --- draft-ietf-usefor-usepro-01.unpaged Mon Sep 20 17:18:31 2004 *************** *** 1,10 **** INTERNET-DRAFT Charles H. Lindsey Usenet Format Working Group University of Manchester ! August 2004 News Article Architecture and Protocols ! Status of this Memo --- 1,10 ---- INTERNET-DRAFT Charles H. Lindsey Usenet Format Working Group University of Manchester ! September 2004 News Article Architecture and Protocols ! Status of this Memo *************** *** 30,36 **** The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ! This Internet-Draft will expire in February 2005. Abstract --- 30,36 ---- The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ! This Internet-Draft will expire in March 2005. Abstract *************** *** 112,123 **** 7.2. Duties of an Injecting Agent .............................. 0 7.2.1. Proto-articles ........................................ 0 7.2.2. Procedure to be followed by Injecting Agents .......... 0 ! 7.3. Procedure for Forwarding to a Moderator ................... 0 ! 7.4. Duties of a Relaying Agent ................................ 0 ! 7.4.1. Example ............................................... 0 ! 7.5. Duties of a Serving Agent ................................. 0 ! 7.6. Duties of a Posting Agent ................................. 0 ! 7.7. Duties of a Followup Agent ................................ 0 7.8. Duties of a Moderator ..................................... 0 7.9. Duties of a Gateway ....................................... 0 7.9.1. Duties of an Outgoing Gateway ......................... 0 --- 112,124 ---- 7.2. Duties of an Injecting Agent .............................. 0 7.2.1. Proto-articles ........................................ 0 7.2.2. Procedure to be followed by Injecting Agents .......... 0 ! 7.2.3. Procedure for Forwarding to a Moderator ............... 0 ! 7.3. Duties of a Relaying Agent ................................ 0 ! 7.3.1. Path-Header Example ................................... 0 ! 7.4. Duties of a Serving Agent ................................. 0 ! 7.5. Duties of a Posting Agent ................................. 0 ! 7.6. Duties of a Followup Agent ................................ 0 ! 7.7. Duties of a Reading Agent ................................. 0 7.8. Duties of a Moderator ..................................... 0 7.9. Duties of a Gateway ....................................... 0 7.9.1. Duties of an Outgoing Gateway ......................... 0 *************** *** 1301,1308 **** matter of policy to be determined by the administrators of each injecting agent, who have the responsibility to ensure that no harm arises. In all other circumstances, unintented reinjection is to be ! avoided (see 7.8). Nevertheless, in order to preserve the integrity ! of the network in these special cases, this standard sets out the correct way to reinject. It is usual for an injecting agent to be closely associated with a --- 1301,1308 ---- matter of policy to be determined by the administrators of each injecting agent, who have the responsibility to ensure that no harm arises. In all other circumstances, unintented reinjection is to be ! avoided (see 7.9). Nevertheless, in order to preserve the integrity ! of the network in these special cases, this standard does set out the correct way to reinject. It is usual for an injecting agent to be closely associated with a *************** *** 1372,1379 **** the mandatory headers other than Injection-Date), or which contains any header that does not have legal contents. It SHOULD reject any article which contains any header deprecated for ! Netnews (a-4.2.1). 5. If the article is rejected (for reasons given above, or for other formatting errors or matters of site policy) the posting agent SHOULD be informed (such as via an NNTP 44x response code) that --- 1372,1391 ---- the mandatory headers other than Injection-Date), or which contains any header that does not have legal contents. It SHOULD reject any article which contains any header deprecated for ! Netnews (a-4.2.1). It SHOULD reject any article whose ! Newsgroups-header does not contain at least one newsgroup-name for ! an existing group (as listed by its associated serving agent) and ! it MAY reject any newsgroup-name which, although syntactically ! correct, violates a policy restriction established, for some ! (sub-)hierarchy, by an agency with the appropriate authority ! (1.2). Observe that crossposting to unknown newsgroups is not ! precluded provided at least one of those in the Newsgroups-header ! is listed. + NOTE: This ability to reject newsgroup-names in breach of + established policy does not extend to relaying agents, though it + might be reasonable for posting agents to do it. + 5. If the article is rejected (for reasons given above, or for other formatting errors or matters of site policy) the posting agent SHOULD be informed (such as via an NNTP 44x response code) that *************** *** 1382,1395 **** 6. The Message-ID, Date and From-headers (and their contents) MUST be added when not already present (but that situation could not arise ! during reinjection). 7. The injecting agent MUST NOT alter the body of the article in any ! way. It MAY, except when reinjecting, add other headers not ! already provided by the poster, but SHOULD NOT alter, delete, or ! reorder any existing header, with the specific exception of ! "tracing" headers such as Injection-Info and Complaints-To, which ! are to be removed as already mentioned. 8. If the Newsgroups-header contains one or more moderated groups and the article does NOT contain an Approved-header, the injecting --- 1394,1414 ---- 6. The Message-ID, Date and From-headers (and their contents) MUST be added when not already present (but that situation could not arise ! during reinjection). A User-Agent-header MAY be added (or an ! already present User-Agent-header MAY be augmented) so as to ! identify the software (e.g. "INN/1.7.2") used by the injecting ! agent. 7. The injecting agent MUST NOT alter the body of the article in any ! way (including any change of Content-Transfer-Encoding). It MAY, ! except when reinjecting, add other headers not already provided by ! the poster, but SHOULD NOT alter, delete, or reorder any existing ! header, with the specific exception of "tracing" headers such as ! Injection-Info and Complaints-To, which are to be removed as ! already mentioned. It MAY also, as an interim measure pending ! widespread adoption of the newly introduced (a-5.5) folding ! whitespace, reformat the Newsgroups- and any Followup-To-header by ! removing any such whitespace inserted by the posting agent. 8. If the Newsgroups-header contains one or more moderated groups and the article does NOT contain an Approved-header, the injecting *************** *** 1403,1431 **** 10.It MUST then prepend the path-identity of the injecting agent and a '%' path-delimiter (which serves to separate the pre-injection and post-injection regions of the Path-content) to the Path- ! content; moreover, that path-identity MUST be an FQDN mailable ! address. This could result in more that one '%' path-delimiter in the case of reinjection. See a-5.6.4 for the significance of the various path-delimiters. 11.An Injection-Info-header (a-6.19) SHOULD be added, identifying the trusted source of the article, and a suitable Complaints-To-header ! (a-6.20) MAY be added. ! 12.The injecting agent MUST then add an An Injection-Date-header (a- ! 5.7) if one is not already present, but it MUST NOT alter, or ! remove, an already present Injection-Date-header (and likewise ! SHOULD NOT alter, or remove, an already present NNTP-Posting- ! Date-header). Finally, it forwards the article to one or more ! relaying or serving agents, and the injection process is to be ! considered complete. ! 7.3. Procedure for Forwarding to a Moderator An injecting agent forwards ar article to a moderator as follows: 1. It MUST forward it to the moderator of the first (leftmost) ! moderated group listed in the Newsgroups-header via email (see 7.7 for how that moderator may forward it to further moderators). There are two possibilities for doing this: --- 1423,1467 ---- 10.It MUST then prepend the path-identity of the injecting agent and a '%' path-delimiter (which serves to separate the pre-injection and post-injection regions of the Path-content) to the Path- ! content; this SHOULD then be followed by CRLF and WSP if it would ! otherwise result in a line longer than 79 characters. The ! prepended path-identity MUST be an FQDN mailable address (a- ! 5.6.2). This could result in more that one '%' path-delimiter in the case of reinjection. See a-5.6.4 for the significance of the various path-delimiters. 11.An Injection-Info-header (a-6.19) SHOULD be added, identifying the trusted source of the article, and a suitable Complaints-To-header ! (a-6.20) MAY be added. Each injecting agent SHOULD use a ! consistent form of the Injection-Info-header for all articles ! emanating from the same or similar origins. ! NOTE: The step above is the only place in which an Injection- ! Info- or Complaints-To-header is to be created. It follows that ! these headers MUST NOT be created, replaced, changed or deleted ! by any other agent (except during reinjection, in which case ! they will always relate to the latest injection and can, to that ! extent, be regarded as variant headers). ! 12.The injecting agent MUST then add an Injection-Date-header (a-5.7) ! if one is not already present, but it MUST NOT alter, or delete, ! an already present Injection-Date-header (and likewise SHOULD NOT ! alter, or delete, an already present NNTP-Posting-Date-header). ! Finally, it forwards the article to one or more relaying or ! serving agents, and the injection process is to be considered ! complete. + NOTE: The step above is the only place where an Injection-Date- + header is to be created It follows that it MUST NOT subsequently + be replaced, changed or deleted by any other agent, even during + reinjection. + + 7.2.3. Procedure for Forwarding to a Moderator + An injecting agent forwards ar article to a moderator as follows: 1. It MUST forward it to the moderator of the first (leftmost) ! moderated group listed in the Newsgroups-header via email (see 7.8 for how that moderator may forward it to further moderators). There are two possibilities for doing this: *************** *** 1440,1446 **** (b) The article is sent as an email as it stands, with the addition of such extra headers (e.g. a To-header) as are ! necessary for an email. Although both of these methods have seen use in the past, the preponderance of current usage on Usenet has been for method (b) --- 1476,1483 ---- (b) The article is sent as an email as it stands, with the addition of such extra headers (e.g. a To-header) as are ! necessary for an email. The existing Message-ID-header SHOULD ! be retained. Although both of these methods have seen use in the past, the preponderance of current usage on Usenet has been for method (b) *************** *** 1462,1468 **** "news.announce.important" would be emailed to "news- announce-important@forwardingagent.example". ! 7.4. Duties of a Relaying Agent A Relaying Agent accepts injected articles from injecting and other relaying agents and passes them on to relaying or serving agents --- 1499,1505 ---- "news.announce.important" would be emailed to "news- announce-important@forwardingagent.example". ! 7.3. Duties of a Relaying Agent A Relaying Agent accepts injected articles from injecting and other relaying agents and passes them on to relaying or serving agents *************** *** 1469,1487 **** according to mutually agreed policy. Relaying agents SHOULD accept articles ONLY from trusted agents. A relaying agent processes articles as follows: 1. It MUST establish the trusted identity of the source of the article and compare it with the leftmost path-identity of the Path-content. If it matches it MUST then prepend its own path- ! identity and a '/' path-delimiter to the Path-header. If it does ! not match then it prepends instead two entries to the Path- ! content; firstly the true established path-identity of the source ! followed by a '?' path-delimiter, and then, to the left of that, ! its own path-identity followed by a '/' path-delimiter as usual. ! This prepending of two entries SHOULD NOT be done if the provided ! and established identities match. See a-5.6.4 for the ! significance of the various path-delimiters. NOTE: In order to prevent overloading, relaying agents should not routinely query an external entity (such as a DNS-server) in --- 1506,1564 ---- according to mutually agreed policy. Relaying agents SHOULD accept articles ONLY from trusted agents. + An article SHOULD NOT be relayed unless the sending agent has been + configured to supply and the receiving agent to receive at least one + of the newsgroup-names in its Newsgroups-header and at least one of + the distributions in its Distribution-header, if any. Exceptionally, + ALL relaying agents are deemed willing to supply or accept the + distribution "world", and NO relaying agent should supply or accept + the distribution "local". + [That SHOULD has been demoted from a MUST in draft-13. Any objections?] + + NOTE: Although it would seem redundant to filter out unwanted + distributions at both ends of a relaying link (and it is clearly + more efficient to do so at the sending end), many sending sites + have been reluctant, historically speaking, to apply such + filters (except to ensure that distributions local to their own + site or cooperating subnet did not escape); moreover they tended + to configure their filters on an "all but those listed" basis, + so that new and hitherto unheard of distributions would not be + caught. Indeed many "hub" sites actually wanted to receive all + possible distributions so that they could feed on to their + clients in all possible geographical (or organizational) + regions. + + Therefore, it is desirable to provide facilities for rejecting + unwanted distributions at the receiving end. Indeed, it may be + simpler to do so locally than to inform each sending site of + what is required, especially in the case of specialized + distributions (for example for control messages, such as cancels + from certain issuers) which might need to be added at short + notice. The possibility for reading agents to filter + distributions has been provided (7.7) for the same reason. + + An article SHOULD NOT be relayed if the path-identity of the + receiving agent (or some known alias thereof) appears in its Path- + header, and the receiving agent MAY detect whether its own path- + identity is already present in the Path-content so as to avoid + further unnecessary relaying. + [See related remarks under serving agents.] + A relaying agent processes articles as follows: 1. It MUST establish the trusted identity of the source of the article and compare it with the leftmost path-identity of the Path-content. If it matches it MUST then prepend its own path- ! identity and a '/' path-delimiter to the Path-content; this SHOULD ! then be followed by CRLF and WSP if it would otherwise result in a ! line longer than 79 characters. If it does not match then it ! prepends instead two entries to the Path-content; firstly the true ! established path-identity of the source followed by a '?' path- ! delimiter, and then, to the left of that, its own path-identity ! followed by a '/' path-delimiter as usual. This prepending of two ! entries SHOULD NOT be done if the provided and established ! identities match. See a-5.6.4 for the significance of the various ! path-delimiters. NOTE: In order to prevent overloading, relaying agents should not routinely query an external entity (such as a DNS-server) in *************** *** 1499,1504 **** --- 1576,1584 ---- 4. It SHOULD reject any article whose optional headers (section a-6) do not have legal contents. + [Is that too strong? Are relaying agents really expected to check + headers in that detail? I suggest s/SHOULD/MAY/. Even the MUST in Step 4 + for mandatory headers might be demoted to SHOULD.] 5. It SHOULD reject any article that has already been sent to it (a database of message identifiers of recent messages is usually kept *************** *** 1508,1526 **** cancel message (or an equivalent Supersedes-header) issued by its poster or by some other trusted entity. 7. It MAY reject any article without an Approved-header posted to newsgroups known to be moderated (this practice is strongly recommended, but the information necessary to do so may not be available to all agents). ! 8. Finally, it passes articles which match mutually agreed criteria ! on to neighbouring relaying and serving agents. However, it SHOULD ! NOT forward articles to sites whose path-identity is already in ! the Path-header. ! NOTE: It is usual for relaying and serving agents to restrict ! the Newsgroups, Distributions, age and size of articles that ! they wish to receive. If the article is rejected as being invalid, unwanted or unacceptable due to site policy, the agent that passed the article to the relaying --- 1588,1604 ---- cancel message (or an equivalent Supersedes-header) issued by its poster or by some other trusted entity. 7. It MAY reject any article without an Approved-header posted to newsgroups known to be moderated (this practice is strongly recommended, but the information necessary to do so may not be available to all agents). ! 8. It MAY delete any Xref-header that is present. ! 9. Finally, it passes the articles on to neighbouring relaying and ! serving agents. If the article is rejected as being invalid, unwanted or unacceptable due to site policy, the agent that passed the article to the relaying *************** *** 1530,1542 **** external entity that an article was not relayed UNLESS that external entity has explicitly requested that it be informed of such errors. Relaying agents MUST NOT alter, delete or rearrange any part of an ! article expect for headers designated as variant (a-4.2.5.3). ! 7.4.1. Example Path: foo.isp.example/ foo-server/bar.isp.example?10.123.12.2/old.site.example! barbaz/baz.isp.example%dialup123.baz.isp.example!not-for-mail --- 1608,1633 ---- external entity that an article was not relayed UNLESS that external entity has explicitly requested that it be informed of such errors. Relaying agents MUST NOT alter, delete or rearrange any part of an ! article expect for headers designated as variant (a-4.2.5.3). In ! particular ! o they MUST NOT create or augment a User-Agent-header in order to ! identify themselves; ! o they MUST NOT rewrite the Newsgroups-header in any way, even if ! some supposedly non-existent newsgroup is included; ! o they MUST NOT refold any header (i.e. they must pass on the ! folding as received), even to remove FWS from a Newsgroups- ! header; ! o they MUST NOT alter the Date-header or the Injection-Date-header; ! o they MUST NOT delete any unrecognized header whose header-name is ! syntactically correct (whether or not it is registered with IANA ! [RFC 3864]); ! o they MUST NOT change the Content-Transfer-Encoding of the body or ! any body part. + 7.3.1. Path-Header Example + Path: foo.isp.example/ foo-server/bar.isp.example?10.123.12.2/old.site.example! barbaz/baz.isp.example%dialup123.baz.isp.example!not-for-mail *************** *** 1576,1582 **** fold the line, on the grounds that it seemed to be getting a little too long. ! 7.5. Duties of a Serving Agent A Serving Agent takes an article from a relaying or injecting agent and files it in a "news database". It also provides an interface for --- 1667,1673 ---- fold the line, on the grounds that it seemed to be getting a little too long. ! 7.4. Duties of a Serving Agent A Serving Agent takes an article from a relaying or injecting agent and files it in a "news database". It also provides an interface for *************** *** 1585,1594 **** article-locator (usually in the form of a decimal number - see a- 6.16). ! A serving agent MUST maintain a list showing the moderation status ! (see 6.2.1) of the newsgroups it stores in the news database, and ! SHOULD include in that list all groups likely to be crossposted to ! from those groups (e.g. all other groups in the same hierarchy(ies)). NOTE: Since control messages are often of interest, but should not be displayed as normal articles in regular newsgroups, it is --- 1676,1686 ---- article-locator (usually in the form of a decimal number - see a- 6.16). ! A serving agent MUST maintain a list of the newsgroups it stores in ! its news database showing the moderation status of each one (see ! 6.2.1), and SHOULD include in that list all groups likely to be ! crossposted to from those groups (e.g. all other groups in the same ! hierarchy(ies)). NOTE: Since control messages are often of interest, but should not be displayed as normal articles in regular newsgroups, it is *************** *** 1596,1604 **** newsgroup named "control" or in a pseudo-newsgroup in a sub- hierarchy under "control." (e.g. "control.cancel"). A serving agent processes articles as follows: ! 1. It MUST establish the trusted identity of the source of the article and modify the Path-header as for a relaying agent (7.3). 2. It MUST examine the Injection-Date-header (or, if that is absent, --- 1688,1715 ---- newsgroup named "control" or in a pseudo-newsgroup in a sub- hierarchy under "control." (e.g. "control.cancel"). + A serving agent MAY decline to accept an article if its own path- + identity is already present in the Path-content or if the Path- + content contains some path-identity whose articles the serving agent + does not want, as a matter of local policy. + [That has been changed from a-5.6.1 in previous drafts, where it said "A + relaying agent MAY decline...". That seemed plain wrong to me. It is + fine for a relaying agent to ignore articles which have apparently + already passed through it (and I still say that), but surely it is for + serving agents to "reject" for policy reasons, and to which the NOTE + below would apply. Comments?] + + NOTE: This last facility is sometimes used to detect and decline + control messages (notably cancel messages) which have been + deliberately seeded with a path-identity to be "aliased out" by + sites not wishing to act upon them. + [Again, is this "aliasing out" usually detected by the serving agent, or + does it more usually work because the previous relaying agent will never + have sent it in the first place?] + A serving agent processes articles as follows: ! 1. It MUST establish the trusted identity of the source of the article and modify the Path-header as for a relaying agent (7.3). 2. It MUST examine the Injection-Date-header (or, if that is absent, *************** *** 1612,1618 **** header that does not have legal contents. 4. It SHOULD reject any article that has already been sent to it (a ! database of message identifiers of recent messages is usually kept and matched against). 5. It SHOULD reject any article that matches an already received --- 1723,1729 ---- header that does not have legal contents. 4. It SHOULD reject any article that has already been sent to it (a ! database of message identifiers of recent articles is usually kept and matched against). 5. It SHOULD reject any article that matches an already received *************** *** 1627,1634 **** 8. Finally, it stores the article in its news database. ! 7.6. Duties of a Posting Agent A Posting Agent is used to assist the poster in creating a valid proto-article and forwarding it to an injecting agent. --- 1738,1753 ---- 8. Finally, it stores the article in its news database. ! Serving agents MUST NOT create new newsgroups simply because an ! unrecognized newsgroup-name occurs in a Newsgroups-header (see a- ! 7.2.1 for the correct method of newsgroup creation). + Serving agents MUST NOT alter, delete or rearrange any part of an + article in any other way. The list of particular cases given for + relaying agents (7.3) applies here also. + + 7.5. Duties of a Posting Agent + A Posting Agent is used to assist the poster in creating a valid proto-article and forwarding it to an injecting agent. *************** *** 1641,1648 **** attempt to post an article which cancels or Supersedes another article of which the poster is not the author. - 7.7. Duties of a Followup Agent A Followup Agent is a special case of a posting agent, and as such is bound by all the posting agent's requirements. Followup agents MUST create valid followups and are subject to special requirements --- 1760,1771 ---- attempt to post an article which cancels or Supersedes another article of which the poster is not the author. + 7.6. Duties of a Followup Agent + A Followup Agent is a special case of a posting agent, and as such is bound by all the posting agent's requirements. Followup agents MUST create valid followups and are subject to special requirements *************** *** 1709,1714 **** --- 1832,1856 ---- Followup agents SHOULD NOT attempt to send email to any address ending in ".invalid". + 7.7. Duties of a Reading Agent + + A reading agent downloads articles from a serving agent, as directed + by the reader, and displays them (or processes them in some other + manner). The article as displayed MUST be identical to the article + as originally posted, subject only to limitations of the display + device (such as availability of charsets, etc.). It MUST provide + facilities for decoding any Content-Transfer-Encodings, encoded- + words, etc., but SHOULD also have the capability to show the article + exactly as received. + + It MAY present lists of articles available for display, and MAY + structure those lists so as to show the relationships between the + articles, as determined by the References-, Subject-, Date- and + other-headers (see [USEAGE] for some usual methods of doing this). It + MAY also be configured so that unwanted distributions (a-6.6) are + ignored. + + 7.8. Duties of a Moderator A Moderator receives news articles by email, decides whether to *************** *** 1898,1903 **** --- 2039,2049 ---- 4. Netnews control messages should not be gated to another medium unless they would somehow be meaningful in that medium. + 5. Changes MAY be made to the Content-Transfer-Encoding of some or + all parts of the body, and even to the charsets specified in + encoded-words or in Content-Type-headers, but such changes SHOULD + NOT be made unless absolutely necessary. + 7.9.2. Duties of an Incoming Gateway The incoming gateway has the serious responsibility of ensuring that *************** *** 2297,2302 **** --- 2447,2455 ---- [RFC 2822] P. Resnick, "Internet Message Format", RFC 2822, April 2001. + [RFC 3864] G. Klyne, M. Nottingham, and J. Mogul, "Registration + procedures for message header fields", RFC 3864. + [RFC 850] Mark R. Horton, "Standard for interchange of Usenet messages", RFC 850, June 1983. *************** *** 2341,2348 **** Comments on this draft should preferably be sent to the mailing list of the Usenet Format Working Group at - usenet-format@landfield.com - shortly to be replaced by ietf-usefor@imc.org. Appendix A.1 - A-News Article Format --- 2494,2499 ---- *************** *** 2494,2496 **** --- 2644,2673 ---- Appendix C - Change Log [This Appendix is to be removed prior to final publication.] + + For version 01 + + 1 Numerous texts describing protocol features related to + particular headers in parts of [ARTICLE] which were destined to + become part of [USEFOR] have been moved to appropriate locations + within section 7 of this document. Such revised texts will be + found in sections + 7.2.2 Steps 4, 6, 7, 10, 11, 12; + 7.2.3 Step 1(b); + 7.3 introductory paragraphs, Steps 1, 4, 8, 9, and some final + paragraphs; + 7.4 introductory and final paragraphs; + 7.9.1 Step 5. + + 2 A section on "Duties of a Reading Agent" (7.8) has been added. + + 3 Some demotions MUST -> SHOULD -> MAY, as noted in pseudo- + comments, have been made or proposed in sections + 7.3 + 7.3 Step 4. + + 4 Part of the procedure for examining Path-headers by relaying + agents has been moved to serving agents, as explained in + pseudo-comments in section 7.4. + + 5 Some renumbering of sections and minor textual clarifications. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Tue Sep 21 12:39:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LJdD3H064782 for ; Tue, 21 Sep 2004 12:39:13 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LJdDXR064781 for ietf-usefor-skb; Tue, 21 Sep 2004 12:39:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LJdC1Z064764 for ; Tue, 21 Sep 2004 12:39:12 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14242; Tue, 21 Sep 2004 15:39:14 -0400 (EDT) Message-Id: <200409211939.PAA14242@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-usefor@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-usefor-usepro-01.txt Date: Tue, 21 Sep 2004 15:39:14 -0400 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Usenet Article Standard Update Working Group of the IETF. Title : News Article Architecture and Protocols Author(s) : C. Lindsey Filename : draft-ietf-usefor-usepro-01.txt Pages : 50 Date : 2004-9-21 This Draft, together with its companion draft [USEFOR], are intended as standards track documents, together obsoleting RFC 1036, which itself dates from 1987. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-usefor-usepro-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-usefor-usepro-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-21153226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-usefor-usepro-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-usefor-usepro-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21153226.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-usefor Sun Sep 26 17:12:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8R0CTxe025636 for ; Sun, 26 Sep 2004 17:12:29 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8R0CT0b025635 for ietf-usefor-skb; Sun, 26 Sep 2004 17:12:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8R0CS0S025629 for ; Sun, 26 Sep 2004 17:12:28 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8R0CXxf004248 for ; Sun, 26 Sep 2004 17:12:34 -0700 Received: (qmail 23170 invoked by uid 1000); 27 Sep 2004 00:12:33 -0000 To: ietf-usefor@imc.org Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: (Charles Lindsey's message of "Tue, 21 Sep 2004 11:33:26 GMT") References: From: Russ Allbery Organization: The Eyrie Date: Sun, 26 Sep 2004 17:12:33 -0700 Message-ID: <87ekkomuxa.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > 2. In 7.3 Steps 3 and 4 it said that Relaying agents MUST check the > legality of all mandatory headers and SHOULD check the legality of the > optional ones as well. I doubt that all relaying agents do such full > checks (surely the injecting and serving sites are the ones that should > check everything), and I suspect something nearer to SHOULD and MAY > would be better. Comments? A relaying agent MUST check the legality of all headers that it needs to use to do its job, namely at least Path, Date, Message-ID, Control if present, Injection-Date if present, and probably also Newsgroups. Demoting the rest to a SHOULD seems reasonable to me. Thinking about it, I see no reason to distinguish between mandatory and optional headers here, although perhaps I'm missing something. > 3. I have added a section on "Duties of a Reading Agent". The prime > reason for this was to find a home for the bit in draft-13:6.6 that > "... reading agents MAY be configured so that unwanted distributions do > not get displayed" - this was part of our grand attempt to make the > Distribution-header more effective by encouraging it to be checked by > both senders and receivers. I have padded this out with other obvious > duties for the reading agent. I think both that comment and really this entire section should simply be striken in its entirety. It seems completely unnecessary to me. > 4. In draft-13:5.6.1 (the Path-header) it said: > A relaying agent SHOULD NOT pass an article to another relaying agent > whose path-identity (or some known alias thereof) already appears in > the Path-content. ... > A relaying agent MAY decline to accept an article if its own path- > identity is already present in the Path-content or if the Path- > content contains some path-identity whose articles the relaying agent > does not want, as a matter of local policy. > NOTE: This last facility is sometimes used to detect and decline > control messages (notably cancel messages) which have been > deliberately seeded with a path-identity to be "aliased out" by > sites not wishing to act upon them. > The first para reflects current practice AIUI, but is the 2nd para > correct? The second paragraph and the NOTE are pointless; relaying agents can reject anything they want based on local policy, and there's no reason to single this out in particular since it doesn't do anything particularly useful. I'd drop both entirely. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Mon Sep 27 09:12:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RGCnai099710 for ; Mon, 27 Sep 2004 09:12:49 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RGCn4a099709 for ietf-usefor-skb; Mon, 27 Sep 2004 09:12:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp804.mail.ukl.yahoo.com (smtp804.mail.ukl.yahoo.com [217.12.12.141]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8RGCm0w099698 for ; Mon, 27 Sep 2004 09:12:48 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-67-180.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.67.180 with poptime) by smtp804.mail.ukl.yahoo.com with SMTP; 27 Sep 2004 16:12:34 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8RGCCH19740; Mon, 27 Sep 2004 17:12:12 +0100 (BST) To: usenet-format@landfield.com, ietf-usefor@imc.org Xref: clerew local.usefor:20157 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: draft-ietf-usefor-usepro-01 Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <87ekkomuxa.fsf@windlord.stanford.edu> Date: Mon, 27 Sep 2004 11:58:20 GMT Lines: 99 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <87ekkomuxa.fsf@windlord.stanford.edu> Russ Allbery writes: >Charles Lindsey writes: >> 2. In 7.3 Steps 3 and 4 it said that Relaying agents MUST check the >> legality of all mandatory headers and SHOULD check the legality of the >> optional ones as well. I doubt that all relaying agents do such full >> checks (surely the injecting and serving sites are the ones that should >> check everything), and I suspect something nearer to SHOULD and MAY >> would be better. Comments? >A relaying agent MUST check the legality of all headers that it needs to >use to do its job, namely at least Path, Date, Message-ID, Control if >present, Injection-Date if present, and probably also Newsgroups. >Demoting the rest to a SHOULD seems reasonable to me. Thinking about it, >I see no reason to distinguish between mandatory and optional headers >here, although perhaps I'm missing something. OK, an explicit list makes sense (leaves From and Subject out of it). I am not so sure about Control; surely that is for serving agents, not relaying agents (and the serving agent will probably just hand it over to whatever subsystem deals with control messages and let that check as it sees fit)? Also, one could omit Date if Injection-Date is present. As for the rest, why not demote to MAY rather than SHOULD? Do current relaying agents routinely check all the lesser known headers, especially if they are just transit agents? >> 3. I have added a section on "Duties of a Reading Agent". The prime >> reason for this was to find a home for the bit in draft-13:6.6 that >> "... reading agents MAY be configured so that unwanted distributions do >> not get displayed" - this was part of our grand attempt to make the >> Distribution-header more effective by encouraging it to be checked by >> both senders and receivers. I have padded this out with other obvious >> duties for the reading agent. >I think both that comment and really this entire section should simply be >striken in its entirety. It seems completely unnecessary to me. Well the bit about distributions was in all our earlier drafts, so I can't just throw it away without some WG discussion. I could be persuaded that it belongs in USEAGE. However, I have now found another bit in draft-13 which really belongs in USEPRO. In 6.21.2 it said: Reading agents SHOULD NOT, unless explicitly configured otherwise, act automatically on Application types which could change the state of that agent (e.g. by writing or modifying files), except in the case of those prescribed for use in control messages (7.2.1.2 and 7.2.4.1). So that reads like a duty of a reading agent, though maybe it is a security consideration. Anyway, I will leave that section in the draft for now until I hear more opinions from this list. >> 4. In draft-13:5.6.1 (the Path-header) it said: >> A relaying agent SHOULD NOT pass an article to another relaying agent >> whose path-identity (or some known alias thereof) already appears in >> the Path-content. ... >> A relaying agent MAY decline to accept an article if its own path- >> identity is already present in the Path-content or if the Path- >> content contains some path-identity whose articles the relaying agent >> does not want, as a matter of local policy. >> NOTE: This last facility is sometimes used to detect and decline >> control messages (notably cancel messages) which have been >> deliberately seeded with a path-identity to be "aliased out" by >> sites not wishing to act upon them. >> The first para reflects current practice AIUI, but is the 2nd para >> correct? >The second paragraph and the NOTE are pointless; relaying agents can >reject anything they want based on local policy, and there's no reason to >single this out in particular since it doesn't do anything particularly >useful. I'd drop both entirely. I could easily be persuaded that the second paragraph and NOTE are supefluous, but I would still be interested to hear whether relaying agents actually do it or not. But the 1st paragraph seems to be an important part of the protocol, and part of the machinery for avoiding loops. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Mon Sep 27 09:36:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RGaHHW001340 for ; Mon, 27 Sep 2004 09:36:17 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RGaHuw001339 for ietf-usefor-skb; Mon, 27 Sep 2004 09:36:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RGaGwi001328 for ; Mon, 27 Sep 2004 09:36:16 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8RGaEcC001140; Mon, 27 Sep 2004 12:36:14 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8RGaDNA001139; Mon, 27 Sep 2004 12:36:13 -0400 (EDT) Date: Mon, 27 Sep 2004 12:36:13 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 27 Sep 2004, Charles Lindsey wrote: > >A relaying agent MUST check the legality of all headers that it needs to > >use to do its job, namely at least Path, Date, Message-ID, Control if > >present, Injection-Date if present, and probably also Newsgroups... > > OK, an explicit list makes sense (leaves From and Subject out of it). In the C News days, persistent pressure eventually persuaded us that our relaying stuff really should check for at least the presence of *all* mandatory headers -- that it served nobody's interests for blatantly malformed articles to propagate. If memory serves, we did not actually do any checking on the From content beyond verifying its presence. Moreover, we did not really do a syntax check on the Path content. Date and Message-ID had to be parsable, as did Newsgroups (although our parsing of that was very simple and would not catch some subtle goofs). > As for the rest, why not demote to MAY rather than SHOULD? Do current > relaying agents routinely check all the lesser known headers, especially > if they are just transit agents? Certainly C News didn't. > >> A relaying agent MAY decline to accept an article if its own path- > >> identity is already present in the Path-content... > > ...I would still be interested to hear whether relaying > agents actually do it or not. If I recall correctly, C News examined Path only on transmission, not on reception. > But the 1st paragraph seems to be an important part of the protocol, and > part of the machinery for avoiding loops. Indeed, the first paragraph remains necessary. It's primarily an efficiency hack rather than loop prevention -- the message ID check is what really breaks loops -- but it's an important one. Henry Spencer henry@spsystems.net From owner-ietf-usefor Mon Sep 27 13:08:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RK84tA016652 for ; Mon, 27 Sep 2004 13:08:04 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RK84bj016651 for ietf-usefor-skb; Mon, 27 Sep 2004 13:08:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RK84Am016645 for ; Mon, 27 Sep 2004 13:08:04 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8RK87i2002048 for ; Mon, 27 Sep 2004 13:08:08 -0700 Received: (qmail 16322 invoked by uid 1000); 27 Sep 2004 20:08:07 -0000 To: ietf-usefor@imc.org, usenet-format@landfield.com Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: (Charles Lindsey's message of "Mon, 27 Sep 2004 11:58:20 GMT") References: <87ekkomuxa.fsf@windlord.stanford.edu> From: Russ Allbery Organization: The Eyrie Date: Mon, 27 Sep 2004 13:08:07 -0700 Message-ID: <87fz53mq54.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > Russ Allbery writes: >> A relaying agent MUST check the legality of all headers that it needs >> to use to do its job, namely at least Path, Date, Message-ID, Control >> if present, Injection-Date if present, and probably also Newsgroups. >> Demoting the rest to a SHOULD seems reasonable to me. Thinking about >> it, I see no reason to distinguish between mandatory and optional >> headers here, although perhaps I'm missing something. > OK, an explicit list makes sense (leaves From and Subject out of it). Right. Those are the two mandatory headers that have no real impact on relaying. Henry's point is well-taken in that it might be worthwhile doing some sort of cursory check just to keep from propagating trash, but on the other hand, major servers don't do this now and Usenet hasn't broken. To me, that argues against a MUST and towards a SHOULD. > I am not so sure about Control; surely that is for serving agents, not > relaying agents (and the serving agent will probably just hand it over > to whatever subsystem deals with control messages and let that check as > it sees fit)? No, see the special propagation rules for newgroup and rmgroup control messages. Relaying agents have to know about that. > Also, one could omit Date if Injection-Date is present. Yes, but beware of backward compatibility here; not everyone will use Injection-Date by preference. Plus, it's more complicated to say that; it's easier to just check both of them. > As for the rest, why not demote to MAY rather than SHOULD? Do current > relaying agents routinely check all the lesser known headers, especially > if they are just transit agents? INN does, yes. Remember that for a relaying agent, if it accepts the message, it also passes it on to other sites. I think that one SHOULD avoid propagating known-broken messages. However, I don't feel strongly enough about this to argue it at length and will happily go along with whatever the group consensus is. > However, I have now found another bit in draft-13 which really belongs > in USEPRO. In 6.21.2 it said: > Reading agents SHOULD NOT, unless explicitly configured otherwise, > act automatically on Application types which could change the state > of that agent (e.g. by writing or modifying files), except in the > case of those prescribed for use in control messages (7.2.1.2 and > 7.2.4.1). > So that reads like a duty of a reading agent, though maybe it is a > security consideration. Yes, I think this is a security consideration and would rather see it there than in a separate duties section. This isn't a statement about what a reading agent should do, but rather what a reading agent shouldn't do. I really think the Distribution thing is pointless. Is anyone aware of a reading agent that actually does that? Would anyone reading this list actually use that feature, as opposed to just reading the relevant regional group? > I could easily be persuaded that the second paragraph and NOTE are > supefluous, but I would still be interested to hear whether relaying > agents actually do it or not. INN doesn't. > But the 1st paragraph seems to be an important part of the protocol, and > part of the machinery for avoiding loops. Oh, certainly, I have no objections at all to the first paragraph and indeed believe it should stay. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Sep 28 09:12:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SGCwa9017831 for ; Tue, 28 Sep 2004 09:12:58 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SGCwcv017830 for ietf-usefor-skb; Tue, 28 Sep 2004 09:12:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SGCvPL017805 for ; Tue, 28 Sep 2004 09:12:57 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) X-Gradwell-Debug: delivering mail for [ietf-usefor@imc.org] to mail.imc.org [208.184.76.43]:25 Received: from host81-144-118-105.midband.mdip.bt.net [81.144.118.105] by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.134) id 41598d80.003ac5.001; Tue, 28 Sep 2004 17:12:48 +0100 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8SGCMq29208; Tue, 28 Sep 2004 17:12:22 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20160 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: draft-ietf-usefor-usepro-01 Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <87ekkomuxa.fsf@windlord.stanford.edu> <87fz53mq54.fsf@windlord.stanford.edu> Date: Tue, 28 Sep 2004 11:24:15 GMT Lines: 131 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <87fz53mq54.fsf@windlord.stanford.edu> Russ Allbery writes: >Charles Lindsey writes: >> Russ Allbery writes: >> OK, an explicit list makes sense (leaves From and Subject out of it). >Right. Those are the two mandatory headers that have no real impact on >relaying. Henry's point is well-taken in that it might be worthwhile >doing some sort of cursory check just to keep from propagating trash, but >on the other hand, major servers don't do this now and Usenet hasn't >broken. To me, that argues against a MUST and towards a SHOULD. Two points, arising from Henry: 1. MUST/SHOULD check for presence of mandatory headers. 2. MUST/SHOULD check for legality of listed headers, but only to the extent needed to ensure they work. For example, you told us recently that you only parse the Date header until you have seen enough to construct a valid date; any trailing rubbish is not looked at. Again, for newsgroups, you are only concerned to see whether anything in your active file is included; you don't care if some malformed names of non-existent groups are present, so long as your parser can manage to skip over them. Is that OK, assuming I can invent a wording for "parse to the extent necessary for proper operation". And in that case, please choose between MUST and SHOULD. >> I am not so sure about Control; surely that is for serving agents, not >> relaying agents (and the serving agent will probably just hand it over >> to whatever subsystem deals with control messages and let that check as >> it sees fit)? >No, see the special propagation rules for newgroup and rmgroup control >messages. Relaying agents have to know about that. Yes, but that does not impose any requirement to check the Control header for legality, which is what we are discussing here. At most, it means recognizing that a Control header is present, and I think the existing wording (now in USEPRO section 6) says what needs to be said. However, upon looking at that wording, it does seem to say more than I intended. In draft-13 it said (and the new USEFOR needs to say) that the Newsgroups header of a control message needs to include the newsgroup-name affected, and anything else that will help to steer it to where it is wanted. But if I only take the big-8 plus uk.* on my system, I don't want to be flooded out with newgroup messages for jp.*. Now the other paragraph from draft-13, which now appears in USEPRO section 6, says: Relaying Agents MUST propagate all control messages regardless of whether or not they are recognized or processed locally. That was intended to say that, even if your local policy is to ignore all newgroup message and all cancels, you are still supposed to propagate control messages normally for the benefit of neighbouring sites who are not so fussy. It certainly was not meant to say that you were to propagate them to peers who did not take the affected hierarchies at all. If it is agreed that what I have just said is what we intend, then I need to review that wording, especially as the two paragraphs which were once together are now going to be in different documents. >> Also, one could omit Date if Injection-Date is present. >Yes, but beware of backward compatibility here; not everyone will use >Injection-Date by preference. Plus, it's more complicated to say that; >it's easier to just check both of them. OK, I shall not bother if it uses too much verbiage. >> As for the rest, why not demote to MAY rather than SHOULD? Do current >> relaying agents routinely check all the lesser known headers, especially >> if they are just transit agents? >INN does, yes. Remember that for a relaying agent, if it accepts the >message, it also passes it on to other sites. I think that one SHOULD >avoid propagating known-broken messages. Yes, but if you don't look, it isn't "known". My inclination is to take Henry's lead and demote to MAY. I am pretty sure that transit relayers will not be making such checks. >> Reading agents SHOULD NOT, unless explicitly configured otherwise, >> act automatically on Application types which could change the state >> of that agent (e.g. by writing or modifying files), except in the >> case of those prescribed for use in control messages (7.2.1.2 and >> 7.2.4.1). >Yes, I think this is a security consideration and would rather see it >there than in a separate duties section. This isn't a statement about >what a reading agent should do, but rather what a reading agent shouldn't >do. Agreed. >I really think the Distribution thing is pointless. Is anyone aware of a >reading agent that actually does that? Would anyone reading this list >actually use that feature, as opposed to just reading the relevant >regional group? We agreed long ago to attempt to make the Distribution header more effective by making sure it got looked at at the proper places. So that action by reading agents was something we wanted to encourage to happen, rather than something that was happening currently (hence the MAY). But I am happy to move that particular bit to USEAGE. >> I could easily be persuaded that the second paragraph and NOTE are >> supefluous, but I would still be interested to hear whether relaying >> agents actually do it or not. >INN doesn't. And Henry says CNews doesn't, and I have just tried it on my own CNews and it didn't. So am I right in thinking that if I don't want to see cancels from all the regular spam cancellers, I have got to instruct my upstream peers to register 'cybercancel' as an alias for my site in their sys files? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Tue Sep 28 11:31:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SIVFgN027975 for ; Tue, 28 Sep 2004 11:31:15 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SIVFuF027974 for ietf-usefor-skb; Tue, 28 Sep 2004 11:31:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SIVECV027968 for ; Tue, 28 Sep 2004 11:31:14 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8SIVIEV005178 for ; Tue, 28 Sep 2004 11:31:18 -0700 Received: (qmail 10433 invoked by uid 1000); 28 Sep 2004 18:31:17 -0000 To: usenet-format@landfield.com, ietf-usefor@imc.org Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: (Charles Lindsey's message of "Tue, 28 Sep 2004 11:24:15 GMT") References: <87ekkomuxa.fsf@windlord.stanford.edu> <87fz53mq54.fsf@windlord.stanford.edu> From: Russ Allbery Organization: The Eyrie Date: Tue, 28 Sep 2004 11:31:17 -0700 Message-ID: <87u0tidz4a.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > Russ Allbery writes: >> Right. Those are the two mandatory headers that have no real impact on >> relaying. Henry's point is well-taken in that it might be worthwhile >> doing some sort of cursory check just to keep from propagating trash, >> but on the other hand, major servers don't do this now and Usenet >> hasn't broken. To me, that argues against a MUST and towards a SHOULD. > Two points, arising from Henry: > 1. MUST/SHOULD check for presence of mandatory headers. > 2. MUST/SHOULD check for legality of listed headers, but only to the > extent needed to ensure they work. For example, you told us recently that > you only parse the Date header until you have seen enough to construct a > valid date; any trailing rubbish is not looked at. Again, for newsgroups, > you are only concerned to see whether anything in your active file is > included; you don't care if some malformed names of non-existent groups > are present, so long as your parser can manage to skip over them. > Is that OK, assuming I can invent a wording for "parse to the extent > necessary for proper operation". And in that case, please choose between > MUST and SHOULD. I am very leery of statements like "parse to the extent necessary for proper operation" in Usenet standards, since that concept cannot be tightly specified. I don't believe there's any reasonable middle point. Either we're going to require that relay agents detect and discard some set of invalid messages, or we're not going to do that and leave it up to each individual relay agent. Currently, existing practice is the latter -- relay agents accept and propagate all sorts of syntactically broken messages. If that's acceptable to people, then I think we should just say SHOULD check or MAY check headers and leave it at that. That attitude is incompatible with what Henry was saying about making sure that the article is at least basically formed, I think. I don't see how it makes any sense to be sure mandatory headers are present without making sure that they contain usable data (and the only definition of usable data that makes any sense to me is compliant and parsable data). >> No, see the special propagation rules for newgroup and rmgroup control >> messages. Relaying agents have to know about that. > Yes, but that does not impose any requirement to check the Control > header for legality, which is what we are discussing here. It requires that the Control message be parsed to the degree that the type of control message and its parameters be recognized, which inherently requires validating its syntax to some degree. Of course, validating the syntax doesn't mean that one has to reject invalid messages; one can just treat them as if they don't have a Control header at all. Is that what you're saying? > At most, it means recognizing that a Control header is present, You have to at least know whether it's a newgroup or rmgroup control message. > However, upon looking at that wording, it does seem to say more than I > intended. In draft-13 it said (and the new USEFOR needs to say) that the > Newsgroups header of a control message needs to include the > newsgroup-name affected, and anything else that will help to steer it to > where it is wanted. Currently, INN can optionally ignore the Newsgroups header is ignored in newgroup and rmgroup control messages by INN; such messages are treated as if they were posted only to the affected newsgroup (and then propagated using the special propagation rules for control messages, which ignore newsgroup existence). I'm trying to remember previous discussions we had on this topic; did we decide that was wrong? It doesn't make a lot of sense to me right now that it's an option in INN, so it would be nice to standardize one type of behavior or another. RFC 1036 is silent on the subject and Son-of-1036 addresses it only in a note: Third, the relayer MUST determine whether any of the article's newsgroups are "subscribed to" by the host, i.e. fit a description of what hierarchies or newsgroups the site wants to receive. NOTE: This check is significant because information on what newsgroups a relayer wishes to receive is often stored at its neighbors, who may not have up-to-date information or may simplify the rules for implementation reasons. As a hedge against the possibility of missed or delayed newgroup control messages, relayers may wish to observe a notion of a newsgroup subscription that is independent of the list of newsgroups actually known to the relayer. This would permit reception and relaying of articles in newsgroups that the relayer is not (yet) aware of, subject to more general criteria indicating that they are likely to be of interest. which is not specific to control messages. (This is interesting to me, since I thought that special propagation of newgroup and rmgroup control messages was long-standing established practice, but apparently it isn't as much as I thought it was.) > Now the other paragraph from draft-13, which now appears in USEPRO > section 6, says: > Relaying Agents MUST propagate all control messages regardless of > whether or not they are recognized or processed locally. > That was intended to say that, even if your local policy is to ignore > all newgroup message and all cancels, you are still supposed to > propagate control messages normally for the benefit of neighbouring > sites who are not so fussy. It certainly was not meant to say that you > were to propagate them to peers who did not take the affected > hierarchies at all. I don't know where this sentence came from and it's never made any sense to me. It's on my list of language that I believe should be striken from the USEPRO document. > If it is agreed that what I have just said is what we intend, Certainly not. Relay agents are never required to propagate anything whatsoever. Instead, the special propagation rules for newgroup and rmgroup control messages need to be specifically described. >> Yes, but beware of backward compatibility here; not everyone will use >> Injection-Date by preference. Plus, it's more complicated to say that; >> it's easier to just check both of them. > OK, I shall not bother if it uses too much verbiage. It will add unnecessary complexity even if there's a short way of saying it. Please, don't bother. :) >> INN does, yes. Remember that for a relaying agent, if it accepts the >> message, it also passes it on to other sites. I think that one SHOULD >> avoid propagating known-broken messages. > Yes, but if you don't look, it isn't "known". My inclination is to take > Henry's lead and demote to MAY. I am pretty sure that transit relayers > will not be making such checks. INN does, as I've said several times, although in a somewhat limited capacity (in that it's somewhat particular about what it cares about and what it doesn't care about). I'm hoping to clean that up over time. > We agreed long ago to attempt to make the Distribution header more > effective by making sure it got looked at at the proper places. Note that I do not consider myself to be part of this "we" at this time and do not agree that we have consensus to do this. > So am I right in thinking that if I don't want to see cancels from all > the regular spam cancellers, I have got to instruct my upstream peers to > register 'cybercancel' as an alias for my site in their sys files? I have no idea how CNews works in this area, but INN allows you to list Path identities that, if found in incoming articles, should cause those articles to be rejected. This configuration option is entirely independent of your own Path identity and is intended specifically for aliasing out sites or pseudosites. This facility has been in INN since 1.0, I believe. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Sep 28 11:58:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SIwXhQ029910 for ; Tue, 28 Sep 2004 11:58:33 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SIwXiA029909 for ietf-usefor-skb; Tue, 28 Sep 2004 11:58:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SIwWUv029901 for ; Tue, 28 Sep 2004 11:58:32 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8SIwKcC008088; Tue, 28 Sep 2004 14:58:20 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8SIwJGd008087; Tue, 28 Sep 2004 14:58:19 -0400 (EDT) Date: Tue, 28 Sep 2004 14:58:19 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List cc: usenet-format@landfield.com Subject: relay checking (was Re: draft-ietf-usefor-usepro-01) In-Reply-To: <87u0tidz4a.fsf@windlord.stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 28 Sep 2004, Russ Allbery wrote: > That attitude is incompatible with what Henry was saying about making sure > that the article is at least basically formed, I think. I don't see how > it makes any sense to be sure mandatory headers are present without making > sure that they contain usable data (and the only definition of usable data > that makes any sense to me is compliant and parsable data). The feedback we got, way back when, was that this distinction *was* valuable -- that merely demanding the presence of the mandatory headers eliminated a class of problems. Since I never knew the details of what those problems were, I can't say whether they're still relevant. On the whole, I rather doubt it. My feeling is that we should *encourage* relaying agents to do as much checking -- beyond the minimum they need to function -- as they think they can manage, but given that they historically have serious performance constraints, we should refrain from *demanding* extra work from them unless it is clearly vital. If for no other reason, I think this is preferable because it avoids the whole question of exactly which things need to be checked and how thoroughly. Henry Spencer henry@spsystems.net From owner-ietf-usefor Tue Sep 28 12:04:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SJ44a5030361 for ; Tue, 28 Sep 2004 12:04:04 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SJ44Nc030360 for ietf-usefor-skb; Tue, 28 Sep 2004 12:04:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SJ43J5030354 for ; Tue, 28 Sep 2004 12:04:03 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8SJ46kH014679 for ; Tue, 28 Sep 2004 12:04:07 -0700 Received: (qmail 11335 invoked by uid 1000); 28 Sep 2004 19:04:06 -0000 To: Usefor Mailing List , usenet-format@landfield.com Subject: Re: relay checking In-Reply-To: (Henry Spencer's message of "Tue, 28 Sep 2004 14:58:19 -0400 (EDT)") References: From: Russ Allbery Organization: The Eyrie Date: Tue, 28 Sep 2004 12:04:06 -0700 Message-ID: <87brfqdxll.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Henry Spencer writes: > The feedback we got, way back when, was that this distinction *was* > valuable -- that merely demanding the presence of the mandatory headers > eliminated a class of problems. Since I never knew the details of what > those problems were, I can't say whether they're still relevant. On the > whole, I rather doubt it. Oh, okay. > My feeling is that we should *encourage* relaying agents to do as much > checking -- beyond the minimum they need to function -- as they think > they can manage, but given that they historically have serious > performance constraints, we should refrain from *demanding* extra work > from them unless it is clearly vital. > If for no other reason, I think this is preferable because it avoids the > whole question of exactly which things need to be checked and how > thoroughly. That sounds like an argument for SHOULD (that's the encouragement) check the syntactical validity of the article, without distinctions between mandatory and optional headers. Does that match what you're thinking? -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Sep 28 12:31:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SJVrvQ032436 for ; Tue, 28 Sep 2004 12:31:53 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SJVrNd032435 for ietf-usefor-skb; Tue, 28 Sep 2004 12:31:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SJVqDV032429 for ; Tue, 28 Sep 2004 12:31:53 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8SJVkcC008237; Tue, 28 Sep 2004 15:31:46 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8SJVk97008236; Tue, 28 Sep 2004 15:31:46 -0400 (EDT) Date: Tue, 28 Sep 2004 15:31:45 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List cc: usenet-format@landfield.com Subject: Re: relay checking In-Reply-To: <87brfqdxll.fsf@windlord.stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 28 Sep 2004, Russ Allbery wrote: > > My feeling is that we should *encourage* relaying agents to do as much > > checking -- beyond the minimum they need to function -- as they think > > they can manage, but given that they historically have serious > > performance constraints, we should refrain from *demanding* extra work > > from them unless it is clearly vital... > > That sounds like an argument for SHOULD (that's the encouragement) check > the syntactical validity of the article, without distinctions between > mandatory and optional headers. Does that match what you're thinking? I'm a little reluctant to use SHOULD for any of this, because that keyword is generally understood to mean that the action in question is nearly mandatory, that almost everyone is expected to do it but there are special situations where it is impractical. This doesn't seem right for something where incomplete implementations are common and expected to remain so. I think the right choice is either to say MAY with some accompanying words urging people to do it, or to say SHOULD but accompany it with an escape hatch like "to the extent that performance requirements permit". Henry Spencer henry@spsystems.net From owner-ietf-usefor Tue Sep 28 13:16:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SKGDQP035883 for ; Tue, 28 Sep 2004 13:16:13 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SKGDfj035882 for ietf-usefor-skb; Tue, 28 Sep 2004 13:16:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SKGDaK035876 for ; Tue, 28 Sep 2004 13:16:13 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8SKGG3r009372 for ; Tue, 28 Sep 2004 13:16:16 -0700 Received: (qmail 12877 invoked by uid 1000); 28 Sep 2004 20:16:16 -0000 To: Usefor Mailing List , usenet-format@landfield.com Subject: Re: relay checking In-Reply-To: (Henry Spencer's message of "Tue, 28 Sep 2004 15:31:45 -0400 (EDT)") References: From: Russ Allbery Organization: The Eyrie Date: Tue, 28 Sep 2004 13:16:16 -0700 Message-ID: <87k6ueb14f.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Henry Spencer writes: > I think the right choice is either to say MAY with some accompanying > words urging people to do it, or to say SHOULD but accompany it with an > escape hatch like "to the extent that performance requirements permit". Hm. Okay, yeah, that works for me. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Sep 28 14:00:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SL0NLR040088 for ; Tue, 28 Sep 2004 14:00:23 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SL0N4w040087 for ietf-usefor-skb; Tue, 28 Sep 2004 14:00:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from oddball.prodigy.com (prgy-npn1.prodigy.com [207.115.54.37]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SL0MMr040063 for ; Tue, 28 Sep 2004 14:00:22 -0700 (PDT) (envelope-from davidsen@tmr.com) Received: from [127.0.0.1] (oddball.prodigy.com [127.0.0.1]) by oddball.prodigy.com (8.11.6/8.11.6) with ESMTP id i8SL1Vt16695; Tue, 28 Sep 2004 17:01:31 -0400 Message-ID: <4159D12A.70100@tmr.com> Date: Tue, 28 Sep 2004 17:01:30 -0400 From: Bill Davidsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: mail.usenet-format To: Russ Allbery CC: ietf-usefor@imc.org Subject: Re: draft-ietf-usefor-usepro-01 References: <87ekkomuxa.fsf@windlord.stanford.edu> In-Reply-To: <87ekkomuxa.fsf@windlord.stanford.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: >>3. I have added a section on "Duties of a Reading Agent". The prime >>reason for this was to find a home for the bit in draft-13:6.6 that >>"... reading agents MAY be configured so that unwanted distributions do >>not get displayed" - this was part of our grand attempt to make the >>Distribution-header more effective by encouraging it to be checked by >>both senders and receivers. I have padded this out with other obvious >>duties for the reading agent. > > > I think both that comment and really this entire section should simply be > striken in its entirety. It seems completely unnecessary to me. Clearly some agent is responsible for generating the required headers, beyond the enumeration of mandatory headers need anything else be mentioned? -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From owner-ietf-usefor Tue Sep 28 14:00:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SL0GxG040071 for ; Tue, 28 Sep 2004 14:00:16 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SL0Gde040070 for ietf-usefor-skb; Tue, 28 Sep 2004 14:00:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from gatekeeper.tmr.com (mail.tmr.com [216.238.38.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SL0F55040058 for ; Tue, 28 Sep 2004 14:00:15 -0700 (PDT) (envelope-from news@gatekeeper.tmr.com) Received: (from news@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) id QAA28321; Tue, 28 Sep 2004 16:52:53 -0400 To: usenet-format@landfield.com, ietf-usefor@imc.org Path: not-for-mail From: Bill Davidsen Newsgroups: mail.usenet-format Subject: Re: draft-ietf-usefor-usepro-01 Date: Tue, 28 Sep 2004 17:01:30 -0400 Organization: TMR Associates, Inc Lines: 21 Message-ID: <4159D12A.70100@tmr.com> References: <87ekkomuxa.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gatekeeper.tmr.com 1096404772 28318 192.168.12.100 (28 Sep 2004 20:52:52 GMT) X-Complaints-To: abuse@tmr.com Cc: ietf-usefor@imc.org To: Russ Allbery User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en In-Reply-To: <87ekkomuxa.fsf@windlord.stanford.edu> Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: >>3. I have added a section on "Duties of a Reading Agent". The prime >>reason for this was to find a home for the bit in draft-13:6.6 that >>"... reading agents MAY be configured so that unwanted distributions do >>not get displayed" - this was part of our grand attempt to make the >>Distribution-header more effective by encouraging it to be checked by >>both senders and receivers. I have padded this out with other obvious >>duties for the reading agent. > > > I think both that comment and really this entire section should simply be > striken in its entirety. It seems completely unnecessary to me. Clearly some agent is responsible for generating the required headers, beyond the enumeration of mandatory headers need anything else be mentioned? -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From owner-ietf-usefor Tue Sep 28 14:07:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SL7HlW040763 for ; Tue, 28 Sep 2004 14:07:17 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SL7HQa040762 for ietf-usefor-skb; Tue, 28 Sep 2004 14:07:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SL7GHp040756 for ; Tue, 28 Sep 2004 14:07:16 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8SL7KYb028786 for ; Tue, 28 Sep 2004 14:07:20 -0700 Received: (qmail 14122 invoked by uid 1000); 28 Sep 2004 21:07:20 -0000 To: ietf-usefor@imc.org Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: <4159D12A.70100@tmr.com> (Bill Davidsen's message of "Tue, 28 Sep 2004 17:01:30 -0400") References: <87ekkomuxa.fsf@windlord.stanford.edu> <4159D12A.70100@tmr.com> From: Russ Allbery Organization: The Eyrie Date: Tue, 28 Sep 2004 14:07:20 -0700 Message-ID: <877jqe9k6v.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Davidsen writes: > Clearly some agent is responsible for generating the required headers, > beyond the enumeration of mandatory headers need anything else be > mentioned? It's probably worthwhile to say something about the breakdown of duties between the posting agent and the injecting agent, but we do already do that (in those sections). -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Sep 28 14:26:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLQwZG041988 for ; Tue, 28 Sep 2004 14:26:58 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SLQwL1041987 for ietf-usefor-skb; Tue, 28 Sep 2004 14:26:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from gatekeeper.tmr.com (mail.tmr.com [216.238.38.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLQvl3041973 for ; Tue, 28 Sep 2004 14:26:58 -0700 (PDT) (envelope-from news@gatekeeper.tmr.com) Received: (from news@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) id RAA28415; Tue, 28 Sep 2004 17:19:38 -0400 To: usenet-format@landfield.com, ietf-usefor@imc.org Path: not-for-mail From: Bill Davidsen Newsgroups: mail.usenet-format Subject: Re: relay checking Date: Tue, 28 Sep 2004 17:28:15 -0400 Organization: TMR Associates, Inc Lines: 20 Message-ID: References: <87brfqdxll.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gatekeeper.tmr.com 1096406378 28385 192.168.12.100 (28 Sep 2004 21:19:38 GMT) X-Complaints-To: abuse@tmr.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en In-Reply-To: Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Henry Spencer wrote: > I'm a little reluctant to use SHOULD for any of this, because that keyword > is generally understood to mean that the action in question is nearly > mandatory, that almost everyone is expected to do it but there are special > situations where it is impractical. This doesn't seem right for something > where incomplete implementations are common and expected to remain so. > > I think the right choice is either to say MAY with some accompanying words > urging people to do it, or to say SHOULD but accompany it with an escape > hatch like "to the extent that performance requirements permit". Another case where SHOULD is too strong and MAY is too weak. Perhaps we can split this hair and say SHOULD check that mandatory headers are present and MAY check the validity of any recognized header? -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From owner-ietf-usefor Tue Sep 28 14:28:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLSJld042034 for ; Tue, 28 Sep 2004 14:28:19 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SLSJWB042033 for ietf-usefor-skb; Tue, 28 Sep 2004 14:28:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from gatekeeper.tmr.com (mail.tmr.com [216.238.38.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLSIwX042027 for ; Tue, 28 Sep 2004 14:28:18 -0700 (PDT) (envelope-from news@gatekeeper.tmr.com) Received: (from news@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) id RAA28429; Tue, 28 Sep 2004 17:20:58 -0400 To: usenet-format@landfield.com, ietf-usefor@imc.org Path: not-for-mail From: Bill Davidsen Newsgroups: mail.usenet-format Subject: Thank you Date: Tue, 28 Sep 2004 17:29:36 -0400 Organization: TMR Associates, Inc Lines: 8 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gatekeeper.tmr.com 1096406458 28385 192.168.12.100 (28 Sep 2004 21:20:58 GMT) X-Complaints-To: abuse@tmr.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To whoever got my mail feed going. I have been told by majordome several time that I was subscribed, but until the 26th I wasn't getting anything unless it was sent by hand or perhaps to the old address. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From owner-ietf-usefor Tue Sep 28 14:20:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLK4mn041617 for ; Tue, 28 Sep 2004 14:20:04 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SLK47E041616 for ietf-usefor-skb; Tue, 28 Sep 2004 14:20:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from gatekeeper.tmr.com (mail.tmr.com [216.238.38.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLK3Ax041608 for ; Tue, 28 Sep 2004 14:20:03 -0700 (PDT) (envelope-from news@gatekeeper.tmr.com) Received: (from news@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) id RAA28388; Tue, 28 Sep 2004 17:12:43 -0400 To: usenet-format@landfield.com, ietf-usefor@imc.org Path: not-for-mail From: Bill Davidsen Newsgroups: mail.usenet-format Subject: Re: draft-ietf-usefor-usepro-01 Date: Tue, 28 Sep 2004 17:21:21 -0400 Organization: TMR Associates, Inc Lines: 41 Message-ID: References: <87ekkomuxa.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gatekeeper.tmr.com 1096405963 28385 192.168.12.100 (28 Sep 2004 21:12:43 GMT) X-Complaints-To: abuse@tmr.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en In-Reply-To: Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: >>A relaying agent MUST check the legality of all headers that it needs to >>use to do its job, namely at least Path, Date, Message-ID, Control if >>present, Injection-Date if present, and probably also Newsgroups. >>Demoting the rest to a SHOULD seems reasonable to me. Thinking about it, >>I see no reason to distinguish between mandatory and optional headers >>here, although perhaps I'm missing something. Depending on the relaying agent, I would expect the newsgroups and path headers to be checked, since those are needed for delivery. Beyond that anything is optional, control means nothing since group names need not be validated beyond seeing if we accept them and some peer wants them. And date? Not my exchange servers, I don't know your policy on age and it takes less time to send something old than make a decision on it. The correct age of most posts today is measured in ms, anything older is down in the noise. > I could easily be persuaded that the second paragraph and NOTE are > supefluous, but I would still be interested to hear whether relaying > agents actually do it or not. I could be convinced that checking that required headers are present, but the number of cases where that is not the case is vanishingly small. > > But the 1st paragraph seems to be an important part of the protocol, and > part of the machinery for avoiding loops. > In many ways an exchange server is like a router, doing no more checking that is required. Some do much more, some are not just doing exchange. I would rather not see a lot of mandated checking. Clearly a relaying agent may be more than an exchange server, and may do many thing beyond routing posts, like handling readers, spam filtering, etc. But it need not be, and I don't see any reason the standard should be changed to suggest otherwise. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From owner-ietf-usefor Tue Sep 28 14:39:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLd4QD042559 for ; Tue, 28 Sep 2004 14:39:04 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SLd41k042558 for ietf-usefor-skb; Tue, 28 Sep 2004 14:39:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLd3Rs042548 for ; Tue, 28 Sep 2004 14:39:04 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8SLctcC008723; Tue, 28 Sep 2004 17:38:55 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8SLctkc008722; Tue, 28 Sep 2004 17:38:55 -0400 (EDT) Date: Tue, 28 Sep 2004 17:38:54 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List cc: usenet-format@landfield.com Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 28 Sep 2004, Bill Davidsen wrote: > And date? Not my exchange servers, I don't know your policy on age and > it takes less time to send something old than make a decision on it... Note that history-based loop detection does not work if you don't verify that the date of the article is within your history list. Not doing loop detection is acceptable only in tightly controlled situations. Henry Spencer henry@spsystems.net From owner-ietf-usefor Tue Sep 28 14:58:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLwHK8043546 for ; Tue, 28 Sep 2004 14:58:17 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8SLwH0G043545 for ietf-usefor-skb; Tue, 28 Sep 2004 14:58:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from a.mail.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8SLwGjj043537 for ; Tue, 28 Sep 2004 14:58:16 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by a.mail.peak.org (8.12.10/8.12.8) with ESMTP id i8SLwE0l018041 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 28 Sep 2004 14:58:14 -0700 (PDT) Date: Tue, 28 Sep 2004 14:58:14 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let's see if the list is now open ... Under definitions: ] A "followup" is an article containing a response to the contents of ] an earlier article (the followup's "precursor"). ][Alternative definition, to bu ised if similar woprding is not added to ]the description of the References-header (a-6.10):] What is "to bu ised"? And no, the alternative text is not how followup is defined, since the ability of the poster to define how articles are displayed does not exist. Implying it does is incorrect. The alternative I suggested is still better. Why has it never appeared in any form? It took a bit of looking, but I finally found the meaning of a-6.10. It would have been much simpler had you just used [ARTICLE ...] as the reference. Under "defining the architecture": A "followup agent" is a combination of reading agent and posting agent that aids in the preparation and posting of a followup. [Alternative definition, to be used if the alternative definition for "followup" is used:] A "followup agent" is a combination of reading agent and posting agent that aids in the preparation and posting of a response intended as a followup to a precursor. The latter is a meaningless extension of the former. From what else does a followup come but a precursor? There is no reason for the 'alternative'. Under 7.6, we are still presented with this stentorian "to be taken from" wording, instead of the correct "copied from". Plus we have a lots of words in the initial paragraph that tell us that "taken from means copied from". If that is true, just say "copied from" and get rid of the extraneous redefinition. We still have the extraneous "by default". If the only action specified is to copy, I mean, "take", the content from the precursor's similar header, then that IS the default, and saying "by default" is meaningless. We are talking about the duties of the followup agent, which INCLUDES giving the article to the poster for his changes. There is no other action we specify for the followup agent, so there is nothing but "default". We also still have the extraneous "MAY be prepended" regarding "Re: " in the Subject. Since there is no prohibition, of course it MAY be prepended. And so may anything else. We need not say what MAY be prepended when the truth of the matter is ANYTHING MAY be prepended. Para. 4: "MUST be formed by...". Formed how? I think you mean something about it ought to contain the message id of the precursor. Perhaps you meant to say: 4. If the precursor did not have a References-header (a-6.10), the followup's References-content MUST be the MessageID-content of the precursor. Para. 5: The followup agent MUST mail the copy to the "copy-addr"? What if the USER decides to mail a copy somewhere else instead? Is the user to be told "FOAD"? If not, then the MUST is ridiculous. In fact, MUST is not appropriate for this, as RFC2119 tells us: there is no "interoperability" issue if the poster decides to send a copy somewhere by email other than the copy-addr. In fact, I would say it is not unreasonable for someone to always mail themselves a copy of anything they post; that would violate the MUST of this section. Similarly, Para. 1, the "MUST NOT" be posted is incorrect. How does a user override this prohibition? By saying "post this". How does he post an article without this? By saying "post this". Since both cases involve the same action, the MUST NOT is specious, and in any case does not involve any interoprability issue necessary for such language. Section 7.7: A reading agent downloads articles from a serving agent, as directed by the reader, and displays them (or processes them in some other manner). The article as displayed MUST be identical to the article as originally posted, subject only to limitations of the display device (such as availability of charsets, etc.). Whoa, doggies. Do you really intend to say that the article cannot have irrelevant or undesired headers left un-displayed? Do you really intend that the display of the PATH header MUST be as it was originally posted? Can the reading agent NOT rearrange headers so they are in a specific order, can it NOT change the date into the local reader's timezone for his convenience? Is displaying the article as originally posted the only thing we are going to allow reading agents to do? That's going to make a lot of existing code non-conforming. It MUST provide facilities for decoding any Content-Transfer-Encodings, encoded- words, etc., but SHOULD also have the capability to show the article exactly as received. No, you just said it MUST display the article "as originally posted", which is not the same as "exactly as received". How can it "SHOULD" do one thing when you've just said it MUST do another? 7.8. Duties of a Moderator A Moderator receives news articles by email, A moderator receives submissions by some means, not necessarily by email. Certainly someone has come up with, or will come up with, a web-based moderation system, and this definition would claim that the person we would normally call the moderator is not, because he did not receive the articles as specified. The next paragraph continues the error. If you want to list possible means of doing something, ok, but to make an exclusive list is wrong. From owner-ietf-usefor Tue Sep 28 17:15:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8T0FpNQ057732 for ; Tue, 28 Sep 2004 17:15:51 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8T0Fof0057731 for ietf-usefor-skb; Tue, 28 Sep 2004 17:15:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from b.mail.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8T0Fofd057721 for ; Tue, 28 Sep 2004 17:15:50 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by b.mail.peak.org (8.12.10/8.12.8) with ESMTP id i8T0ForP069106 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 28 Sep 2004 17:15:50 -0700 (PDT) Date: Tue, 28 Sep 2004 17:15:50 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Usefor/usepro conflicts. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bravo to USEFOR for having reached the correct style and length. Boo to USEPRO for contradicting USEFOR. USEPRO: redefines the term "sender" from what RFC2822 says, although the Sender header is supposed to be identical to that from RFC2822. There is no reason to define 'sender' in our draft. USEPRO: claims that "poster" is synonymous with RFC2822 "author", which it is not. "Poster" in USEPRO says "composes and submits", while RFC2822 limits "author" to the composer and clearly delineates between "author" and "sender". If we want to use "poster" as a synonym, fine, but to call it a synonym when it is not is incorrect. The word in standard usage implies "the person who posts", which is different than "the person who writes", so as a synonym, it belongs to "sender". This matches the actions of a "posting agent", and references in the drafts to the assistance posting agents give in posting the article (presumably given to the poster). This points out a contradiction in 7.5: Posting agents meant for use by ordinary posters SHOULD reject any attempt to post an article which cancels or Supersedes another article of which the poster is not the author. Using RFC2822's example, if John asks Michael to cancel the article he had Michael post, our posting agent is being told it SHOULD reject that action, since the poster (Michael) is not the author (John). This same section would have the operator of an incoming gateway unable to cancel articles from his gateway. USEFOR tells us that "Compliant software MUST support headers of at least 998 octets." USEPRO tells us "[relaying agents] MUST NOT refold any header (i.e. they must pass on the folding as received), even to remove FWS from a Newsgroups-header;". What does a relaying agent which has been written to support the minimum do when given an article by an agent written to support more than the minimum, and it has? I.e., A gives B an article with a header line of more than 998 octets? Both A and B are prohibited from refolding it. Does it get truncated or discarded? Would it be better to specify a maximum that is supported, so that everyone can know ahead of time what that maximum is and follow it? From owner-ietf-usefor Tue Sep 28 17:43:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8T0hhVI059998 for ; Tue, 28 Sep 2004 17:43:43 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8T0hhJr059997 for ietf-usefor-skb; Tue, 28 Sep 2004 17:43:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8T0hhh4059990 for ; Tue, 28 Sep 2004 17:43:43 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8T0hmbu018743 for ; Tue, 28 Sep 2004 17:43:48 -0700 Received: (qmail 19288 invoked by uid 1000); 29 Sep 2004 00:43:48 -0000 To: ietf-usefor@imc.org Subject: Re: Usefor/usepro conflicts. In-Reply-To: (John Stanley's message of "Tue, 28 Sep 2004 17:15:50 -0700 (PDT)") References: From: Russ Allbery Organization: The Eyrie Date: Tue, 28 Sep 2004 17:43:48 -0700 Message-ID: <873c117vln.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Stanley writes: > Bravo to USEFOR for having reached the correct style and length. I'd like to second this, btw, since I've not yet said this in public. The current USEFOR draft is exactly the sort of document that I feel we've needed all along, and I'm delighted to see it. This will be a valuable and helpful contribution to Usenet going forward. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Sep 28 17:49:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8T0n2gL060613 for ; Tue, 28 Sep 2004 17:49:02 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8T0n2R5060612 for ietf-usefor-skb; Tue, 28 Sep 2004 17:49:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8T0n2Au060605 for ; Tue, 28 Sep 2004 17:49:02 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8T0n7rn012393 for ; Tue, 28 Sep 2004 17:49:07 -0700 Received: (qmail 19324 invoked by uid 1000); 29 Sep 2004 00:49:07 -0000 To: ietf-usefor@imc.org Subject: Re: Usefor/usepro conflicts. In-Reply-To: (John Stanley's message of "Tue, 28 Sep 2004 17:15:50 -0700 (PDT)") References: From: Russ Allbery Organization: The Eyrie Date: Tue, 28 Sep 2004 17:49:07 -0700 Message-ID: <87y8it6gsc.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Stanley writes: > USEPRO: redefines the term "sender" from what RFC2822 says, although the > Sender header is supposed to be identical to that from RFC2822. There is > no reason to define 'sender' in our draft. > USEPRO: claims that "poster" is synonymous with RFC2822 "author", which > it is not. "Poster" in USEPRO says "composes and submits", while RFC2822 > limits "author" to the composer and clearly delineates between "author" > and "sender". If we want to use "poster" as a synonym, fine, but to call > it a synonym when it is not is incorrect. The word in standard usage > implies "the person who posts", which is different than "the person who > writes", so as a synonym, it belongs to "sender". This matches the > actions of a "posting agent", and references in the drafts to the > assistance posting agents give in posting the article (presumably given > to the poster). This makes sense to me. I think "poster" should in practice be used as a synonym for "sender" (and in fact we may not need the term at all; we could just use "sender" with the same definition as RFC 2822). > This points out a contradiction in 7.5: > Posting agents meant for use by ordinary posters SHOULD reject any > attempt to post an article which cancels or Supersedes another > article of which the poster is not the author. > Using RFC2822's example, if John asks Michael to cancel the article he > had Michael post, our posting agent is being told it SHOULD reject that > action, since the poster (Michael) is not the author (John). This same > section would have the operator of an incoming gateway unable to cancel > articles from his gateway. Yes, I believe the last clause should instead be something more like "which cancels or Supersedes an article from a different poster." > USEFOR tells us that "Compliant software MUST support headers of at > least 998 octets." USEPRO tells us "[relaying agents] MUST NOT refold > any header (i.e. they must pass on the folding as received), even to > remove FWS from a Newsgroups-header;". What does a relaying agent which > has been written to support the minimum do when given an article by an > agent written to support more than the minimum, and it has? I.e., A > gives B an article with a header line of more than 998 octets? Both A > and B are prohibited from refolding it. Does it get truncated or > discarded? It would have to be discarded (in other words, the article would be rejected by that agent), as truncation is also modification of the article. > Would it be better to specify a maximum that is supported, so that > everyone can know ahead of time what that maximum is and follow it? The supported maximum SHOULD be unlimited, but I'm not sure that we can flatly require that. Site policy on maximum article length will, of course, put a practical limit on header size, but it's hard to clearly state that in the standard. I don't believe it makes sense to specify any magic number other than 998. This is probably a situation where a posting agent SHOULD ensure that it generates no headers longer than 998 octets for maximum propagation. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Sep 28 19:12:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8T2Ch6U074966 for ; Tue, 28 Sep 2004 19:12:43 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8T2ChkG074965 for ietf-usefor-skb; Tue, 28 Sep 2004 19:12:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp812.mail.ukl.yahoo.com (smtp812.mail.ukl.yahoo.com [217.12.12.202]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8T2CgtY074923 for ; Tue, 28 Sep 2004 19:12:43 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-68-32.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.68.32 with poptime) by smtp812.mail.ukl.yahoo.com with SMTP; 29 Sep 2004 02:12:21 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8T2CAh03323; Wed, 29 Sep 2004 03:12:10 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20161 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Message fragmentation via message/partial and news-specific header fields Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4135EBE2.5040908@erols.com> Date: Tue, 28 Sep 2004 18:50:57 GMT Lines: 44 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4135EBE2.5040908@erols.com> Bruce Lilly writes: >4. a) During fragmentation, which message header fields are to be copied > to the enclosing message header, and which are to be preserved in > the enclosed first part message/partial header? b) Which fields > need to be copied to the headers of each of the subsequent message > fragments? >5. During reassembly, which fields of the first part message header > are to be retained, which are to be discarded; likewise for the > fields in the header of the enclosed first part? >Specifically regarding question 5, I expect that Approved, Newsgroups, >Distribution, Path, Followup-To, Expires, Summary, Organization, >Injection-Date, Injector-Info, and User-Agent can be safely copied to >the header of the first part and at least Approved, Newsgroups, >Distribution, Path, Injection-Date, and Expires should be copied to >the headers of subsequent parts. Copying these fields to the first >part is expected behavior when fragmenting per RFC 2046 as amended by >RFC 3798. I believe there may be difficulties with Control, >Supersedes, Archive, Posted-And-Mailed, Mail-Copies-To, and possibly >Complaints-To. Having thought about this some more, I have concluded that nearly all headers about which RFC 2046 says nothing specific should be copied to the headers of the first fragment (and mostly to the subsequent fragments too), because the reassembly process will then put them back in the article proper upon reassembly. The only ones which need to be placed in the enclosed header in the first fragment (in addition to those mentioned in RFC 2046) are those that might otherwise have been different in the various fragments. Lines is an obvious candidate here, and also User-Agent (since injectors are allowed to add bits to it). I see no reason to make exception for any others (and hence the changes we need to make to RFC 2046 are rather slight). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Sep 29 09:12:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TGCe8R011308 for ; Wed, 29 Sep 2004 09:12:40 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TGCeMx011307 for ietf-usefor-skb; Wed, 29 Sep 2004 09:12:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp812.mail.ukl.yahoo.com (smtp812.mail.ukl.yahoo.com [217.12.12.202]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8TGCb0j011225 for ; Wed, 29 Sep 2004 09:12:37 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host62-172-26-51.midband.mdip.bt.net) (ietf-usefor@imc.org@62.172.26.51 with poptime) by smtp812.mail.ukl.yahoo.com with SMTP; 29 Sep 2004 16:12:34 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8TGCHp07853; Wed, 29 Sep 2004 17:12:17 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20178 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: relay checking Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <87brfqdxll.fsf@windlord.stanford.edu> Date: Wed, 29 Sep 2004 14:26:38 GMT Lines: 27 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Bill Davidsen writes: >Another case where SHOULD is too strong and MAY is too weak. Perhaps we >can split this hair and say SHOULD check that mandatory headers are >present and MAY check the validity of any recognized header? Yes, that is more or less the position I had come to following this exchange. My draft text now reads as follows: 3. It SHOULD reject any article that does not have the correct mandatory headers (section a-5) present. 4. It MAY reject any article whose headers do not have legal contents. Any advance on that? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Sep 29 09:12:52 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TGCqlm011420 for ; Wed, 29 Sep 2004 09:12:52 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TGCpsu011419 for ietf-usefor-skb; Wed, 29 Sep 2004 09:12:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp812.mail.ukl.yahoo.com (smtp812.mail.ukl.yahoo.com [217.12.12.202]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8TGCoDW011353 for ; Wed, 29 Sep 2004 09:12:51 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host62-172-26-51.midband.mdip.bt.net) (ietf-usefor@imc.org@62.172.26.51 with poptime) by smtp812.mail.ukl.yahoo.com with SMTP; 29 Sep 2004 16:12:33 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8TGCIm07857; Wed, 29 Sep 2004 17:12:18 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20179 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Thank you Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: Date: Wed, 29 Sep 2004 14:28:21 GMT Lines: 19 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Bill Davidsen writes: >To whoever got my mail feed going. I have been told by majordome several >time that I was subscribed, but until the 26th I wasn't getting anything >unless it was sent by hand or perhaps to the old address. Is anyone else still having problems reading or posting to the new list? If not, I will stop posting to both. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Sep 29 09:13:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TGDFA5011603 for ; Wed, 29 Sep 2004 09:13:15 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TGDFox011602 for ietf-usefor-skb; Wed, 29 Sep 2004 09:13:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TGDEpx011585 for ; Wed, 29 Sep 2004 09:13:14 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) X-Gradwell-Debug: delivering mail for [ietf-usefor@imc.org] to mail.imc.org [208.184.76.43]:25 Received: from host62-172-26-51.midband.mdip.bt.net [62.172.26.51] by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.134) id 415adf18.00b287.04f; Wed, 29 Sep 2004 17:13:12 +0100 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8TGCHu07847; Wed, 29 Sep 2004 17:12:17 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20177 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: draft-ietf-usefor-usepro-01 Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <87ekkomuxa.fsf@windlord.stanford.edu> <87fz53mq54.fsf@windlord.stanford.edu> <87u0tidz4a.fsf@windlord.stanford.edu> Date: Wed, 29 Sep 2004 14:19:03 GMT Lines: 136 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <87u0tidz4a.fsf@windlord.stanford.edu> Russ Allbery writes: >I am very leery of statements like "parse to the extent necessary for >proper operation" in Usenet standards, since that concept cannot be >tightly specified. Yes, I would be too. It would need careful wording. But it may not be necessary, since the protocol requires you to do various things which obviously involve looking at the Path and Newsgroups headers, and if you find that those headers are unintelligible as regards what you need to do with them, then you are going to barf anyway without being told to. >Currently, INN can optionally ignore the Newsgroups header is ignored in >newgroup and rmgroup control messages by INN; such messages are treated as >if they were posted only to the affected newsgroup (and then propagated >using the special propagation rules for control messages, which ignore >newsgroup existence). I'm trying to remember previous discussions we had >on this topic; did we decide that was wrong? It doesn't make a lot of >sense to me right now that it's an option in INN, so it would be nice to >standardize one type of behavior or another. >RFC 1036 is silent on the subject and Son-of-1036 addresses it only in a >note: > NOTE: This check is significant because information on what > newsgroups a relayer wishes to receive is often stored at its > neighbors, who may not have up-to-date information or may > simplify the rules for implementation reasons. As a hedge > against the possibility of missed or delayed newgroup control > messages, relayers may wish to observe a notion of a newsgroup > subscription that is independent of the list of newsgroups > actually known to the relayer. This would permit reception and > relaying of articles in newsgroups that the relayer is not (yet) > aware of, subject to more general criteria indicating that they > are likely to be of interest. That NOTE has never made its way into our drafts, and it is not clear quite what it is suggesting. I think everyone accepts that a message posted to a group two minutes after that group was newgrouped is going to fail to appear in many places, though the flooding algorithm should get it to most of them eventually. >which is not specific to control messages. (This is interesting to me, >since I thought that special propagation of newgroup and rmgroup control >messages was long-standing established practice, but apparently it isn't >as much as I thought it was.) No, that has never been raised in this group before, to my knowledge. We did discuss the text that says control messages need to have a Newsgroups-header that will steer them to the proper places, and the text you see contains some tweaks arising from that. Now if INN has implemented some optimizations that will further improve the propagation of control messages, then good luck to it, but it has never been suggested that they should form part of this standard. >> Now the other paragraph from draft-13, which now appears in USEPRO >> section 6, says: >> Relaying Agents MUST propagate all control messages regardless of >> whether or not they are recognized or processed locally. >> That was intended to say that, even if your local policy is to ignore >> all newgroup message and all cancels, you are still supposed to >> propagate control messages normally for the benefit of neighbouring >> sites who are not so fussy. It certainly was not meant to say that you >> were to propagate them to peers who did not take the affected >> hierarchies at all. >I don't know where this sentence came from and it's never made any sense >to me. It's on my list of language that I believe should be striken from >the USEPRO document. I wrote it, and it was intended to say what I said in the previous paragraph. But its meaning is not clear, so I have rewritten it as follows (I have also included the preceding paragraph so you get the full context). The descriptions below set out REQUIREMENTS to be followed by sites that receive control messages and choose to honour them. However, nothing in these descriptions should be taken as overriding the right of any such site, in accordance with its local policy, to refuse to honour any particular control message, or to refer it to an administrator for approval (either as a class or on a case-by-case basis). Even if relaying agents do not, as a matter of local policy, intend to honour certain control messages, they MUST still propagate them in the normal manner. [The inclusion of that paragraph still remains under discussion.] Hopefully, it is now clearer what it means, so we can proceed to discuss whether we need it at all. Comments? >> If it is agreed that what I have just said is what we intend, >Certainly not. Relay agents are never required to propagate anything >whatsoever. Sure, but there is a general Caveat somewhere covering that, so we do not need to repeat it every time we say "Relaying agents MUST ...". >> We agreed long ago to attempt to make the Distribution header more >> effective by making sure it got looked at at the proper places. >Note that I do not consider myself to be part of this "we" at this time >and do not agree that we have consensus to do this. It was a long way back, but there was certainly a consensus at the time to try and make Distributions work. >I have no idea how CNews works in this area, but INN allows you to list >Path identities that, if found in incoming articles, should cause those >articles to be rejected. This configuration option is entirely >independent of your own Path identity and is intended specifically for >aliasing out sites or pseudosites. This facility has been in INN since >1.0, I believe. Ah! I had always understood, since the matter was first raised on the news.admin.net-abuse groups, that it came out of the normal processing of the Path header rather than on special code in transport agents. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Sep 29 09:13:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TGD6DM011517 for ; Wed, 29 Sep 2004 09:13:06 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TGD6NS011516 for ietf-usefor-skb; Wed, 29 Sep 2004 09:13:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TGD2Pp011476 for ; Wed, 29 Sep 2004 09:13:03 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) X-Gradwell-Debug: delivering mail for [ietf-usefor@imc.org] to mail.imc.org [208.184.76.43]:25 Received: from host62-172-26-51.midband.mdip.bt.net [62.172.26.51] by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.134) id 415adf0b.00b287.04d; Wed, 29 Sep 2004 17:12:59 +0100 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8TGCJT07861; Wed, 29 Sep 2004 17:12:19 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20180 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Usefor/usepro conflicts. Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: Date: Wed, 29 Sep 2004 14:57:53 GMT Lines: 64 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In John Stanley writes: >Bravo to USEFOR for having reached the correct style and length. >Boo to USEPRO for contradicting USEFOR. >USEPRO: redefines the term "sender" from what RFC2822 says, although the >Sender header is supposed to be identical to that from RFC2822. There is >no reason to define 'sender' in our draft. Currently, USEPRO is gathering together all the definitions that may be needed in both documents. When things have settled down, we will check which terms are still being used and which document (or even both) the definition belongs in. Your point about "sender" is noted. >USEPRO: claims that "poster" is synonymous with RFC2822 "author", which >it is not. "Poster" in USEPRO says "composes and submits", while RFC2822 >limits "author" to the composer and clearly delineates between "author" >and "sender". OK, I now have: A "poster" is the person or software that composes a possibly compliant article for submission to a posting agent. The poster is synonymous with [RFC 2822]'s author. > The word in standard usage >implies "the person who posts", which is different than "the person who >writes", so as a synonym, it belongs to "sender". But the term as widely used throughout Usenet is as I have defined it. >This points out a contradiction in 7.5: > Posting agents meant for use by ordinary posters SHOULD reject any > attempt to post an article which cancels or Supersedes another > article of which the poster is not the author. OK, I now have: Posting agents meant for use by ordinary posters SHOULD reject any attempt to post an article which cancels or Supersedes another article of which the poster is not the author or sender. >USEFOR tells us that "Compliant software MUST support headers of at least >998 octets." I think it needs to say that it MUST NOT generate longer than that, but MAY accept more. I shall look into that. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Sep 29 09:17:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TGHt48013071 for ; Wed, 29 Sep 2004 09:17:55 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TGHtiL013070 for ietf-usefor-skb; Wed, 29 Sep 2004 09:17:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TGHsna013064 for ; Wed, 29 Sep 2004 09:17:54 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: MrqM7bMnK3QbCCmA80CLf01H96HSujX8uZBHc6IdvbM= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CCh9R-0004Uq-00; Wed, 29 Sep 2004 12:17:57 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i8TGH09G022404(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Wed, 29 Sep 2004 12:17:16 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i8TGGjW5022398(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Wed, 29 Sep 2004 12:17:00 -0400 Message-ID: <415ABDFE.9080303@erols.com> Date: Wed, 29 Sep 2004 09:51:58 -0400 From: Bruce Lilly Reply-To: ietf-usefor Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us MIME-Version: 1.0 To: Alexey Melnikov CC: ietf-usefor Subject: Re: Issues with MIME-style parameters References: <412DEE02.1040604@erols.com> In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: [...] > So the > possibility that there may one day be parameters in the Path header has > changed nothing. [...] > why should it be used as an argument with > Injection-Date? The WG Chair declared the matter of so-called "MIME" parameters a closed issue on August 23, a full week before Charles' message was composed, and more than a month before it was posted to the mailing list. This is outrageous. Mr. Chairman, can we please settle this issue once and for all. From owner-ietf-usefor Wed Sep 29 11:06:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TI6xSI038906 for ; Wed, 29 Sep 2004 11:06:59 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TI6xwV038905 for ietf-usefor-skb; Wed, 29 Sep 2004 11:06:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from a.mail.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TI6w6c038842 for ; Wed, 29 Sep 2004 11:06:58 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by a.mail.peak.org (8.12.10/8.12.8) with ESMTP id i8TI6s0l019201 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 29 Sep 2004 11:06:54 -0700 (PDT) Date: Wed, 29 Sep 2004 11:06:54 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Re: Usefor/usepro conflicts. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Charles Lindsey" : I'm fascinated by a web page that contains explicit mailto links for deliberately invalid email addresses. >OK, I now have: > A "poster" is the person or software that composes a possibly > compliant article for submission to a posting agent. The poster is > synonymous with [RFC 2822]'s author. Nope. Wrong action. >> The word in standard usage >>implies "the person who posts", which is different than "the person who >>writes", so as a synonym, it belongs to "sender". >But the term as widely used throughout Usenet is as I have defined it. No. It may appear that way since USUALLY the person who writes the article is then the one that posts it, but the action of posting is clearly different than the action of writing, and the term "poster" means "one who posts", not "one who writes". When someone refers to the "original poster", they are correct, in most cases, only because the "original author" and "original poster" are the same person. I cannot speak for most people, but I expect that most people are able to differentiate the actions, but are simply loose in their usage of the term. This does not mean we ought to be. In fact, I think it would remove confusion were we to use the terms both as they are defined in simple engish and to isolate the actions of authoring and posting. For example, it makes the concept of "what happens in a moderated group" much clearer. It also makes the idea of what a "posting agent" does clearer. A "posting agent" need not be a text editor, only something that can take the result of a text editor and assist in posting it. From owner-ietf-usefor Wed Sep 29 11:37:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIb7Pb046160 for ; Wed, 29 Sep 2004 11:37:07 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TIb7Th046159 for ietf-usefor-skb; Wed, 29 Sep 2004 11:37:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIb6La046153 for ; Wed, 29 Sep 2004 11:37:06 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8TIb98J008999 for ; Wed, 29 Sep 2004 11:37:09 -0700 Received: (qmail 8363 invoked by uid 1000); 29 Sep 2004 18:37:09 -0000 To: usenet-format@landfield.com, ietf-usefor@imc.org Subject: Re: Usefor/usepro conflicts. In-Reply-To: (Charles Lindsey's message of "Wed, 29 Sep 2004 14:57:53 GMT") References: From: Russ Allbery Organization: The Eyrie Date: Wed, 29 Sep 2004 11:37:09 -0700 Message-ID: <87zn38syzu.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > John Stanley writes: >> USEPRO: claims that "poster" is synonymous with RFC2822 "author", which >> it is not. "Poster" in USEPRO says "composes and submits", while >> RFC2822 limits "author" to the composer and clearly delineates between >> "author" and "sender". > OK, I now have: > A "poster" is the person or software that composes a possibly > compliant article for submission to a posting agent. The poster is > synonymous with [RFC 2822]'s author. I believe this is wrong. Poster is synonymous with sender. >> The word in standard usage implies "the person who posts", which is >> different than "the person who writes", so as a synonym, it belongs to >> "sender". > But the term as widely used throughout Usenet is as I have defined it. I strongly disagree. Everywhere that I've seen poster used on Usenet in a context that drew the distinction between author and transmitter, poster referred to the person who injected the article, not the author. > OK, I now have: > Posting agents meant for use by ordinary posters SHOULD reject any > attempt to post an article which cancels or Supersedes another > article of which the poster is not the author or sender. That works. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Wed Sep 29 11:37:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIbuuE046278 for ; Wed, 29 Sep 2004 11:37:56 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TIbu4j046277 for ietf-usefor-skb; Wed, 29 Sep 2004 11:37:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIbt30046259 for ; Wed, 29 Sep 2004 11:37:55 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8TIbocC014414; Wed, 29 Sep 2004 14:37:50 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8TIbn5S014413; Wed, 29 Sep 2004 14:37:49 -0400 (EDT) Date: Wed, 29 Sep 2004 14:37:49 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List cc: usenet-format@landfield.com Subject: Re: relay checking In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Sep 2004, Charles Lindsey wrote: > 3. It SHOULD reject any article that does not have the correct > mandatory headers (section a-5) present. Why "correct"? That seems redundant, and it is bound to make people wonder whether it has some special significance. I'd take that word out. Otherwise, this seems okay. Henry Spencer henry@spsystems.net From owner-ietf-usefor Wed Sep 29 11:32:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIWRcD045207 for ; Wed, 29 Sep 2004 11:32:27 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TIWRth045206 for ietf-usefor-skb; Wed, 29 Sep 2004 11:32:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIWRVc045199 for ; Wed, 29 Sep 2004 11:32:27 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8TIWUV2002710 for ; Wed, 29 Sep 2004 11:32:30 -0700 Received: (qmail 8288 invoked by uid 1000); 29 Sep 2004 18:32:30 -0000 To: usenet-format@landfield.com, ietf-usefor@imc.org Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: (Charles Lindsey's message of "Wed, 29 Sep 2004 14:19:03 GMT") References: <87ekkomuxa.fsf@windlord.stanford.edu> <87fz53mq54.fsf@windlord.stanford.edu> <87u0tidz4a.fsf@windlord.stanford.edu> From: Russ Allbery Organization: The Eyrie Date: Wed, 29 Sep 2004 11:32:30 -0700 Message-ID: <878yatsz7l.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > Russ Allbery writes: >> which is not specific to control messages. (This is interesting to me, >> since I thought that special propagation of newgroup and rmgroup >> control messages was long-standing established practice, but apparently >> it isn't as much as I thought it was.) > No, that has never been raised in this group before, to my knowledge. I've raised it in this group in the past, but generally as part of other discussions of control message handling. > We did discuss the text that says control messages need to have a > Newsgroups-header that will steer them to the proper places, and the > text you see contains some tweaks arising from that. Control messages should not, in general, be crossposted to other newsgroups than they one that they affect. David Lawrence was the one who first taught me the problems caused by doing so. For example, when people form a habit of crossposting control messages to alt.config, someone limiting what hierarchies in alt.* they receive, they still ends up getting control messages for the hierarchies they don't want. Unfortunately, this bad habit is sufficiently established that I doubt we can really get people to stop (although relay agents could be configured to ignore the Newsgroups header entirely). I don't think it's a good idea to encourage it, though (but I remember the previous discussion and recognize that documenting it is to a degree documenting existing practice). However, relay agents that check the Newsgroups header against a list of valid groups *do* need to propagate control messages as if the group they were affecting existed. *That* behavior does need to be specified in the standard. This is independent of the question of whether one should ignore the Newsgroups header on newgroup and rmgroup control messages entirely. I'm surprised that it's not in son-of-1036 and doesn't appear to be in CNews, but perhaps both predate the understanding that this was the right thing to do. This has been implemented in INN since the 1.0 release in 1991. if (IsNewgroup && Approved) { /* Newgroup being sent to a group that doesn't exist. * Assume it is being sent to the group being created, * and send the group to all sites that would get the * group if it were created. */ ARTsendnewgroup(*groups); Accepted = TRUE; } (By INN 1.4 in 1993, and possibly earlier, this logic had been corrected to include rmgroups as well.) If relay agents don't implement this behavior, booster rmgroups are futile because they won't propagate past the first host that already removed the group and newgroups won't propagate through relay agents that don't act on them immediately and require that newsgroups exist before propagating messages. This is clearly wrong. > Now if INN has implemented some optimizations that will further improve > the propagation of control messages, then good luck to it, but it has > never been suggested that they should form part of this standard. Well, I don't believe that's correct, but there's no point in arguing about past history. I'm making that statement now. This should be part of the standard. > I wrote it, and it was intended to say what I said in the previous > paragraph. But its meaning is not clear, so I have rewritten it as > follows (I have also included the preceding paragraph so you get the > full context). > The descriptions below set out REQUIREMENTS to be followed by sites > that receive control messages and choose to honour them. However, > nothing in these descriptions should be taken as overriding the right > of any such site, in accordance with its local policy, to refuse to > honour any particular control message, or to refer it to an > administrator for approval (either as a class or on a case-by-case > basis). > Even if relaying agents do not, as a matter of local policy, intend > to honour certain control messages, they MUST still propagate them in > the normal manner. > [The inclusion of that paragraph still remains under discussion.] This is still not correct. This doesn't help with the issue addressed above in propagation of newgroup and rmgroup control messages and simply contradicts other portions of the document in a fashion that leaves one wondering what it's supposed to mean. Please, remove this language and just explain that newgroup and rmgroup control messages should always be propagated as if the group they're affecting exists, even if it does not. > Sure, but there is a general Caveat somewhere covering that, so we do > not need to repeat it every time we say "Relaying agents MUST ...". Given that relaying agents clearly do *not* have such a restriction, I think that we should view anywhere that the document states that relaying agents MUST propagate some article with a great deal of suspicion. At the least, every occurance of such language is an internal contradiction. If I recall correctly from my reading, there are rather few places where this contradiction occurs. This may be one of the only ones. > It was a long way back, but there was certainly a consensus at the time > to try and make Distributions work. Well, again, it's futile to argue about what happened years ago, but I don't believe a consensus continues to exist in this area. >> I have no idea how CNews works in this area, but INN allows you to list >> Path identities that, if found in incoming articles, should cause those >> articles to be rejected. This configuration option is entirely >> independent of your own Path identity and is intended specifically for >> aliasing out sites or pseudosites. This facility has been in INN since >> 1.0, I believe. > Ah! I had always understood, since the matter was first raised on the > news.admin.net-abuse groups, that it came out of the normal processing > of the Path header rather than on special code in transport agents. Nope. It was possible because of a pre-existing feature in INN (the path aliasing concept predates pseudo-sites by quite some time), but path aliasing is not really part of the normal processing of the Path header. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Wed Sep 29 11:35:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIZA7o045893 for ; Wed, 29 Sep 2004 11:35:10 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TIZA5r045892 for ietf-usefor-skb; Wed, 29 Sep 2004 11:35:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIZ9K3045881 for ; Wed, 29 Sep 2004 11:35:09 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8TIZCD4004936 for ; Wed, 29 Sep 2004 11:35:12 -0700 Received: (qmail 8322 invoked by uid 1000); 29 Sep 2004 18:35:12 -0000 To: usenet-format@landfield.com, ietf-usefor@imc.org Subject: Re: relay checking In-Reply-To: (Charles Lindsey's message of "Wed, 29 Sep 2004 14:26:38 GMT") References: <87brfqdxll.fsf@windlord.stanford.edu> From: Russ Allbery Organization: The Eyrie Date: Wed, 29 Sep 2004 11:35:12 -0700 Message-ID: <874qlgudnj.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > Yes, that is more or less the position I had come to following this > exchange. My draft text now reads as follows: > 3. It SHOULD reject any article that does not have the correct > mandatory headers (section a-5) present. > 4. It MAY reject any article whose headers do not have legal > contents. > Any advance on that? I thought Henry and I just agreed on language, and I'm curious as to why you decided to go with this language instead, from an article that predates the conclusion that Henry and I reached. Maybe it would be better to see if Bill agrees with Henry and I and if so, go with that language since it has more of a consensus? I don't see a lot of purpose served in distinguishing between existence and syntactic validity of headers. I think that makes the logic of the standard slightly more complex for no particularly clear reason. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Wed Sep 29 11:54:36 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIsa2e049209 for ; Wed, 29 Sep 2004 11:54:36 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TIsamN049208 for ietf-usefor-skb; Wed, 29 Sep 2004 11:54:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TIsZxr049202 for ; Wed, 29 Sep 2004 11:54:36 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8TIsacC014503; Wed, 29 Sep 2004 14:54:36 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8TIsarG014502; Wed, 29 Sep 2004 14:54:36 -0400 (EDT) Date: Wed, 29 Sep 2004 14:54:36 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List cc: usenet-format@landfield.com Subject: Re: relay checking In-Reply-To: <874qlgudnj.fsf@windlord.stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Sep 2004, Russ Allbery wrote: > I thought Henry and I just agreed on language, and I'm curious as to why > you decided to go with this language instead... > I don't see a lot of purpose served in distinguishing between existence > and syntactic validity of headers. I think that makes the logic of the > standard slightly more complex for no particularly clear reason. To clarify my own position on this... + I see a small benefit from insisting on presence of mandatory headers, but only a small one. It's unobjectionable but not very important. + I'm reluctant to demand full checking by relay agents which otherwise don't have reason to do it. Even SHOULD seems too strong a word here. + I would *like* to see relay agents not only permitted, but explicitly encouraged, to do as much checking as they feel they can. + I don't care deeply about the issue, and could live with any wording that permits full checking but doesn't require it. Henry Spencer henry@spsystems.net From owner-ietf-usefor Wed Sep 29 12:00:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TJ0TsR049787 for ; Wed, 29 Sep 2004 12:00:29 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TJ0TQj049785 for ietf-usefor-skb; Wed, 29 Sep 2004 12:00:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TJ0SYr049774 for ; Wed, 29 Sep 2004 12:00:28 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8TJ0TcC014554; Wed, 29 Sep 2004 15:00:29 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8TJ0T7E014553; Wed, 29 Sep 2004 15:00:29 -0400 (EDT) Date: Wed, 29 Sep 2004 15:00:28 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List cc: usenet-format@landfield.com Subject: control propagation (was Re: draft-ietf-usefor-usepro-01) In-Reply-To: <878yatsz7l.fsf@windlord.stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Sep 2004, Russ Allbery wrote: > ...I'm surprised that it's not in son-of-1036 and doesn't appear > to be in CNews, but perhaps both predate the understanding that this was > the right thing to do [1991]... > /* Newgroup being sent to a group that doesn't exist. > * Assume it is being sent to the group being created, > * and send the group to all sites that would get the > * group if it were created. */ C News is mostly a late-80s creation and was pretty much in maintenance mode by 1991, so if this wasn't prominently brought to our attention it could easily have been missed. And son-of-1036 reflected C News experience more than anything else. I don't recall this issue being raised when son-of-1036 came out, but there are probably some son-of-1036 responses in my files that never got dealt with properly, as I was most definitely in news burnout by that time. Henry Spencer henry@spsystems.net From owner-ietf-usefor Wed Sep 29 12:48:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TJmKZF057951 for ; Wed, 29 Sep 2004 12:48:20 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TJmKT9057950 for ietf-usefor-skb; Wed, 29 Sep 2004 12:48:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8TJmGt7057892 for ; Wed, 29 Sep 2004 12:48:17 -0700 (PDT) (envelope-from mail@sebastian-brocks.de) Received: (qmail 4892 invoked by uid 65534); 29 Sep 2004 19:48:08 -0000 Received: from xdsl-213-168-120-198.netcologne.de (EHLO awesome.sebastian-brocks.de) (213.168.120.198) by mail.gmx.net (mp011) with SMTP; 29 Sep 2004 21:48:08 +0200 X-Authenticated: #1840277 Received: from localhost (HELO [127.0.0.1]) [127.0.0.1] by awesome.sebastian-brocks.de (192.168.1.2) (userid 2) with ESMTP (Classic Hamster Version 2.0 Build 2.0.4.0) ; Wed, 29 Sep 2004 21:43:30 +0200 Message-ID: <290904.214330.mail.386.sebe@sebastian-brocks.de> Date: Wed, 29 Sep 2004 21:43:29 +0200 From: Sebastian Brocks User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7) Gecko/20040616 Thunderbird/0.7 Mnenhy/0.6.0.101 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: usenet-format@rkive.landfield.com, ietf-usefor@imc.org Subject: Re: Usefor/usepro conflicts. References: <87zn38syzu.fsf@windlord.stanford.edu> In-Reply-To: <87zn38syzu.fsf@windlord.stanford.edu> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0E0A4C1771E301790B1A8B87" X-Posting-Agent: Hamster/2.0.4.0 Lines: 34 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0E0A4C1771E301790B1A8B87 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit And now for the whole mailinglist (sorry Russ) Russ Allbery schrieb: > I strongly disagree. Everywhere that I've seen poster used on Usenet in a > context that drew the distinction between author and transmitter, poster > referred to the person who injected the article, not the author. In the case of "Followup-to: poster", certainly the author is meant, not the person who injected the article, isn't it? greetings, Sebastian --------------enig0E0A4C1771E301790B1A8B87 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBWxBhPlwI4sEdWTARAtPfAJ9e/iLsC4fCKypdSE3GqJ+VSG/b8ACgyg03 Ue2NRTThKJ8tLZg0zIYAbyI= =FQvt -----END PGP SIGNATURE----- --------------enig0E0A4C1771E301790B1A8B87-- From owner-ietf-usefor Wed Sep 29 13:48:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TKmcVe065424 for ; Wed, 29 Sep 2004 13:48:38 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8TKmcvf065423 for ietf-usefor-skb; Wed, 29 Sep 2004 13:48:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8TKmbic065414 for ; Wed, 29 Sep 2004 13:48:37 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i8TKmfns026532 for ; Wed, 29 Sep 2004 13:48:41 -0700 Received: (qmail 11535 invoked by uid 1000); 29 Sep 2004 20:48:41 -0000 To: usenet-format@rkive.landfield.com, ietf-usefor@imc.org Subject: Re: Usefor/usepro conflicts. In-Reply-To: <290904.214330.mail.386.sebe@sebastian-brocks.de> (Sebastian Brocks's message of "Wed, 29 Sep 2004 21:43:29 +0200") References: <87zn38syzu.fsf@windlord.stanford.edu> <290904.214330.mail.386.sebe@sebastian-brocks.de> From: Russ Allbery Organization: The Eyrie Date: Wed, 29 Sep 2004 13:48:41 -0700 Message-ID: <87hdpgpzrq.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sebastian Brocks writes: > And now for the whole mailinglist (sorry Russ) No problem. > Russ Allbery schrieb: >> I strongly disagree. Everywhere that I've seen poster used on Usenet >> in a context that drew the distinction between author and transmitter, >> poster referred to the person who injected the article, not the author. > In the case of "Followup-to: poster", certainly the author is meant, not > the person who injected the article, isn't it? Yeah, that's a very good point. That would indeed be an exception. (Well, more precisely speaking, the person in the From header is what's meant, but per RFC 2822 that should be the author, not the sender.) -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Wed Sep 29 19:13:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8U2D6pA008456 for ; Wed, 29 Sep 2004 19:13:06 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8U2D62L008455 for ietf-usefor-skb; Wed, 29 Sep 2004 19:13:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-2.gradwell.net (lon-mail-2.gradwell.net [193.111.201.126]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8U2D5EZ008441 for ; Wed, 29 Sep 2004 19:13:05 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) X-Gradwell-Debug: delivering mail for [ietf-usefor@imc.org] to mail.imc.org [208.184.76.43]:25 Received: from host81-144-74-58.midband.mdip.bt.net [81.144.74.58] by lon-mail-2.gradwell.net with esmtp (Gradwell gwh-smtpd 1.134) id 415b6bac.00d68f.00f; Thu, 30 Sep 2004 03:13:00 +0100 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i8U2CAk11136; Thu, 30 Sep 2004 03:12:10 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20181 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Content-Type: text/plain; charset=iso-8859-1 Message-ID: Content-Transfer-Encoding: 8bit X-Newsreader: NN version 6.5.2 (NOV) References: Mime-Version: 1.0 Date: Wed, 29 Sep 2004 18:07:36 GMT Lines: 183 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In John Stanley writes: >Under definitions: >] A "followup" is an article containing a response to the contents of >] an earlier article (the followup's "precursor"). >And no, the alternative text is not how followup is defined, since the >ability of the poster to define how articles are displayed does not exist. >Implying it does is incorrect. The alternative text, which you did not quote, is A "followup" is an article containing a response to the contents of an earlier article (its "precursor"), or which is otherwise intended to be grouped with that article for purposes of display (e.g. as part of a multipart posting such as a FAQ). No, the poster cannot "define" how articles are to be displayed, but he can indicate his intention in the matter by creating a suitable References-header, which is all that it says. The particular wording is based on a suggestion by Forrest, followed by various tweaks that were discussed here. It may yet get tweaked some more. The alternative text in a-6.10 is also due to be rewritten with similar wording. It is still an open issue as to which alternative wording gets used. >The alternative I suggested is still better. Why has it never appeared in >any form? You need to explain _why_ your wording is better. >Under "defining the architecture": > A "followup agent" is a combination of reading agent and posting > agent that aids in the preparation and posting of a followup. >[Alternative definition, to be used if the alternative definition for >"followup" is used:] > A "followup agent" is a combination of reading agent and posting > agent that aids in the preparation and posting of a response intended > as a followup to a precursor. >The latter is a meaningless extension of the former. From what else does >a followup come but a precursor? There is no reason for the 'alternative'. If you read the definition, some followups come from precursors and some come from the poster's display intentions. Followup agents are only designed to handle the first case, and don't have the necessary capability to handle the second. >Under 7.6, we are still presented with this stentorian "to be taken from" >wording, instead of the correct "copied from". Plus we have a lots of >words in the initial paragraph that tell us that "taken from means copied >from". If that is true, just say "copied from" and get rid of the >extraneous redefinition. No, "copy" would mean "copy the whole header". "Taken" means "copy the content of the header". >We still have the extraneous "by default". If we didn't say "by default", then there would be no latitude for the poster to override that default. > We are talking about the duties of the followup agent, which >INCLUDES giving the article to the poster for his changes. There is no >other action we specify for the followup agent, so there is nothing >but "default". It says nothing about "giving" the poster anything (that is up to the implementor of the followup agent). How the overriding is done is not specified (maybe the user edits those headers in the article he is given, maybe he is obliged to choose them before composing his article, maybe he is not given any article at all, because providing the precursor as a quotation is not obligatory). All that is clear is that if the poster omits to provide those headers, the "default" is what he gets. >We also still have the extraneous "MAY be prepended" regarding "Re: " in >the Subject. Since there is no prohibition, of course it MAY be prepended. >And so may anything else. We need not say what MAY be prepended when the >truth of the matter is ANYTHING MAY be prepended. NO! The whole point of that wording, and of the compromise thrashed out between those on my left and those on my right, was that in the *default* anything other than "Re: " SHOULD NOT be prepended. Remember Seth's four points? >Para. 4: "MUST be formed by...". Formed how? I think you mean something >about it ought to contain the message id of the precursor. Perhaps you >meant to say: > 4. If the precursor did not have a References-header (a-6.10), the > followup's References-content MUST be the MessageID-content of > the precursor. OK, I'll buy that. 4. If the precursor did not have a References-header (a-6.10), the followup's References-content MUST be copied from the Message-ID- content of the precursor. A followup to an article which already had a References-header MUST have a References-header comprising the precursor's References-content (subject to trimming as described below) followed by CFWS and the Message-ID-content of the precursor. >Para. 5: The followup agent MUST mail the copy to the "copy-addr"? What if >the USER decides to mail a copy somewhere else instead? Well the whole thing is already within the scope of "(and subject to manual override by the poster)", so that is covered. The various "SHOULD"s are meant to cover what the followup agent does in the absence of poster overrides (like mailing to the poster regardless without taking any notice of the header or asking the poster). They are SHOULD rather than MUST because the harm that ensues does not actually break anything - it just violates the whole intent of the header. But I take your point that a perverse followup agent which mails to the poster in spite of being told to use the copy-addr hardly merits a MUST, so I have changed it to SHOULD. Is the user to be >told "FOAD"? If not, then the MUST is ridiculous. In fact, MUST is not >appropriate for this, as RFC2119 tells us: there is no "interoperability" >issue if the poster decides to send a copy somewhere by email other than >the copy-addr. In fact, I would say it is not unreasonable for someone to >always mail themselves a copy of anything they post; that would violate >the MUST of this section. >Similarly, Para. 1, the "MUST NOT" be posted is incorrect. How does a >user override this prohibition? By saying "post this". How does he post >an article without this? Again, you have failed to distinguish when the poster chooses to override the default and when the followup agent (or rather its implementor) does something stupid. In this case, if the poster takes no action to override the default, then the agent MUST mail it to the poster and NOT post it. >Section 7.7: > A reading agent downloads articles from a serving agent, as directed > by the reader, and displays them (or processes them in some other > manner). The article as displayed MUST be identical to the article > as originally posted, subject only to limitations of the display > device (such as availability of charsets, etc.). >Whoa, doggies. Do you really intend to say that the article cannot have >irrelevant or undesired headers left un-displayed? Do you really intend >that the display of the PATH header MUST be as it was originally posted? >Can the reading agent NOT rearrange headers so they are in a specific >order, can it NOT change the date into the local reader's timezone for his >convenience? Is displaying the article as originally posted the only thing >we are going to allow reading agents to do? That's going to make a lot of >existing code non-conforming. OK, that is new wording, and it may yet disappear entirely. But the "MUST be identical" is indeed too severe. I have made a note to review it. >7.8. Duties of a Moderator > A Moderator receives news articles by email, >A moderator receives submissions by some means, not necessarily by email. >Certainly someone has come up with, or will come up with, a web-based >moderation system, ... No, the rule is that the injection agent MUST mail articles to the moderator (at his published submission address). If the moderator chooses to put all sorts of web sites and whatever behind that address, then that is up to him. Essentially, the boundary of "moderator" starts anywhere on his side of the submission address. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Thu Sep 30 06:52:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UDqgUu079905 for ; Thu, 30 Sep 2004 06:52:42 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8UDqghI079904 for ietf-usefor-skb; Thu, 30 Sep 2004 06:52:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from gatekeeper.tmr.com (mail.tmr.com [216.238.38.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UDqf3Z079886 for ; Thu, 30 Sep 2004 06:52:41 -0700 (PDT) (envelope-from news@gatekeeper.tmr.com) Received: (from news@localhost) by gatekeeper.tmr.com (8.9.0/8.9.0) id JAA05092; Thu, 30 Sep 2004 09:45:13 -0400 To: usenet-format@landfield.com, ietf-usefor@imc.org Path: not-for-mail From: Bill Davidsen Newsgroups: mail.usenet-format Subject: Re: draft-ietf-usefor-usepro-01 Date: Thu, 30 Sep 2004 09:53:57 -0400 Organization: TMR Associates, Inc Lines: 23 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: gatekeeper.tmr.com 1096551912 5091 192.168.12.100 (30 Sep 2004 13:45:12 GMT) X-Complaints-To: abuse@tmr.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en In-Reply-To: Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Henry Spencer wrote: > On Tue, 28 Sep 2004, Bill Davidsen wrote: > >>And date? Not my exchange servers, I don't know your policy on age and >>it takes less time to send something old than make a decision on it... > > > Note that history-based loop detection does not work if you don't verify > that the date of the article is within your history list. > > Not doing loop detection is acceptable only in tightly controlled > situations. Unless you assume some evil entity editing the Path header loop detection will work anyway, I would assume. I certainly won't send anything to a site in the Path, so the worst that could happen is that I would get something so old it expired out of history. And if I've seen it I don't expect to have my peers offer it again. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me From owner-ietf-usefor Thu Sep 30 15:52:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UMq7i2055933 for ; Thu, 30 Sep 2004 15:52:07 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8UMq704055932 for ietf-usefor-skb; Thu, 30 Sep 2004 15:52:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UMq6jJ055922 for ; Thu, 30 Sep 2004 15:52:07 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i8UMpscC022106; Thu, 30 Sep 2004 18:51:54 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i8UMpsOS022105; Thu, 30 Sep 2004 18:51:54 -0400 (EDT) Date: Thu, 30 Sep 2004 18:51:53 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List cc: usenet-format@landfield.com Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 30 Sep 2004, Bill Davidsen wrote: > > Note that history-based loop detection does not work if you don't verify > > that the date of the article is within your history list. > > Unless you assume some evil entity editing the Path header loop > detection will work anyway, I would assume. The Path-header check is just an optimization; loop detection is done by message ID and history list. Yes, mangled or reinitialized Path headers have been known to happen, especially when gateways get involved. > ...the worst that could happen is that I > would get something so old it expired out of history. Correct... and it is important that you recognize that case and discard the article, because loop detection is not reliable for it. Yes, loops with propagation delays longer than history-list retention times have been known to happen, especially when gateways or server outages get involved. > And if I've seen > it I don't expect to have my peers offer it again. This isn't a safe assumption unless local feed topology and relayer software are sufficiently tightly controlled that you can be sure that either (a) there are no feed loops, or (b) all loops contain at least one host which does full history/date-based loop detection. Henry Spencer henry@spsystems.net From owner-ietf-usefor Thu Sep 30 16:08:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UN8ZnA059698 for ; Thu, 30 Sep 2004 16:08:35 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8UN8ZxR059697 for ietf-usefor-skb; Thu, 30 Sep 2004 16:08:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from a.mail.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8UN8Zmn059687 for ; Thu, 30 Sep 2004 16:08:35 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by a.mail.peak.org (8.12.10/8.12.8) with ESMTP id i8UN8W0l032501 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 30 Sep 2004 16:08:33 -0700 (PDT) Date: Thu, 30 Sep 2004 16:08:32 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Charles Lindsey" : >The alternative text, which you did not quote, is Didn't need to quote it, I thought. >No, the poster cannot "define" how articles are to be displayed, but he >can indicate his intention in the matter ... If he cannot control it, his intention of controlling it is irrelevant. "I want ...". That's nice, but you don't get to say. Presenting it as if there was some mechanism, when none exists, just leads to foolish expectations. Just like the foolish expectations that copyright notices in the body of an article are going to change how Google or any other automated news processor is going to work. >>The alternative I suggested is still better. Why has it never appeared in >>any form? >You need to explain _why_ your wording is better. I have, many times. On the other hand, I've not seen any explanation of why your new alternative is better, it just appeared out of nowhere. And now I've explained why YOUR wording is wrong. >If you read the definition, some followups come from precursors and some >come from the poster's display intentions. Since the "display intentions" are irrelevant, that part of the definition is irrelevant. >Followup agents are only >designed to handle the first case, and don't have the necessary capability >to handle the second. Oh, please. Those people who are fooled into thinking they can control "this ought to appear next to that" find it trivial to use the "followup agent" to do that. Of course it has "the necessary capability", because the "necessary capability" is the main function OF the followup agent. I.e., copying the message id of what this new article is supposed to appear next to into the References header (which isn't defined as meaning "display this next to that" in the first place.) Saying that followup agents cannot handle the second case is simply ridiculous (but that still doesn't mean they can actually do what they are being told they can do.) >>We still have the extraneous "by default". >If we didn't say "by default", then there would be no latitude for the >poster to override that default. Untrue. What the followup agent does is not binding on the user who gets to modify what that agent does. We are specifying what the FOLLOWUP AGENT does, not the user, so the fact that we specify ONE ACTION for the followup agent makes that the DEFAULT action for that agent. It is specious to say that the ONE thing we say a followup agent does is the default. The "by default" is extraneous; it adds nothing to the text. Now, were we talking about the headers as they are injected, yes, by default the Subject header contains X, because at that point we are including the actions of the user and not just talking about what the followup agent is supposed to do. >It says nothing about "giving" the poster anything (that is up to the >implementor of the followup agent). So let's see if I understand your intention here. The followup agent "takes" the subject content of the precursor for the new subject, but nowhere is it intended or specified that this followup agent is supposed to allow the user to modify this content after it has done its one specified action? What malarky. If it doesn't say "the user gets to edit the followup agent's proto-article prior to posting" and you think that by not saying this we somehow prohibit it, then we damn well better say it just to keep silly interpretations like yours from being implemented in code (as if user revolt wouldn't stop it.) >How the overriding is done is not >specified (maybe the user edits those headers in the article he is given, What article is he given? You just said nothing is said about doing that, so apparently it is forbidden (as are all other things that are not said, which is why we have to say things like "MAY prepend the string..." when nothing else prohibits it.) >All that is clear is that if the poster >omits to provide those headers, the "default" is what he gets. Once again, he apparently doesn't "get" anything, since we allegedly don't say he is to be given anything. Twice now you've said that the user is given the article to modify, after telling me that he apparently isn't supposed to be given the article. The truth is, the draft says: However, posters MAY then override that default before posting if they so wish. This is AFTER the "default" (really, ONLY action specified) is taken by the followup agent. So, if the poster is not "given" anything to modify, how can he modify this "default" before posting? (You do understand that "then" indicates a chronological relationship between actions, don't you? You do understand that saying "do A then B" really does mean A gets done first, yes?) Further, a followup agent is a special case of a posting agent, which is clearly intended to assist the poster in creating a valid proto-article. If the followup/posting agent does not allow the poster to edit the Subject header, it cannot do that. While the subject header may be syntactically valid, it may not be contextually valid. And since the context may change long after any "default taking" of the precursor's subject content, this editing has to occur long after the taking. >OK, that is new wording, and it may yet disappear entirely. Why is entirely new wording appearing first in the drafts sent to the IETF and not in proposals discussed here? When did you say "I propose we put strict limits on how articles are to be displayed such that they MUST be displayed as they were posted"? Have I not brought this problem of surprise changes to your attention before? >>A moderator receives submissions by some means, not necessarily by email. >>Certainly someone has come up with, or will come up with, a web-based >>moderation system, ... >No, the rule is that the injection agent MUST mail articles to the >moderator (at his published submission address). Well, YOUR version of the draft says that, but that may not be the final version. I know of NO reason that email MUST be the means of forwarding. What interoperability issue is there that mandates such RFC2119 language? If a specific hierarchy decides that submissions are printed out on the company line printer and delivered to the moderator via FedEx, does news break? But this avoids the actual problem with the text I quoted. Your injection agent may mail what it wants to some address, but that address may be a pipeline into a web-based submission mechanism. The moderator never sees the submission until it hits the web. If there is a moderation panel, for example, they may all work via a web-based system of approval. Furthermore, there is no law of nature that says that all submissions to moderated groups must pass through an injection agent. I've mailed submissions directly, and many moderators publish submission addresses. Where do we get off trying to tell them they cannot accept material from a website or any other method of getting submissions they feel appropriate, including snail mail or cuniform tablets? >If the moderator chooses >to put all sorts of web sites and whatever behind that address, then that >is up to him. Yes, and it means that he is not receiving things by email. >Essentially, the boundary of "moderator" starts anywhere on >his side of the submission address. I've never seen software listed as the proposed moderator of a group. I have seen a person who intends to run software listed as the moderator, but that's not the same thing. From owner-ietf-usefor Sat Oct 2 08:26:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92FQjdm034867 for ; Sat, 2 Oct 2004 08:26:45 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92FQjJJ034866 for ietf-usefor-skb; Sat, 2 Oct 2004 08:26:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from colo.khms.westfalen.de (Debian-exim@colo.khms.westfalen.de [213.239.196.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92FQi4R034852 for ; Sat, 2 Oct 2004 08:26:44 -0700 (PDT) (envelope-from kaih@khms.westfalen.de) Received: from khms.vpn ([10.172.192.2]:59701 helo=khms.westfalen.de ident=Debian-exim) by colo.khms.westfalen.de with asmtp (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.34) id 1CDlkX-0007BR-Kt for ietf-usefor@imc.org; Sat, 02 Oct 2004 17:24:41 +0200 Received: from root (helo=khms.westfalen.de) by khms.westfalen.de with local-bsmtp (Exim 4.34) id 1CDlkM-0008Hb-Jz for ietf-usefor@imc.org; Sat, 02 Oct 2004 17:24:30 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh14 R/C435); 02 Oct 2004 17:02:27 +0200 Date: 02 Oct 2004 12:05:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ietf-usefor@imc.org Message-ID: <9I4pzYkXw-B@khms.westfalen.de> In-Reply-To: <878yatsz7l.fsf@windlord.stanford.edu> Subject: Re: draft-ietf-usefor-usepro-01 X-Mailer: CrossPoint v3.12d.kh14 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <878yatsz7l.fsf@windlord.stanford.edu> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: rra@stanford.edu (Russ Allbery) wrote on 29.09.04 in <878yatsz7l.fsf@windlord.stanford.edu>: > Control messages should not, in general, be crossposted to other > newsgroups than they one that they affect. That never seemed right to me. Surely group-list changing ones should be crossposted to a designated control message group for the hierarchy in question. >David Lawrence was the one who > first taught me the problems caused by doing so. For example, when people > form a habit of crossposting control messages to alt.config, someone > limiting what hierarchies in alt.* they receive, they still ends up > getting control messages for the hierarchies they don't want. Frankly, I have trouble coming up with a reason why that's bad. From where I sit, that's an intended result. MfG Kai From owner-ietf-usefor Sat Oct 2 12:26:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92JQ4F0050330 for ; Sat, 2 Oct 2004 12:26:04 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92JQ4uV050329 for ietf-usefor-skb; Sat, 2 Oct 2004 12:26:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92JQ3D5050323 for ; Sat, 2 Oct 2004 12:26:03 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i92JQ73o014843 for ; Sat, 2 Oct 2004 12:26:07 -0700 Received: (qmail 9107 invoked by uid 1000); 2 Oct 2004 19:26:07 -0000 To: ietf-usefor@imc.org Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: <9I4pzYkXw-B@khms.westfalen.de> (Kai Henningsen's message of "02 Oct 2004 12:05:00 +0200") References: <878yatsz7l.fsf@windlord.stanford.edu> <9I4pzYkXw-B@khms.westfalen.de> From: Russ Allbery Organization: The Eyrie Date: Sat, 02 Oct 2004 12:26:07 -0700 Message-ID: <87acv4rkfk.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Kai Henningsen writes: > rra@stanford.edu (Russ Allbery) wrote: >> Control messages should not, in general, be crossposted to other >> newsgroups than they one that they affect. > That never seemed right to me. Surely group-list changing ones should be > crossposted to a designated control message group for the hierarchy in > question. Why? What purpose does this serve? >> David Lawrence was the one who first taught me the problems caused by >> doing so. For example, when people form a habit of crossposting >> control messages to alt.config, someone limiting what hierarchies in >> alt.* they receive, they still ends up getting control messages for the >> hierarchies they don't want. > Frankly, I have trouble coming up with a reason why that's bad. From > where I sit, that's an intended result. Why? If I have all of my peers sending me alt.*,@alt.binaries.*, I don't want to get control messages for alt.binaries.* either. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Sun Oct 3 12:57:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93Jv5Me050324 for ; Sun, 3 Oct 2004 12:57:05 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i93Jv5NN050323 for ietf-usefor-skb; Sun, 3 Oct 2004 12:57:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93Jv4xZ050312 for ; Sun, 3 Oct 2004 12:57:04 -0700 (PDT) (envelope-from sethb@panix.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 14419981EE for ; Sun, 3 Oct 2004 15:57:04 -0400 (EDT) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i93Jv4o25662; Sun, 3 Oct 2004 15:57:04 -0400 (EDT) Date: Sun, 3 Oct 2004 15:57:04 -0400 (EDT) Message-Id: <200410031957.i93Jv4o25662@panix5.panix.com> From: Seth Breidbart To: ietf-usefor@imc.org In-reply-to: (message from John Stanley on Thu, 30 Sep 2004 16:08:32 -0700 (PDT)) Subject: Re: References: Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Stanley wrote: > "Charles Lindsey" : >>No, the poster cannot "define" how articles are to be displayed, but he >>can indicate his intention in the matter ... > > If he cannot control it, his intention of controlling it is > irrelevant. Not to me, as a reader. While I don't _have to_ display anything the way the poster wants, I will often _choose_ to _defer to_ the poster's wishes. > "I want ...". That's nice, but you don't get to say. Presenting it > as if there was some mechanism, when none exists, just leads to > foolish expectations. An expectation that is fulfilled, say, 98% of the time is far from "foolish". >>If you read the definition, some followups come from precursors and some >>come from the poster's display intentions. > > Since the "display intentions" are irrelevant, that part of the > definition is irrelevant. The "display intentions" are not irrelevant to me, as a reader, because my newsreader adheres to them 99.9+% of the time (that is, I seldom bother to override its defaults). Seth From owner-ietf-usefor Sun Oct 3 13:18:22 2004 Received: from taxis.dwdata.com (taxis.dwdata.com [216.33.93.235]) by above.proper.com (8.12.11/8.12.9) with SMTP id i93KIMb3051659 for ; Sun, 3 Oct 2004 13:18:22 -0700 (PDT) (envelope-from petergordon@zoomshare.com) Received: (qmail 96329 invoked by uid 832822484); 3 Oct 2004 19:23:13 -0000 Message-ID: <20041003192313.96328.qmail@taxis.dwdata.com> From: "petergordon" Date: Sun, 03 Oct 2004 14:23:13 -0500 (CDT) To: Subject: BUSINESS PROPOSAL!! References: In-Reply-To: X-Mailer: oMail 0.98.4 - http://webmail.omnis.ch X-IPAddress: 82.169.144.10 X-Sender: petergordon@zoomshare.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mr.Peter Gordons Imperial Bank. 140 Boeing Road East Elma Park Edenvale Gauteng 1610 Republic Of South Africa. Fax:+27:732:632:745 email:petergordons@netscape.net Dear Sir/Madam, I am Mr.Peter Gordon, Head: Enterprise Wide Risk and member of the executive and risk committees. of Imperial Bank, South Africa. This is an urgent and very confidential business proposition. On June 6, 2000,a Foreign Oil consultant/contractor with the South African Institute of Mining and Metallurgy, Mr.Stephen Garrick made a numbered time(Fixed) Deposit for twelve calendar months, valued at US$26,500,000.00,(Twenty-six Million, five hundred thousand Dollars). Upon maturity, I sent a routine notification to his forwarding address but got no reply. After a month, we sent a reminder and finally we discovered from his contract employers, the National Petroleum Corporation that Mr.Stephen Garrick died from an automobile accident. On further investigation, I found out that he died without making a "WILL", and all attempts to trace his next of kin was fruitless. I therefore made further investigation and discovered that Mr. Stephen Garrick did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$26,500,000.00 has carefully been fixed in my bank for safekeeping. No one will ever come forward to claim it. According to South African Law, at the expiration of 5 (five) years, the money will revert to the ownership of the Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you as a Foreigner to stand in as the owner of the money which was fixed deposited in my bank. I am writing you because I as a public servant, I cannot operate a foreign account. I want to present you as the owner of the funds so you can be able to claim them with the help of my attorney. This is simple. I will like you to provide immediately your full names,telephone/fax numbers and address, so that the Attorney will prepare the necessary documents which will put you in place as the beneficiary of the funds. The money will be moved out for us to share in the ratio of 80% for me and 20% for you. The paperwork for this transaction will be done by the Attorney If you are interested, please reply immediately via my email address and Upon your response, I shall then provide you with more details that will help you understand the transaction. Please observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in real estate within your country. Due to the nature of confidentiality in this Transaction our communication can only be via email and fax mostly. Awaiting your urgent reply via email. Thanks and my regards. Mr.Peter Gordon. PLEASE REPLY TO my FAX NUMBER OR EMAIL:petergordons@netscape.net From owner-ietf-usefor Mon Oct 4 07:14:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94EERWw038787 for ; Mon, 4 Oct 2004 07:14:27 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94EER5F038786 for ietf-usefor-skb; Mon, 4 Oct 2004 07:14:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94EEQlh038780 for ; Mon, 4 Oct 2004 07:14:26 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 15:14:26 +0100 Message-ID: <41615AC2.7030205@isode.com> Date: Mon, 04 Oct 2004 15:14:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor Subject: Re: Issues with MIME-style parameters References: <412DEE02.1040604@erols.com> <415ABDFE.9080303@erols.com> In-Reply-To: <415ABDFE.9080303@erols.com> Content-Type: multipart/alternative; boundary="------------020007080808030900050305" Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --------------020007080808030900050305 Content-type: text/plain; charset="us-ascii" Bruce Lilly wrote: >Charles Lindsey wrote: > >[...] > >>So the >>possibility that there may one day be parameters in the Path header has >>changed nothing. >> >[...] > > >>why should it be used as an argument with >>Injection-Date? >> >> > >The WG Chair declared the matter of so-called "MIME" parameters >a closed issue on August 23, a full week before Charles' message >was composed, and more than a month before it was posted to the >mailing list. This is outrageous. Mr. Chairman, can we please >settle this issue once and for all. > Just to clarify, based on WG feedback, I've declared that there is no WG support for generic MIME-type parameters applicable to all *existing* and new headers. A new header can be designed to be extensible (including something that looks like MIME-style parameter), however the WG need to understand all "for" and "against" introducing extensibility for the header. Alexey --------------020007080808030900050305 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Bruce Lilly wrote:
Charles Lindsey wrote:

[...]  
So the
possibility that there may one day be parameters in the Path header has
changed nothing. 
[...]
  
why should it be used as an argument with
Injection-Date?
    

The WG Chair declared the matter of so-called "MIME" parameters
a closed issue on August 23, a full week before Charles' message
was composed, and more than a month before it was posted to the
mailing list.  This is outrageous.  Mr. Chairman, can we please
settle this issue once and for all.
Just to clarify, based on WG feedback, I've declared that there is no WG support for generic MIME-type parameters applicable to all *existing* and new headers.

A new header can be designed to be extensible (including something that looks like MIME-style parameter), however the WG need to understand all "for" and "against" introducing extensibility for the header.

Alexey

--------------020007080808030900050305-- From owner-ietf-usefor Mon Oct 4 08:31:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94FV2mt044304 for ; Mon, 4 Oct 2004 08:31:02 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94FV2sp044303 for ietf-usefor-skb; Mon, 4 Oct 2004 08:31:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from a.mail.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94FV2xr044289 for ; Mon, 4 Oct 2004 08:31:02 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by a.mail.peak.org (8.12.10/8.12.8) with ESMTP id i94FUv0l030289 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 4 Oct 2004 08:30:57 -0700 (PDT) Date: Mon, 4 Oct 2004 08:30:57 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Seth Breidbart : >> If he cannot control it, his intention of controlling it is >> irrelevant. >Not to me, as a reader. If you think you have some control, then you are ill informed. What you intend is nice, and it is nice that you think it is important to you, but your intention really is irrelevant, since there is no means for you to accomplish what you want. >While I don't _have to_ display anything the >way the poster wants, I will often _choose_ to _defer to_ the poster's >wishes. It's nice that you "choose" to defer, since you actually have no choice in the matter. If the user wants to display your message in 1 pt font in red blinking letters, there isn't anything you can do to stop it. >An expectation that is fulfilled, say, 98% of the time is far from >"foolish". An expectation based on SWAG numbers, with no mechanism to accomplish it in the first place, is foolish. >The "display intentions" are not irrelevant to me, as a reader, That's nice. Too bad you don't have a choice. >because my newsreader adheres to them 99.9+% of the time (that is, I >seldom bother to override its defaults). Oh, I see where you get your SWAG number. YOUR newsreader shows you things the way YOU want them 99% of the time, thus everyone elses shows them things the way you want them 99% of the time. Sorry, no. I bet mine doesn't show them your way even 1% of the time. Your average is down to 50%, and that's just after considering two readers. The fact remains: poster "intentions" on how messages are displayed, or in what order, are irrelevant simply because the expectation of control is specious. Better to teach people the truth than give them false expectations, which will lead them to come here expecting their intentions to be codified in the standard, as we are now seeing happen. From owner-ietf-usefor Mon Oct 4 10:11:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94HBcAm065242 for ; Mon, 4 Oct 2004 10:11:38 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94HBcCm065241 for ietf-usefor-skb; Mon, 4 Oct 2004 10:11:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94HBage065231 for ; Mon, 4 Oct 2004 10:11:37 -0700 (PDT) (envelope-from sethb@panix.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 0AB1D98203 for ; Mon, 4 Oct 2004 13:11:39 -0400 (EDT) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p2-a/8.8.8/PanixN1.1) id i94HBdf06942; Mon, 4 Oct 2004 13:11:39 -0400 (EDT) Date: Mon, 4 Oct 2004 13:11:39 -0400 (EDT) Message-Id: <200410041711.i94HBdf06942@panix5.panix.com> From: Seth Breidbart To: ietf-usefor@imc.org In-reply-to: (message from John Stanley on Mon, 4 Oct 2004 08:30:57 -0700 (PDT)) Subject: Re: References: Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John Stanley wrote: > Seth Breidbart : >>> If he cannot control it, his intention of controlling it is >>> irrelevant. > >>Not to me, as a reader. > > If you think you have some control, then you are ill informed. What part of "me, as a reader" didn't you understand? The last word? > What you intend is nice, and it is nice that you think it is > important to you, but your intention really is irrelevant, since > there is no means for you to accomplish what you want. When I post, I _intend_ that others read my post. Obviously, I can't enforce that; does that mean that transmission of posts should be blocked entirely? When I post a followup in response to a specific article, with a References header, am I indicating that my article is part of a thread, or am I indicating my intention that my article be treated as part of that thread? >>While I don't _have to_ display anything the way the poster wants, I >>will often _choose_ to _defer to_ the poster's wishes. > > It's nice that you "choose" to defer, since you actually have no choice > in the matter. As the _reader_, I have _all_ the choice. >>The "display intentions" are not irrelevant to me, as a reader, > > That's nice. Too bad you don't have a choice. But I do. >>because my newsreader adheres to them 99.9+% of the time (that is, I >>seldom bother to override its defaults). > > Oh, I see where you get your SWAG number. YOUR newsreader shows you things > the way YOU want them 99% of the time, thus everyone elses shows them > things the way you want them 99% of the time. No, their newsreader shows them things the way they want. > Sorry, no. I bet mine doesn't show them your way even 1% of the > time. Your average is down to 50%, and that's just after considering > two readers. Really? If I put a References header into a new article, your newsreader (as you have it configured) won't show my article as part of the thread containing the messages referred to in that References header? And you think a significant fraction of other readers have their newsreaders configured similarly? > The fact remains: poster "intentions" on how messages are displayed, > or in what order, are irrelevant simply because the expectation of > control is specious. Let's remove the Newsgroups header, too, then, for the same reason. Seth From owner-ietf-usefor Mon Oct 4 11:25:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94IPmLv082795 for ; Mon, 4 Oct 2004 11:25:48 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94IPm0W082794 for ietf-usefor-skb; Mon, 4 Oct 2004 11:25:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from kosat.consultit.no (sam.consultit.no [80.203.206.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94IPk1N082774 for ; Mon, 4 Oct 2004 11:25:47 -0700 (PDT) (envelope-from eivindt@multinet.no) Received: from tagseth-trd.consultit.no (182.80-202-209.nextgentel.com [80.202.209.182]) by kosat.consultit.no (Postfix) with SMTP id DCEDC7D3C for ; Mon, 4 Oct 2004 20:25:34 +0200 (CEST) Received: by tagseth-trd.consultit.no (sSMTP sendmail emulation); Mon, 4 Oct 2004 20:25:22 +0200 Date: Mon, 4 Oct 2004 20:25:22 +0200 From: Eivind Tagseth To: ietf-usefor@imc.org Subject: Re: Message-ID: <20041004182521.GA28583@tagseth-trd.consultit.no> Mail-Followup-To: Eivind Tagseth , ietf-usefor@imc.org References: <200410041711.i94HBdf06942@panix5.panix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410041711.i94HBdf06942@panix5.panix.com> User-Agent: Mutt/1.5.6i Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Seth Breidbart [2004-10-04 13:11:39 -0400]: > John Stanley wrote: > > What you intend is nice, and it is nice that you think it is > > important to you, but your intention really is irrelevant, since > > there is no means for you to accomplish what you want. > When I post a followup in response to a specific article, with a > References header, am I indicating that my article is part of a > thread, or am I indicating my intention that my article be treated as > part of that thread? You are indicating that your article and the article with the last message id in the References header has a child-parent relationship. Furthermore, you're saying that all message ids in the References header have an ancestry relationship to your article. And you're saying that the very first message id in the References header is the very first message of this ancestry lineage. I guess this isn't quite correct, as the References header may also contain message ids that are not decendants of the very first article (when replying to two different articles as once), or doesn't this ever happen? Isn't this what the references header really means? How to display the article in a news reader isn't really that relevant, the natural way to display articles having such relations comes from the meaning of the header, not vice versa. Are we really not able to describe the semantics of the references header without doing it backwards by describing the ui rather than the meaning. Eivind From owner-ietf-usefor Mon Oct 4 13:14:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94KEkRn010341 for ; Mon, 4 Oct 2004 13:14:46 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94KEkt6010340 for ietf-usefor-skb; Mon, 4 Oct 2004 13:14:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94KEjpX010328 for ; Mon, 4 Oct 2004 13:14:46 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from [213.116.56.3] (1Cust3.tnt104.lnd4.gbr.da.uu.net [213.116.56.3]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 21:14:47 +0100 Message-ID: <4161AC98.1010000@isode.com> Date: Mon, 04 Oct 2004 21:03:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor Subject: Standardize Complaints-To as deployed? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I would like to poll the WG about fate of the Complaints-To header. I would ask people to voice their opinion about the following question: should Complaints-To be standardized as described in section 6.20 of draft-ietf-usefor-article-13.txt? If the answer to this question is "yes", than it will be added to draft-ietf-usefor-usefor-01.txt. Otherwise I will reopen the discussion whether it should be an email address or an URL. Thanks, Alexey From owner-ietf-usefor Mon Oct 4 14:30:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94LUciJ020660 for ; Mon, 4 Oct 2004 14:30:38 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94LUc21020659 for ietf-usefor-skb; Mon, 4 Oct 2004 14:30:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94LUbT7020651 for ; Mon, 4 Oct 2004 14:30:37 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i94LUddn010912 for ; Mon, 4 Oct 2004 14:30:40 -0700 Received: (qmail 5251 invoked by uid 1000); 4 Oct 2004 21:30:39 -0000 To: ietf-usefor Subject: Re: Standardize Complaints-To as deployed? In-Reply-To: <4161AC98.1010000@isode.com> (Alexey Melnikov's message of "Mon, 04 Oct 2004 21:03:36 +0100") References: <4161AC98.1010000@isode.com> From: Russ Allbery Organization: The Eyrie Date: Mon, 04 Oct 2004 14:30:39 -0700 Message-ID: <877jq6rx1c.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alexey Melnikov writes: > I would like to poll the WG about fate of the Complaints-To header. I > would ask people to voice their opinion about the following question: > should Complaints-To be standardized as described in section 6.20 of > draft-ietf-usefor-article-13.txt? > If the answer to this question is "yes", than it will be added to > draft-ietf-usefor-usefor-01.txt. Otherwise I will reopen the discussion > whether it should be an email address or an URL. I don't believe it should be standardized as described there. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Mon Oct 4 14:35:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94LZhaj020971 for ; Mon, 4 Oct 2004 14:35:43 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94LZhFw020970 for ietf-usefor-skb; Mon, 4 Oct 2004 14:35:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94LZgtb020962 for ; Mon, 4 Oct 2004 14:35:43 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i94LZecC015255; Mon, 4 Oct 2004 17:35:40 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i94LZeks015254; Mon, 4 Oct 2004 17:35:40 -0400 (EDT) Date: Mon, 4 Oct 2004 17:35:40 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List Subject: Re: Standardize Complaints-To as deployed? In-Reply-To: <4161AC98.1010000@isode.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 4 Oct 2004, Alexey Melnikov wrote: > I would like to poll the WG about fate of the Complaints-To header. > I would ask people to voice their opinion about the following question: > should Complaints-To be standardized as described in section 6.20 of > draft-ietf-usefor-article-13.txt? 6.20 of article-13 looks good to me, let's do it that way. Henry Spencer henry@spsystems.net From owner-ietf-usefor Mon Oct 4 14:46:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94LkWbP021661 for ; Mon, 4 Oct 2004 14:46:32 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94LkWOi021660 for ietf-usefor-skb; Mon, 4 Oct 2004 14:46:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from b.mail.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94LkVPc021639 for ; Mon, 4 Oct 2004 14:46:31 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by b.mail.peak.org (8.12.10/8.12.8) with ESMTP id i94LkTZh087133 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 4 Oct 2004 14:46:29 -0700 (PDT) Date: Mon, 4 Oct 2004 14:46:29 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Seth Breidbart : >While I don't _have to_ display anything the >way the poster wants, I will often _choose_ to _defer to_ the poster's >wishes. Sorry, the first time I read that I saw it as choosing to defer to the reader's wishes. The fact is, the only "poster's wish" that you can know is that he thinks some article is related to another. Whether that means he wants it displayed next to or above is difficult to tell, since there is no definition to guide anyone. You can defer to what you think the poster wants for display, but you are just guessing, and in any case, the poster doesn't have the control that this draft is trying to imply he has. From owner-ietf-usefor Mon Oct 4 14:52:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94LqeHG022025 for ; Mon, 4 Oct 2004 14:52:40 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94Lqe9H022024 for ietf-usefor-skb; Mon, 4 Oct 2004 14:52:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94Lqd30022018 for ; Mon, 4 Oct 2004 14:52:40 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from [213.116.60.52] (1Cust52.tnt106.lnd4.gbr.da.uu.net [213.116.60.52]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 22:52:28 +0100 Message-ID: <4161C5F0.7000703@isode.com> Date: Mon, 04 Oct 2004 22:51:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor Subject: USEFOR WG meeting in Washington, DC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is there any interest to have an official WG slot at Washington, DC IETF? Please, let me know. Alexey From owner-ietf-usefor Mon Oct 4 15:08:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94M82Zr022850 for ; Mon, 4 Oct 2004 15:08:02 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94M82f4022849 for ietf-usefor-skb; Mon, 4 Oct 2004 15:08:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from a.mail.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94M823R022841 for ; Mon, 4 Oct 2004 15:08:02 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by a.mail.peak.org (8.12.10/8.12.8) with ESMTP id i94M810l095812 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 4 Oct 2004 15:08:02 -0700 (PDT) Date: Mon, 4 Oct 2004 15:08:01 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Seth Breidbart : >What part of "me, as a reader" didn't you understand? The last word? Already covered. And still, your deference to the poster is well and good, but guessing nonetheless, and not in any way universal. >When I post, I _intend_ that others read my post. Obviously, I can't >enforce that; Glad to see left field is still alive. The issue at hand is not whether they read your article or not, it is how your article is displayed when they read it. Do you have control over that? No. Is your "intent" worth much, given you have no control and no mechanism defined for describing your intent? No. >When I post a followup in response to a specific article, with a >References header, am I indicating that my article is part of a >thread, or am I indicating my intention that my article be treated as >part of that thread? Irrelevant question, since the issue is not "is this part of a thread", but "do you have control over how it is displayed?" >> Oh, I see where you get your SWAG number. YOUR newsreader shows you things >> the way YOU want them 99% of the time, thus everyone elses shows them >> things the way you want them 99% of the time. >No, their newsreader shows them things the way they want. Yes, exactly. So your control over how they see things is nada, and your intentions about same are meaningless. >Really? If I put a References header into a new article, your >newsreader (as you have it configured) won't show my article as part >of the thread containing the messages referred to in that References >header? It shows things the way I specify. If I say not to, you have no control. You certainly can't say "show this next to that". >> The fact remains: poster "intentions" on how messages are displayed, >> or in what order, are irrelevant simply because the expectation of >> control is specious. >Let's remove the Newsgroups header, too, then, for the same reason. Left field is active. I don't know what "same reason" you think applies, but the control of the newsgroups to which an article is posted IS the posters; how the article is displayed is up to the reader. The same kinds of arguments do not apply to the Newsgroups header. From owner-ietf-usefor Tue Oct 5 06:27:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95DR378013660 for ; Tue, 5 Oct 2004 06:27:03 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95DR39o013659 for ietf-usefor-skb; Tue, 5 Oct 2004 06:27:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95DR2U5013652 for ; Tue, 5 Oct 2004 06:27:03 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp01.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: 6J5jcvtjudcz0OH4NnYi0NLdZiOf+WfQjl22YFGiQ0g= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp01.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CEpLI-0002YL-00; Tue, 05 Oct 2004 09:27:00 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i95DQvQw008389(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Tue, 5 Oct 2004 09:26:57 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i95DQuuF008388(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Tue, 5 Oct 2004 09:26:56 -0400 Message-ID: <4162A120.20806@erols.com> Date: Tue, 05 Oct 2004 09:26:56 -0400 From: Bruce Lilly Reply-To: ietf-usefor@imc.org Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us MIME-Version: 1.0 To: Henry Spencer CC: Usefor Mailing List Subject: Re: relay checking References: In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Henry Spencer wrote: > To clarify my own position on this... > [...] > + I'm reluctant to demand full checking by relay agents which otherwise > don't have reason to do it. Even SHOULD seems too strong a word here. > > + I would *like* to see relay agents not only permitted, but explicitly > encouraged, to do as much checking as they feel they can. Since SHOULD carries the same weight as RECOMMENDED, either there is an inconsistency in your position or you believe that there is some significant difference between "RECOMMENDED" and encouraged. So please do clarify; how would an explicit recommendation not encourage relay agent authors to "do as much checking as they feel they can"? From owner-ietf-usefor Tue Oct 5 06:27:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95DRGiN013675 for ; Tue, 5 Oct 2004 06:27:16 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95DRGhX013674 for ietf-usefor-skb; Tue, 5 Oct 2004 06:27:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95DRGlR013667 for ; Tue, 5 Oct 2004 06:27:16 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: 6J5jcvtjudc938dpQvexrg5ef6XVIppk7MEUdmNlIiI= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CEpLZ-00058k-00; Tue, 05 Oct 2004 09:27:17 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i95DRGr0008393(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Tue, 5 Oct 2004 09:27:16 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i95DRFlX008392(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Tue, 5 Oct 2004 09:27:16 -0400 Message-ID: <41628E2D.2060107@erols.com> Date: Tue, 05 Oct 2004 08:06:05 -0400 From: Bruce Lilly Reply-To: ietf-usefor Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us MIME-Version: 1.0 To: Alexey Melnikov CC: ietf-usefor Subject: Re: Standardize Complaints-To as deployed? References: <4161AC98.1010000@isode.com> In-Reply-To: <4161AC98.1010000@isode.com> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alexey Melnikov wrote: > should Complaints-To be standardized as described in section 6.20 of > draft-ietf-usefor-article-13.txt? No. From owner-ietf-usefor Tue Oct 5 12:08:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95J8Neq043767 for ; Tue, 5 Oct 2004 12:08:23 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95J8NkV043766 for ietf-usefor-skb; Tue, 5 Oct 2004 12:08:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from spsystems.net (spsystems.net [216.126.83.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95J8MB7043759 for ; Tue, 5 Oct 2004 12:08:22 -0700 (PDT) (envelope-from henry@spsystems.net) Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i95J8DcC021726; Tue, 5 Oct 2004 15:08:13 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i95J8DSA021725; Tue, 5 Oct 2004 15:08:13 -0400 (EDT) Date: Tue, 5 Oct 2004 15:08:13 -0400 (EDT) From: Henry Spencer To: Usefor Mailing List Subject: Re: relay checking In-Reply-To: <4162A120.20806@erols.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 5 Oct 2004, Bruce Lilly wrote: > > + I'm reluctant to demand full checking by relay agents which otherwise > > don't have reason to do it. Even SHOULD seems too strong a word here. > > + I would *like* to see relay agents not only permitted, but explicitly > > encouraged, to do as much checking as they feel they can. > > Since SHOULD carries the same weight as RECOMMENDED... Most people believe that SHOULD (or the seldom-used RECOMMENDED) carries a lot of weight -- that it is not just a suggestion or an encouragement, but an emphatic recommendation that you disregard at your peril, although unusual circumstances may occasionally justify violating it. There are a few people who persist in claiming that it doesn't really mean that. My concern is to communicate, and therefore I use SHOULD with its consensus meaning. Henry Spencer henry@spsystems.net From owner-ietf-usefor Wed Oct 6 19:12:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972CR5C025828 for ; Wed, 6 Oct 2004 19:12:27 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i972CRDS025827 for ietf-usefor-skb; Wed, 6 Oct 2004 19:12:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-5.gradwell.net (lon-mail-5.gradwell.net [193.111.201.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972CQIJ025809 for ; Wed, 6 Oct 2004 19:12:26 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) X-Gradwell-Debug: delivering mail for [ietf-usefor@imc.org] to mail.imc.org [208.184.76.43]:25 Received: from host81-144-68-121.midband.mdip.bt.net [81.144.68.121] by lon-mail-5.gradwell.net with esmtp (Gradwell gwh-smtpd 1.138) id 4164a60f.e777.19; Thu, 7 Oct 2004 03:12:31 +0100 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CI826077; Thu, 7 Oct 2004 03:12:18 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20213 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: draft-ietf-usefor-usepro-01 Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <87ekkomuxa.fsf@windlord.stanford.edu> <87fz53mq54.fsf@windlord.stanford.edu> <87u0tidz4a.fsf@windlord.stanford.edu> <878yatsz7l.fsf@windlord.stanford.edu> Date: Wed, 6 Oct 2004 22:20:41 GMT Lines: 119 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <878yatsz7l.fsf@windlord.stanford.edu> Russ Allbery writes: >Charles Lindsey writes: >> We did discuss the text that says control messages need to have a >> Newsgroups-header that will steer them to the proper places, and the >> text you see contains some tweaks arising from that. >Control messages should not, in general, be crossposted to other >newsgroups than they one that they affect. David Lawrence was the one who >first taught me the problems caused by doing so. For example, when people >form a habit of crossposting control messages to alt.config, someone >limiting what hierarchies in alt.* they receive, they still ends up >getting control messages for the hierarchies they don't want. Indeed so, which is why our draft says you SHOULD include the affected group in the Newsgroups-header, and you MAY include others, but it then points out that this may cause other problems. However, it may sometimes be useful, and others have said as much in response to your message. >However, relay agents that check the Newsgroups header against a list of >valid groups *do* need to propagate control messages as if the group they >were affecting existed. *That* behavior does need to be specified in the >standard. This is independent of the question of whether one should >ignore the Newsgroups header on newgroup and rmgroup control messages >entirely. But if control messages are to be propagated regardless of what the Newsgroups-header says, then how is it that I do not see newgroup messages for jp.* and other hierarchies to which I do not subscribe? For sure someone upstream of me is filtering them out, so I can only suppose that some 'sys' files are being consulted somewhere in the process, but where? > I'm surprised that it's not in son-of-1036 and doesn't appear >to be in CNews, but perhaps both predate the understanding that this was >the right thing to do. This has been implemented in INN since the 1.0 >release in 1991. >If relay agents don't implement this behavior, booster rmgroups are >futile because they won't propagate past the first host that already >removed the group and newgroups won't propagate through relay agents that >don't act on them immediately and require that newsgroups exist before >propagating messages. This is clearly wrong. Sure, but different relay agents attack this problem in all sorts of different ways. For example, in CNews, it checks for the presence of a Control-header at an early stage, and immediately decides to file it in the 'control' newsgroup (which is always in the active file). So any control message received (i.e. which the upstream peer was somehow configured to send to it) will get stored regardless. Then, whenever a new article is stored it consults its 'sys' file to see which of its downstream peers it should send it to, and that of course is determined by what is in the article's Newsgroups-header. Note that 'sys' files are usually broadly written, disposing of complete (sub-)hierarchies using wildmat notation or similar. So, back when Tale first created 'humanities.misc', I think you will find that his Newsgroups-header will have contained at least token groups from sci, comp, news, talk, etc. Otherwise, it would never have propagated very far. >Well, I don't believe that's correct, but there's no point in arguing >about past history. I'm making that statement now. This should be part >of the standard. I think it is clear that we have to put _something_ in the standard about this, but I think we need to understand the range of practices that current relaying agents actually DO before writing any text. >> Even if relaying agents do not, as a matter of local policy, intend >> to honour certain control messages, they MUST still propagate them in >> the normal manner. >> [The inclusion of that paragraph still remains under discussion.] >This is still not correct. This doesn't help with the issue addressed >above in propagation of newgroup and rmgroup control messages and simply >contradicts other portions of the document in a fashion that leaves one >wondering what it's supposed to mean. Sure, but it's not supposed to be anything to do with the issues discussed above. It is concerned with agents that try to say "I am not going to create this group, so I am not going to tell you about it". > Please, remove this language and >just explain that newgroup and rmgroup control messages should always be >propagated as if the group they're affecting exists, even if it does not. I could easily be persuaded that the wording should come out, but at least let us remove it for the right reasons (e.g. that no current agent is so inconsiderate and mean as to do such a thing). >> Ah! I had always understood, since the matter was first raised on the >> news.admin.net-abuse groups, that it came out of the normal processing >> of the Path header rather than on special code in transport agents. >Nope. It was possible because of a pre-existing feature in INN (the path >aliasing concept predates pseudo-sites by quite some time), but path >aliasing is not really part of the normal processing of the Path header. OK. Thanks for that, though it implies that the trick would never have worked on CNews. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 6 19:12:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972CQfi025818 for ; Wed, 6 Oct 2004 19:12:26 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i972CQlG025815 for ietf-usefor-skb; Wed, 6 Oct 2004 19:12:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-5.gradwell.net (lon-mail-5.gradwell.net [193.111.201.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972CNh3025800 for ; Wed, 6 Oct 2004 19:12:24 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) X-Gradwell-Debug: delivering mail for [ietf-usefor@imc.org] to mail.imc.org [208.184.76.43]:25 Received: from host81-144-68-121.midband.mdip.bt.net [81.144.68.121] by lon-mail-5.gradwell.net with esmtp (Gradwell gwh-smtpd 1.138) id 4164a60d.e777.17; Thu, 7 Oct 2004 03:12:29 +0100 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CLc26098; Thu, 7 Oct 2004 03:12:21 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20214 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <200409301656.i8UGqSOL005552@jefferson.patriot.net> Date: Wed, 6 Oct 2004 22:23:37 GMT Lines: 27 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <200409301656.i8UGqSOL005552@jefferson.patriot.net> "Shmuel (Seymour J.) Metz" writes: >In , on 09/29/2004 > at 06:07 PM, "Charles Lindsey" said: >>OK, that is new wording, and it may yet disappear entirely. But the >>"MUST be identical" is indeed too severe. I have made a note to >>review it. >You could just add an additional phrse along the lines of "except as >requested by the reader." >For the most part I like your text as it is. Which seems to imply that you support retention of a "Duties of a Reading Agent" section broadly as I have suggested it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 6 19:12:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972CQLl025817 for ; Wed, 6 Oct 2004 19:12:26 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i972CQ3F025816 for ietf-usefor-skb; Wed, 6 Oct 2004 19:12:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-5.gradwell.net (lon-mail-5.gradwell.net [193.111.201.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972CPOP025801 for ; Wed, 6 Oct 2004 19:12:25 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) X-Gradwell-Debug: delivering mail for [ietf-usefor@imc.org] to mail.imc.org [208.184.76.43]:25 Received: from host81-144-68-121.midband.mdip.bt.net [81.144.68.121] by lon-mail-5.gradwell.net with esmtp (Gradwell gwh-smtpd 1.138) id 4164a60e.e777.18; Thu, 7 Oct 2004 03:12:30 +0100 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CNZ26118; Thu, 7 Oct 2004 03:12:23 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20215 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: Date: Wed, 6 Oct 2004 22:45:51 GMT Lines: 57 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In John Stanley writes: >"Charles Lindsey" : >>The alternative text, which you did not quote, is >Didn't need to quote it, I thought. >>No, the poster cannot "define" how articles are to be displayed, but he >>can indicate his intention in the matter ... >If he cannot control it, his intention of controlling it is irrelevant. "I >want ...". That's nice, but you don't get to say. Presenting it as if >there was some mechanism, when none exists, just leads to foolish >expectations. Just like the foolish expectations that copyright notices in >the body of an article are going to change how Google or any other >automated news processor is going to work. The whole of this discussion started because it was reported that some FAQ writers had formed the habit of linking their multi-part FAQs together using References-headers, and a consensus developed that this practice was a Good Thing. But why did those FAQ writers start doing that? Because they saw that it would cause their parts to be presented in the correct order, at least in those reading agents which did threading (which was enough of them to be useful). In other words, they were indicating an intention of how they would like their articles displayed. Not guaranteed to work, but working often enough to be useful. >>>The alternative I suggested is still better. Why has it never appeared in >>>any form? >>You need to explain _why_ your wording is better. >I have, many times. On the other hand, I've not seen any explanation of >why your new alternative is better, it just appeared out of nowhere. And >now I've explained why YOUR wording is wrong. And I've just explained why it was right. Your move. All the remaining points raised in your message raise nothing that has not already been discussed on this list ad nauseam and received adequate answers, both from myself and from others. If other members of this list feel that any of your points are worth further discussion, then I am willing to reopen them. But not otherwise. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 6 19:12:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972CbCh025879 for ; Wed, 6 Oct 2004 19:12:37 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i972CbK6025878 for ietf-usefor-skb; Wed, 6 Oct 2004 19:12:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp811.mail.ukl.yahoo.com (smtp811.mail.ukl.yahoo.com [217.12.12.201]) by above.proper.com (8.12.11/8.12.9) with SMTP id i972CaPl025861 for ; Wed, 6 Oct 2004 19:12:36 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-68-121.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.68.121 with poptime) by smtp811.mail.ukl.yahoo.com with SMTP; 7 Oct 2004 02:12:21 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CGm26067; Thu, 7 Oct 2004 03:12:16 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20212 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Issues with MIME-style parameters Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <412DEE02.1040604@erols.com> <415ABDFE.9080303@erols.com> Date: Wed, 6 Oct 2004 21:10:46 GMT Lines: 32 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <415ABDFE.9080303@erols.com> Bruce Lilly writes: >Charles Lindsey wrote: >[...] >> So the >> possibility that there may one day be parameters in the Path header has >> changed nothing. >[...] >> why should it be used as an argument with >> Injection-Date? >The WG Chair declared the matter of so-called "MIME" parameters >a closed issue on August 23, a full week before Charles' message >was composed, and more than a month before it was posted to the >mailing list. This is outrageous. Mr. Chairman, can we please >settle this issue once and for all. The remark concerning the Path header was totally peripheral to the substance of what my message was about. I note that you have made no response to that substance. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 6 19:28:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972SDBK026720 for ; Wed, 6 Oct 2004 19:28:13 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i972SDOP026719 for ietf-usefor-skb; Wed, 6 Oct 2004 19:28:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i972SDJQ026710 for ; Wed, 6 Oct 2004 19:28:13 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id i972SGbP032252 for ; Wed, 6 Oct 2004 19:28:17 -0700 Received: (qmail 14303 invoked by uid 1000); 7 Oct 2004 02:28:16 -0000 To: ietf-usefor@imc.org Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: (Charles Lindsey's message of "Wed, 6 Oct 2004 22:20:41 GMT") References: <87ekkomuxa.fsf@windlord.stanford.edu> <87fz53mq54.fsf@windlord.stanford.edu> <87u0tidz4a.fsf@windlord.stanford.edu> <878yatsz7l.fsf@windlord.stanford.edu> From: Russ Allbery Organization: The Eyrie Date: Wed, 06 Oct 2004 19:28:16 -0700 Message-ID: <871xgb9s8v.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > Russ Allbery writes: >> However, relay agents that check the Newsgroups header against a list >> of valid groups *do* need to propagate control messages as if the group >> they were affecting existed. *That* behavior does need to be specified >> in the standard. This is independent of the question of whether one >> should ignore the Newsgroups header on newgroup and rmgroup control >> messages entirely. > But if control messages are to be propagated regardless of what the > Newsgroups-header says, then how is it that I do not see newgroup > messages for jp.* and other hierarchies to which I do not subscribe? I am completely baffled by this reply. You seem to have not read what I have said. You don't get newgroup messages for jp.* because you are not being fed the jp.* hierarchy, and the only mention of "control messages are to be propagated regardless of what the Newsgroups-header says" is the text that's currently in USEPRO that I'm trying to get you to take *out*. Control messages MUST be propagated as if the newsgroup that they affect existed, even if it doesn't. It is occasionally additionally a good idea to behave as if the Newsgroups header contains only the newsgroup being affected, rather than whatever other random junk the poster has chosen to put in there, but that's a different topic. The important part is that if I post a newgroup message for news.misc, that newgroup message should propagate to any of my peers that would receive news.misc given their subscription patterns, even if that group doesn't actually exist. This is significant since normally, for speed, implementations like INN turn feed subscriptions into a hash table keyed on newsgroup name and listing all the sites that want to retrieve that newsgroup. This is an effective technique for nearly all traffic if you're maintaining an active file, but control messages cannot be handled this way, and INN pulls them out of normal feed processing and performs a special match of the affected group against the raw feed patterns instead. > So, back when Tale first created 'humanities.misc', I think you will > find that his Newsgroups-header will have contained at least token > groups from sci, comp, news, talk, etc. Otherwise, it would never have > propagated very far. How much money would you like to bet me? -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Wed Oct 6 20:12:27 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i973CRfS029489 for ; Wed, 6 Oct 2004 20:12:27 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i973CRSB029488 for ietf-usefor-skb; Wed, 6 Oct 2004 20:12:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp807.mail.ukl.yahoo.com (smtp807.mail.ukl.yahoo.com [217.12.12.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i973CQck029463 for ; Wed, 6 Oct 2004 20:12:26 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-73-71.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.73.71 with poptime) by smtp807.mail.ukl.yahoo.com with SMTP; 7 Oct 2004 03:12:27 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CT326167; Thu, 7 Oct 2004 03:12:29 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20220 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: relay checking Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: Date: Wed, 6 Oct 2004 23:28:06 GMT Lines: 40 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Henry Spencer writes: >On Wed, 29 Sep 2004, Russ Allbery wrote: >> I thought Henry and I just agreed on language, and I'm curious as to why >> you decided to go with this language instead... >> I don't see a lot of purpose served in distinguishing between existence >> and syntactic validity of headers. I think that makes the logic of the >> standard slightly more complex for no particularly clear reason. >To clarify my own position on this... >+ I see a small benefit from insisting on presence of mandatory headers, >but only a small one. It's unobjectionable but not very important. I have written SHOULD. >+ I'm reluctant to demand full checking by relay agents which otherwise >don't have reason to do it. Even SHOULD seems too strong a word here. I have written MAY. >+ I would *like* to see relay agents not only permitted, but explicitly >encouraged, to do as much checking as they feel they can. Not sure I want to encourage too hard. It could be a severe performance penalty. And I agree that SHOULD is far too strong. >+ I don't care deeply about the issue, and could live with any wording >that permits full checking but doesn't require it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 6 20:12:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i973COGG029472 for ; Wed, 6 Oct 2004 20:12:24 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i973CO3F029471 for ietf-usefor-skb; Wed, 6 Oct 2004 20:12:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp807.mail.ukl.yahoo.com (smtp807.mail.ukl.yahoo.com [217.12.12.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i973CN3V029461 for ; Wed, 6 Oct 2004 20:12:24 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-73-71.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.73.71 with poptime) by smtp807.mail.ukl.yahoo.com with SMTP; 7 Oct 2004 03:12:24 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CSO26162; Thu, 7 Oct 2004 03:12:28 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20219 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Standardize Complaints-To as deployed? Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4161AC98.1010000@isode.com> Date: Wed, 6 Oct 2004 23:25:54 GMT Lines: 29 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4161AC98.1010000@isode.com> Alexey Melnikov writes: >Hi, >I would like to poll the WG about fate of the Complaints-To header. >I would ask people to voice their opinion about the following question: >should Complaints-To be standardized as described in section 6.20 of >draft-ietf-usefor-article-13.txt? >If the answer to this question is "yes", than it will be added to >draft-ietf-usefor-usefor-01.txt. Otherwise I will reopen the discussion >whether it should be an email address or an URL. Yes. But note that Complaints-To comes as a pair with Injection-Info. Also, I would have no problem with a URL as an alternative, but _only_ if that URL were limited to 'mailto'. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 6 20:12:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i973CQgQ029481 for ; Wed, 6 Oct 2004 20:12:26 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i973CQwK029480 for ietf-usefor-skb; Wed, 6 Oct 2004 20:12:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp807.mail.ukl.yahoo.com (smtp807.mail.ukl.yahoo.com [217.12.12.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i973COGl029462 for ; Wed, 6 Oct 2004 20:12:25 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-73-71.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.73.71 with poptime) by smtp807.mail.ukl.yahoo.com with SMTP; 7 Oct 2004 03:12:26 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CQR26148; Thu, 7 Oct 2004 03:12:26 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20217 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: relay checking Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: Date: Wed, 6 Oct 2004 23:14:37 GMT Lines: 31 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Henry Spencer writes: >On Wed, 29 Sep 2004, Charles Lindsey wrote: >> 3. It SHOULD reject any article that does not have the correct >> mandatory headers (section a-5) present. >Why "correct"? That seems redundant, and it is bound to make people >wonder whether it has some special significance. I'd take that word out. Because that word has been there all along. But I take your point. 3. It SHOULD reject any article that does not include all the mandatory headers (section a-5). And likewise for serving agents. There was also a similar use of "correct" in relation to injecting agents and proto-articles, where I have changed it to "proper". >Otherwise, this seems okay. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 6 20:12:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i973CS1i029498 for ; Wed, 6 Oct 2004 20:12:28 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i973CSNH029497 for ietf-usefor-skb; Wed, 6 Oct 2004 20:12:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp807.mail.ukl.yahoo.com (smtp807.mail.ukl.yahoo.com [217.12.12.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i973CRQN029464 for ; Wed, 6 Oct 2004 20:12:28 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-73-71.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.73.71 with poptime) by smtp807.mail.ukl.yahoo.com with SMTP; 7 Oct 2004 03:12:28 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CR726157; Thu, 7 Oct 2004 03:12:27 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20218 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Usefor/usepro conflicts. Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <87zn38syzu.fsf@windlord.stanford.edu> Date: Wed, 6 Oct 2004 23:23:15 GMT Lines: 47 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <87zn38syzu.fsf@windlord.stanford.edu> Russ Allbery writes: >Charles Lindsey writes: >> OK, I now have: >> A "poster" is the person or software that composes a possibly >> compliant article for submission to a posting agent. The poster is >> synonymous with [RFC 2822]'s author. >I believe this is wrong. Poster is synonymous with sender. Well "poster" is the word we have used in the draft all along, and I worry that some subtle change of meaning will ensue if we change it now. Any more opinions on this one? And, as someone else observed, "poster" is used as a keyword in Followup-To and in Mail-Copies-To, and in both those places it means the From/Reply-To guy. >>> The word in standard usage implies "the person who posts", which is >>> different than "the person who writes", so as a synonym, it belongs to >>> "sender". >> But the term as widely used throughout Usenet is as I have defined it. >I strongly disagree. Everywhere that I've seen poster used on Usenet in a >context that drew the distinction between author and transmitter, poster >referred to the person who injected the article, not the author. Yes, and in any case in the draft where that distinction is important we need to be careful, as in the following case: >> Posting agents meant for use by ordinary posters SHOULD reject any >> attempt to post an article which cancels or Supersedes another >> article of which the poster is not the author or sender. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 6 20:12:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i973CV4l029506 for ; Wed, 6 Oct 2004 20:12:31 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i973CVgR029505 for ietf-usefor-skb; Wed, 6 Oct 2004 20:12:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp807.mail.ukl.yahoo.com (smtp807.mail.ukl.yahoo.com [217.12.12.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i973CUXJ029474 for ; Wed, 6 Oct 2004 20:12:30 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-73-71.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.73.71 with poptime) by smtp807.mail.ukl.yahoo.com with SMTP; 7 Oct 2004 03:12:31 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i972CPd26135; Thu, 7 Oct 2004 03:12:25 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20216 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <200410041711.i94HBdf06942@panix5.panix.com> <20041004182521.GA28583@tagseth-trd.consultit.no> Date: Wed, 6 Oct 2004 23:02:47 GMT Lines: 47 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20041004182521.GA28583@tagseth-trd.consultit.no> Eivind Tagseth writes: >You are indicating that your article and the article with the last >message id in the References header has a child-parent relationship. >Furthermore, you're saying that all message ids in the References header >have an ancestry relationship to your article. And you're saying that >the very first message id in the References header is the very first >message of this ancestry lineage. >I guess this isn't quite correct, as the References header may also contain >message ids that are not decendants of the very first article (when >replying to two different articles as once), or doesn't this ever >happen? We have explicitly said we do not cover the case of followups to multiple articles, and RFC 2822 says much the same thing for email. OTOH, if you do make such a followup and manually create a References-header in a plausible way, then most current threading agents will probably manage to do something sensible with it. >Isn't this what the references header really means? How to display >the article in a news reader isn't really that relevant, the natural >way to display articles having such relations comes from the meaning >of the header, not vice versa. I think the two things go hand in hand. There would be little point in having the References header if it were not intended to be used for threading. >Are we really not able to describe the semantics of the references >header without doing it backwards by describing the ui rather >than the meaning. But I agree that some semantics in the USEFOR document would be a good addition to the detailed instructions in USEPRO as to how to contruct it, and I intend to look into this. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Thu Oct 7 04:56:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97Bucj4082824 for ; Thu, 7 Oct 2004 04:56:38 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97BucN3082823 for ietf-usefor-skb; Thu, 7 Oct 2004 04:56:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97BuYp7082809 for ; Thu, 7 Oct 2004 04:56:35 -0700 (PDT) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CFWsn-0008MZ-00 for ; Thu, 07 Oct 2004 13:56:29 +0200 Received: from du-001-107.access.de.clara.net ([212.82.227.107]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Oct 2004 13:56:29 +0200 Received: from nobody by du-001-107.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Oct 2004 13:56:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Usefor/usepro conflicts. Date: Thu, 07 Oct 2004 13:55:16 +0200 Organization: Lines: 28 Message-ID: <41652EA4.40E6@xyzzy.claranet.de> References: <87zn38syzu.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-107.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: >>> "poster" is the person or software that composes a possibly >>> compliant article for submission to a posting agent. The >>> poster is synonymous with [RFC 2822]'s author. >> I believe this is wrong. Poster is synonymous with sender. > Well "poster" is the word we have used in the draft all > along, and I worry that some subtle change of meaning will > ensue if we change it now. Any more opinions on this one? > And, as someone else observed, "poster" is used as a keyword > in Followup-To and in Mail-Copies-To, and in both those > places it means the From/Reply-To guy. "Poster" is as you say the From/Reply-To guy. That's the same as the 2822-Sender. It's generally the same as the 2822-From (author), but not always. Likewise the poster is generally the author, but not always (sometimes FAQs are written by A, but posted by B, where A is the author, and B is a posting-Bot run by somebody else). I'm not sure about this, but a news From is not always exactly the same as a 2822-From, a news From is more like a MAIL FROM. Bye, Frank From owner-ietf-usefor Thu Oct 7 05:12:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97CCPLK084006 for ; Thu, 7 Oct 2004 05:12:25 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97CCPtB084005 for ietf-usefor-skb; Thu, 7 Oct 2004 05:12:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97CCNgL083996 for ; Thu, 7 Oct 2004 05:12:24 -0700 (PDT) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CFX8D-0000To-00 for ; Thu, 07 Oct 2004 14:12:25 +0200 Received: from du-001-107.access.de.clara.net ([212.82.227.107]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Oct 2004 14:12:25 +0200 Received: from nobody by du-001-107.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Oct 2004 14:12:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Date: Thu, 07 Oct 2004 14:09:49 +0200 Organization: Lines: 15 Message-ID: <4165320D.157F@xyzzy.claranet.de> References: <200410041711.i94HBdf06942@panix5.panix.com> <20041004182521.GA28583@tagseth-trd.consultit.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-107.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: > There would be little point in having the References header > if it were not intended to be used for threading. Depends, my UA certainly uses it for threading, but it also displays the "References:" in a way suited for a "See-Also:" literal meaning of references. Especially if I select its "options -> show headers -> brief". Of course both attempts (threading and "See-Also:") can fail, and the main purpose of references from my POV is threading. Bye, Frank From owner-ietf-usefor Thu Oct 7 08:39:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97Fd6De003455 for ; Thu, 7 Oct 2004 08:39:06 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97Fd66U003454 for ietf-usefor-skb; Thu, 7 Oct 2004 08:39:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97Fd501003447 for ; Thu, 7 Oct 2004 08:39:06 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp01.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: wwvnFyfMpUbSJ7cH+G4aB0MsHwYCNl628XXpbM4f1hM= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp01.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CFaMG-0003qP-00; Thu, 07 Oct 2004 11:39:08 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i97Fd4qa020135(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Thu, 7 Oct 2004 11:39:04 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i97Fd3Nk020133(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Thu, 7 Oct 2004 11:39:03 -0400 Message-ID: <41656316.5060504@erols.com> Date: Thu, 07 Oct 2004 11:39:02 -0400 From: Bruce Lilly Reply-To: ietf-usefor@imc.org Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us MIME-Version: 1.0 To: Henry Spencer CC: Usefor Mailing List Subject: Re: relay checking References: In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Henry Spencer wrote: > I'm a little reluctant to use SHOULD for any of this, because that keyword > is generally understood to mean that the action in question is nearly > mandatory, No, it's understood to be a recommendation (and in fact the term explicitly and by definition carries the same weight as the adjective RECOMMENDED); MUST and MUST NOT are mandates (for conforming implementations -- and there is no enforcement, so even those terms are not terribly forceful). > I think the right choice is either to say MAY with some accompanying words > urging people to do it, The term MAY is generally used for clarification where an implementor might misinterpret some normative text as precluding something which is in fact not intended to be precluded. Any other use of the term tends to be vacuous since it is generally permitted to do anything that is not explicitly proscribed. > or to say SHOULD but accompany it with an escape > hatch like "to the extent that performance requirements permit". I don't have a problem with that, but let's make sure the right wording is used; let's not speak of performance requirements where performance is not the major issue. We also ought to recognize several different instances where different fields might be checked. Some fields are checked at injection time and are supposed to remain unaltered during transport. It would probably be unreasonable to demand routine checks of such fields at every relay agent, and given the protocol specifications (viz. checked once at injection time and remaining unaltered thereafter) there is only a small point (see below) in recommending checks. There is no reason to prohibit such checks. On the other hand, there are fields (e.g. Path) which are modified during transport, and which are used in the protocol (at least by some implementations, as discussed). It is not unreasonable to recommend that these fields be checked, so as to be able to pinpoint the agent responsible for screwing up syntax or similar errors. The questions then are what might reasonably be checked, when, and by whom. At minimum, if a field is to be checked, the part which should have been modified by the preceding (upstream) agent should be checked. If checking is a mere recommendation, then it is possible that that upstream agent did no checking of what was modified by its upstream neighbor and so on, so it might be prudent to check everything that might have been modified since injection. Such checks (of modifications made by predecessors) should probably be performed on receipt, before other processing, so as to avoid attempting to process broken articles. There is little point in an agent attempting to check its own modifications prior to sending an article downstream, since an author's error in interpretation of requirements when modifying a field is likely to be repeated when checking. It is also conceivable that an injection agent may have made an error, so there is no reason to preclude a relay agent from checking parts of fields that might have been set at injection time, or entire fields that are supposed to be set at injection and remain unmodified thereafter. From owner-ietf-usefor Thu Oct 7 09:01:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97G15t0004898 for ; Thu, 7 Oct 2004 09:01:05 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97G15N0004897 for ietf-usefor-skb; Thu, 7 Oct 2004 09:01:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from a.mail.peak.org (a.mail.peak.org [69.59.192.41]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97G14c4004876 for ; Thu, 7 Oct 2004 09:01:05 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by a.mail.peak.org (8.12.10/8.12.8) with ESMTP id i97G10UD060096 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 7 Oct 2004 09:01:00 -0700 (PDT) Date: Thu, 7 Oct 2004 09:01:00 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Charles Lindsey" : >The whole of this discussion started because it was reported that some FAQ >writers had formed the habit of linking their multi-part FAQs together >using References-headers, and a consensus developed that this practice was >a Good Thing. Umm, this discussion started when I read the document listed in the subject and saw a silly alternative definition for a word that implied a level of control over something that did not exist. >But why did those FAQ writers start doing that? Because they saw that it >would cause their parts to be presented in the correct order, at least in >those reading agents which did threading (which was enough of them to be >useful). And which reading agents did they see this in? Their own. Keep in mind, they get to control how they see things, so the fact that they can control how they see things is no big surprise. It is their ability to control how OTHER PEOPLE see things that is the question, and which they lack. >And I've just explained why it was right. Your move. No, you explained why someone has unfounded expectations about something they do being able to control other people's display of articles. Unfounded expectations are not a reason to change a definition. However, the fact that they DO use the header to indicate relationships that are just outside the old definition are a reason to change it, if one it truly documenting existing practice. It's just not correct to imply that their desire to indicate a relationship actually has some basis in controlling the display of articles. That implication is the problem with the alternate definition you have provided. From owner-ietf-usefor Thu Oct 7 09:07:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97G7IoP005248 for ; Thu, 7 Oct 2004 09:07:18 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97G7IVm005247 for ietf-usefor-skb; Thu, 7 Oct 2004 09:07:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from b.mail.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97G7III005234 for ; Thu, 7 Oct 2004 09:07:18 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by b.mail.peak.org (8.12.10/8.12.8) with ESMTP id i97G7FjZ035737 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 7 Oct 2004 09:07:15 -0700 (PDT) Date: Thu, 7 Oct 2004 09:07:15 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Re: Usefor/usepro conflicts. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Charles Lindsey" : >Well "poster" is the word we have used in the draft all along, and I worry >that some subtle change of meaning will ensue if we change it now. Any >more opinions on this one? Just as I did for the word "followup" and found nothing really changed, nothing really changes for the word "poster", since most of the standard deals with the actions of posting and what happens from thereon, and not much with the content of the body, which is the author's responsibility. >And, as someone else observed, "poster" is used as a keyword in Followup-To >and in Mail-Copies-To, and in both those places it means the From/Reply-To >guy. Yes, this is the only point I found that would be in error, but since it is current practice, it seems a bit late to change that to "author". It is also pretty much harmless, and can easily be covered by a simple statement that "yes, we know it ought to be 'author', but its usage is historical and we're just going to live with it this way". From owner-ietf-usefor Thu Oct 7 09:11:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97GBKXT005505 for ; Thu, 7 Oct 2004 09:11:20 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97GBKEI005504 for ietf-usefor-skb; Thu, 7 Oct 2004 09:11:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from b.mail.peak.org (b.mail.peak.org [69.59.192.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97GBJPO005493 for ; Thu, 7 Oct 2004 09:11:19 -0700 (PDT) (envelope-from stanley@peak.org) Received: from a.shell.peak.org ([69.59.192.81]) by b.mail.peak.org (8.12.10/8.12.8) with ESMTP id i97GBHjZ037338 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 7 Oct 2004 09:11:17 -0700 (PDT) Date: Thu, 7 Oct 2004 09:11:17 -0700 (PDT) From: John Stanley X-X-Sender: stanley@a.shell.peak.org To: ietf-usefor@imc.org Subject: Re: relay checking Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Henry Spencer : >Most people believe that SHOULD (or the seldom-used RECOMMENDED) carries a >lot of weight -- that it is not just a suggestion or an encouragement, but >an emphatic recommendation that you disregard at your peril, although >unusual circumstances may occasionally justify violating it. >There are a few people who persist in claiming that it doesn't really mean >that. My concern is to communicate, and therefore I use SHOULD with its >consensus meaning. Unfortunately, every standard that uses SHOULD proclaims somewhere within that they use SHOULD as it is defined in RFC2119. There is no mention of "peril" or "emphatic" in that standard. Not even the implication. Wouldn't it be nice if the "consensus" meaning actually matched the consensus meaning that was achieved when RFC2119 was adopted? I mean, if the authors of RFC2119 MEANT the strength of force that Henry's "consensus" says, they could have said so themselves. Since they did not, it seems clear to me that they didn't intend any such force. From owner-ietf-usefor Thu Oct 7 09:13:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97GD0Lm005619 for ; Thu, 7 Oct 2004 09:13:00 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97GD0ES005617 for ietf-usefor-skb; Thu, 7 Oct 2004 09:13:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp801.mail.ukl.yahoo.com (smtp801.mail.ukl.yahoo.com [217.12.12.138]) by above.proper.com (8.12.11/8.12.9) with SMTP id i97GCw14005599 for ; Thu, 7 Oct 2004 09:12:59 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-64-212.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.64.212 with poptime) by smtp801.mail.ukl.yahoo.com with SMTP; 7 Oct 2004 16:12:29 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i97GCFF00222; Thu, 7 Oct 2004 17:12:15 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20222 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: draft-ietf-usefor-usepro-01 Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <87ekkomuxa.fsf@windlord.stanford.edu> <87fz53mq54.fsf@windlord.stanford.edu> <87u0tidz4a.fsf@windlord.stanford.edu> <878yatsz7l.fsf@windlord.stanford.edu> <871xgb9s8v.fsf@windlord.stanford.edu> Date: Thu, 7 Oct 2004 14:26:57 GMT Lines: 43 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <871xgb9s8v.fsf@windlord.stanford.edu> Russ Allbery writes: >Control messages MUST be propagated as if the newsgroup that they affect >existed, even if it doesn't. It is occasionally additionally a good idea >to behave as if the Newsgroups header contains only the newsgroup being >affected, rather than whatever other random junk the poster has chosen to >put in there, but that's a different topic. The important part is that if >I post a newgroup message for news.misc, that newgroup message should >propagate to any of my peers that would receive news.misc given their >subscription patterns, even if that group doesn't actually exist. Right! That last sentence is the bit that was missing from your previous explanations of what INN actually did. There clearly had to be a 'sys' file (however called) somewhere in the chain that controlled what actually went to your downstream peers. >This is significant since normally, for speed, implementations like INN >turn feed subscriptions into a hash table keyed on newsgroup name and >listing all the sites that want to retrieve that newsgroup. This is an >effective technique for nearly all traffic if you're maintaining an active >file, but control messages cannot be handled this way, and INN pulls them >out of normal feed processing and performs a special match of the affected >group against the raw feed patterns instead. OK, it is useful to know that, but I can still see variants on that technique that would work equally well. Anyway, for the final question, what about transit-only systems that keep no active file, nor any permenent store of articles? Do they need to take any special note of Control-headers, or do they just propagate them like ordinary articles, as determined by the Newsgroups-headers plus their peers' subscription information? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Thu Oct 7 13:50:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97KonkQ026467 for ; Thu, 7 Oct 2004 13:50:49 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i97KoneR026466 for ietf-usefor-skb; Thu, 7 Oct 2004 13:50:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i97KomKe026459 for ; Thu, 7 Oct 2004 13:50:48 -0700 (PDT) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id i97Koqk1031457 for ; Thu, 7 Oct 2004 13:50:53 -0700 Received: (qmail 5874 invoked by uid 1000); 7 Oct 2004 20:50:52 -0000 To: ietf-usefor@imc.org Subject: Re: draft-ietf-usefor-usepro-01 In-Reply-To: (Charles Lindsey's message of "Thu, 7 Oct 2004 14:26:57 GMT") References: <87ekkomuxa.fsf@windlord.stanford.edu> <87fz53mq54.fsf@windlord.stanford.edu> <87u0tidz4a.fsf@windlord.stanford.edu> <878yatsz7l.fsf@windlord.stanford.edu> <871xgb9s8v.fsf@windlord.stanford.edu> From: Russ Allbery Organization: The Eyrie Date: Thu, 07 Oct 2004 13:50:52 -0700 Message-ID: <87vfdm45hv.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > Anyway, for the final question, what about transit-only systems that > keep no active file, nor any permenent store of articles? Do they need > to take any special note of Control-headers, or do they just propagate > them like ordinary articles, as determined by the Newsgroups-headers > plus their peers' subscription information? I think either approach works. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Fri Oct 8 09:12:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98GCtmX049650 for ; Fri, 8 Oct 2004 09:12:55 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98GCtUe049648 for ietf-usefor-skb; Fri, 8 Oct 2004 09:12:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp801.mail.ukl.yahoo.com (smtp801.mail.ukl.yahoo.com [217.12.12.138]) by above.proper.com (8.12.11/8.12.9) with SMTP id i98GCrJ9049632 for ; Fri, 8 Oct 2004 09:12:54 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-73-148.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.73.148 with poptime) by smtp801.mail.ukl.yahoo.com with SMTP; 8 Oct 2004 16:12:33 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i98GCE208494; Fri, 8 Oct 2004 17:12:14 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20232 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <200410041711.i94HBdf06942@panix5.panix.com> <20041004182521.GA28583@tagseth-trd.consultit.no> <4165320D.157F@xyzzy.claranet.de> Date: Fri, 8 Oct 2004 12:04:27 GMT Lines: 25 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4165320D.157F@xyzzy.claranet.de> Frank Ellermann writes: >Depends, my UA certainly uses it for threading, but it also >displays the "References:" in a way suited for a "See-Also:" >literal meaning of references. Especially if I select its >"options -> show headers -> brief". Yes, I sometimes look at the References header if I want to view some precursor in its un-snipped form. >Of course both attempts (threading and "See-Also:") can fail, >and the main purpose of references from my POV is threading. But yes, the "main purpose" is threading. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Fri Oct 8 09:12:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98GCtpN049667 for ; Fri, 8 Oct 2004 09:12:55 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98GCtAr049665 for ietf-usefor-skb; Fri, 8 Oct 2004 09:12:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp801.mail.ukl.yahoo.com (smtp801.mail.ukl.yahoo.com [217.12.12.138]) by above.proper.com (8.12.11/8.12.9) with SMTP id i98GCsbI049635 for ; Fri, 8 Oct 2004 09:12:54 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-73-148.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.73.148 with poptime) by smtp801.mail.ukl.yahoo.com with SMTP; 8 Oct 2004 16:12:36 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i98GCFU08498; Fri, 8 Oct 2004 17:12:15 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20233 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: relay checking Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <41656316.5060504@erols.com> Date: Fri, 8 Oct 2004 12:23:48 GMT Lines: 63 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <41656316.5060504@erols.com> Bruce Lilly writes: >Henry Spencer wrote: >> I'm a little reluctant to use SHOULD for any of this, because that keyword >> is generally understood to mean that the action in question is nearly >> mandatory, >No, it's understood to be a recommendation (and in fact the term >explicitly and by definition carries the same weight as the >adjective RECOMMENDED); MUST and MUST NOT are mandates (for >conforming implementations -- and there is no enforcement, so >even those terms are not terribly forceful). Indeed, but "RECOMMENDATION" is usually taken as something more than mere "recommendation". The phrase Henry would use (and I have seen it used also by yourself) is that SHOULD is a "strong recommendation" not lightly to be ignored, and RFC 2119 supports that interpretation. >> or to say SHOULD but accompany it with an escape >> hatch like "to the extent that performance requirements permit". >I don't have a problem with that, but let's make sure the >right wording is used; let's not speak of performance >requirements where performance is not the major issue. But the question here relates to the behaviour of relaying agents, where performance is THE major issue. >We also ought to recognize several different instances where >different fields might be checked. Some fields are checked >at injection time and are supposed to remain unaltered >during transport. Indeed, and that is the case here. These headers are supposed to have been checked already by an injecting agent (but there are some dodgy injecting agents out there). > ... On the >other hand, there are fields (e.g. Path) which are modified >during transport, and which are used in the protocol (at >least by some implementations, as discussed). It is >not unreasonable to recommend that these fields be checked, >so as to be able to pinpoint the agent responsible for >screwing up syntax or similar errors. But again, there is a performance hit here. What relaying agents do in practice, I suspect, is just to extract anything that looks like a path-identity and do a crude comparison with the identity of the site it is about to relay to. No great harm arises if it gets it wrong occasionally. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Fri Oct 8 09:12:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98GCtUL049651 for ; Fri, 8 Oct 2004 09:12:55 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98GCtTb049649 for ietf-usefor-skb; Fri, 8 Oct 2004 09:12:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp801.mail.ukl.yahoo.com (smtp801.mail.ukl.yahoo.com [217.12.12.138]) by above.proper.com (8.12.11/8.12.9) with SMTP id i98GCrC0049633 for ; Fri, 8 Oct 2004 09:12:54 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-73-148.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.73.148 with poptime) by smtp801.mail.ukl.yahoo.com with SMTP; 8 Oct 2004 16:12:34 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i98GCDT08490; Fri, 8 Oct 2004 17:12:13 +0100 (BST) To: LIST: usenet-format@landfield.com, ietf-usefor@imc.org; Xref: clerew local.usefor:20231 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Usefor/usepro conflicts. Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <87zn38syzu.fsf@windlord.stanford.edu> <41652EA4.40E6@xyzzy.claranet.de> Date: Fri, 8 Oct 2004 12:00:59 GMT Lines: 39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <41652EA4.40E6@xyzzy.claranet.de> Frank Ellermann writes: >Charles Lindsey wrote: >> And, as someone else observed, "poster" is used as a keyword >> in Followup-To and in Mail-Copies-To, and in both those >> places it means the From/Reply-To guy. >"Poster" is as you say the From/Reply-To guy. That's the same >as the 2822-Sender. I think not. In the oft-quoted case where the Boss gets his Secretary to send the message, the Secretary is the Sender, but the Boss is the From. The Reply-To may be either of them, or even a third person. > ... Likewise the poster is generally the >author, but not always (sometimes FAQs are written by A, but >posted by B, where A is the author, and B is a posting-Bot run >by somebody else). B is the Sender. If the FAQ contains Followup-To: poster, then followups would be mailed to A (assuming he is the From/Reply-To). >I'm not sure about this, but a news From is not always exactly >the same as a 2822-From, a news From is more like a MAIL FROM. No, I think that is wrong. The MAIL FROM is where you send reports of non-delivery and the like, which will usually be the Sender. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Sat Oct 9 01:23:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i998NS5Z090875 for ; Sat, 9 Oct 2004 01:23:28 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i998NSjF090874 for ietf-usefor-skb; Sat, 9 Oct 2004 01:23:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i998NNgY090806 for ; Sat, 9 Oct 2004 01:23:24 -0700 (PDT) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CGCVh-0006Dq-00 for ; Sat, 09 Oct 2004 10:23:25 +0200 Received: from 212.82.251.67 ([212.82.251.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Oct 2004 10:23:25 +0200 Received: from nobody by 212.82.251.67 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Oct 2004 10:23:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Usefor/usepro conflicts. Date: Sat, 09 Oct 2004 10:22:35 +0200 Organization: Lines: 33 Message-ID: <41679FCB.72B1@xyzzy.claranet.de> References: <87zn38syzu.fsf@windlord.stanford.edu> <41652EA4.40E6@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.67 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: > In the oft-quoted case where the Boss gets his Secretary to > send the message, the Secretary is the Sender, but the Boss > is the From. Sorry, I should have looked into the normative reference (for my parallel universe ;-), you're right, I was confused: (5.2) | The From header contains the electronic address, and possi- | bly the full name, of the article's author: (6.4) | The Sender header identifies the poster, in the event that | this differs from the author identified in the From header: [...] | In the absence of Sender, the default poster is the author | (named in the From header). (10.4) | The Sender header is a tricky case, one where mailing-list | and post-by-mail practice should differ. For gatewaying | mailing lists, the mailing-list host should be considered a | relayer, and the From and Sender headers supplied in its | transmissions left strictly untouched. For post-by-mail, as | for a moderator posting a mailed submission, the Sender | header should reflect the poster rather than the author. If | a post-by-mail gateway receives a message with its own | Sender header, it might wish to preserve the content in an | X-Sender header. Bye, Frank From owner-ietf-usefor Tue Oct 12 07:43:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CEho9k039289 for ; Tue, 12 Oct 2004 07:43:50 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CEhoHJ039288 for ietf-usefor-skb; Tue, 12 Oct 2004 07:43:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CEhnlN039279 for ; Tue, 12 Oct 2004 07:43:49 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: F/GYF4dqrElHTfCzRoHnG4cDEPt50Q/QdiMEchDQUFU= Received: from 65.105.220.34.ptr.us.xo.net ([65.105.220.34] helo=mail.blilly.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #7) id 1CHNsd-0003HW-00; Tue, 12 Oct 2004 10:43:59 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i9CEhxIw005303(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Tue, 12 Oct 2004 10:43:59 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i9CEhrFI005302(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Tue, 12 Oct 2004 10:43:53 -0400 Message-ID: <416BD4F8.1050205@erols.com> Date: Tue, 12 Oct 2004 08:58:32 -0400 From: Bruce Lilly Reply-To: ietf-usefor Organization: Bruce Lilly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us MIME-Version: 1.0 To: Charles Lindsey CC: ietf-usefor@imc.org; Subject: Re: Issues with MIME-style parameters References: <412DEE02.1040604@erols.com> <415ABDFE.9080303@erols.com> In-Reply-To: X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: > The remark concerning the Path header was totally peripheral to the > substance of what my message was about. I note that you have made no > response to that substance. Yet. As you took more than a month to respond to the original message, don't be so quick to note responses. At the moment, I have many far more important things to do than to respond to imaginary "substance" in your self-contradictory ramblings. From owner-ietf-usefor Sun Oct 17 10:07:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9HH7wNZ023283 for ; Sun, 17 Oct 2004 10:07:58 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9HH7w3Y023282 for ietf-usefor-skb; Sun, 17 Oct 2004 10:07:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9HH7wu6023274 for ; Sun, 17 Oct 2004 10:07:58 -0700 (PDT) (envelope-from blilly@erols.com) X-Info: This message was accepted for relay by smtp03.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: BNCexjMrAqC1u1x+ODKbnZB90taFh2fzPzDKu2slO7A= Received: from [12.40.110.79] (helo=mail.blilly.com) by smtp03.mrf.mail.rcn.net with esmtpa (Exim 4.42 #5) id 1CJEVl-0004gb-BG; Sun, 17 Oct 2004 13:08:01 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) by mail.blilly.com with ESMTP id i9HH7niA005178(8.12.10/8.12.10/mail.blilly.com sendmail.mc.mail 1.18 2004/05/15 07:23:45) ; Sun, 17 Oct 2004 13:07:54 -0400 Received: from localhost (localhost [127.0.0.1]) by marty.blilly.com with ESMTP id i9HH7i7P005153(8.12.10/8.12.10/blilly.com submit.mc 1.1 2003/08/26 22:21:33) ; Sun, 17 Oct 2004 13:07:53 -0400 From: Bruce Lilly Reply-To: ietf-usefor@imc.org Organization: Bruce Lilly To: Russ Allbery Subject: Re: draft-ietf-usefor-usepro-01 Date: Sun, 17 Oct 2004 11:49:04 -0400 User-Agent: KMail/1.7.1 References: <878yatsz7l.fsf@windlord.stanford.edu> <9IYKznMXw-B@khms.westfalen.de> <87vfdjeo20.fsf@windlord.stanford.edu> In-Reply-To: <87vfdjeo20.fsf@windlord.stanford.edu> Cc: ietf-usefor@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410171149.05316.blilly@erols.com> Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [Incidentally, the original was apparently sent only to the old mailing list rather than the "new" (as of a couple of months ago) mailing list] On Sat October 9 2004 14:36, you wrote: > Kai Henningsen writes: > > > That sounds to me like a very special case. It seems to me it's much > > more likely that you have your peers send you, say, a certain subset of > > the Big8, and you want to get all the Big8 control messages, not just > > that subset, so you can decide what other groups you might be interested > > in. > > Note that this has never been possible for the Big Eight, and I've never > heard a complaint about it. You're the first person who I recall > indicating that you'd prefer things be done that way, rather than only > sending control messages according to normal newsgroup subscription > patterns. [...] > (This is probably more detailed than we really need to cover in our > documents, but it is a good argument in favor of not banning crossposting > control messages.) We probably need to cover more detail; let's start with examining the pros and cons for the different types of control messages: So far you folks have been discussing newgroup messages, but there are other types. The considerations vary based on the control message type. Cancels could safely be limited to the newsgroup subscription patterns *assuming* that newsgroups are specified exactly the same on the cancel as in the original, *and* further assuming that there have been no changes to newsgroup hierarchies in the time interval between posting of the original and cancel messages, *and* still further assuming that no site has changed newsgroup feed patterns in such a way (e.g. dropping newsgroups) that would prevent a cancel message from reaching a system that had received the original. I suspect that in a small but significant portion of cases, one or more of those assumptions would fail to conform to reality. I believe that the specific mechanism specified in RFC 1036 is reasonable; viz. propagate widely initially, stopping propagation to downstream sites unless the original message had been received. Rmgroup messages, the newfangled mvgroup messages, newgroup and checkgroups messages should probably propagate everywhere. Otherwise a site that gets its initial list of active newsgroups e.g. via ftp from some source would not be kept up to date w.r.t. changes in hierarchies (additions, renaming, removals, changes in suggested moderation status) if upstream sites fail to propagate relevant control messages when newsgroups directly affected are not fed. That in turn could affect downstrean sites that subsequently get the out-of-date active newsgroup list from the site in question, administrators and users of that site may be unaware of changes to newsgroups of potential interest (e.g. for finding an alternate upstream feed for new groups of interest), and sites with out-of-date lists may unintentionally become sources of problems (e.g. crossposts to "old" newsgroups that have been removed or renamed). Ihave and sendme control messages should only propagate one hop regardless of newsgroup subscriptions. Generally, pseudo- newsgroups are set up by administrators to implement that, but the rule should be specified; implementation details are just that -- implementation details. Sendsys control messages are intended to gather statistics about connectivity and newsgroup distribution. If limited to newsgroup hierarchies, then gathered connectivity statistics will obviously only represent a subset of sites to which the control message propagates. That is probably A Bad Thing for connectivity (as distinct from newsgroup propagation) statistics. Causing those control messages to propagate widely in order to gather more complete statistics requires crossposting to a huge number of newsgroups, which would likely cause some breakage (I suspect that some software would be unable to handle a Newsgroups field listing 30,000 newsgrousp). On the other hand, collecting newsgroup propagation statistics could be achieved even if propagation of the control message is limited; conversely if it is not limited the only downside is the volume of the responses sent to the requestor. I believe sendsys control messages should therefore propagate everywhere, unless superseded by two distinct types of control messages for the two specific purposes (viz. connectivity in general, and specific newsgroup hierarchy propagation). Version control messages are intended to gather statistics on transport/spooling software, and is likely only to be of use to a requestor if reasonably complete (e.g. to definitively answer the question "is anybody still running B news 2.11?"). It should therefore propagate widely (i.e. independently of newsgroups). Other considerations: Since different types of control messages are handled differently and affect different agents in different ways, we should probably consider whether a long term split of the catch-all Control field would be worth planning for (i.e. while keeping the catch-all Control field name tag with a separate "verb" in the field for the moment, advising implementors that at some future date there may well be separate fields to facilitate the different types of propagation and the different handling by different agents). From owner-ietf-usefor Mon Oct 18 12:09:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IJ9eHM086866 for ; Mon, 18 Oct 2004 12:09:40 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IJ9eCf086865 for ietf-usefor-skb; Mon, 18 Oct 2004 12:09:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IJ9dZx086855 for ; Mon, 18 Oct 2004 12:09:40 -0700 (PDT) (envelope-from alexey.melnikov-usefor@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 20:09:41 +0100 Message-ID: <417414F5.6020500@isode.com> Date: Mon, 18 Oct 2004 20:09:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor Subject: Re: Standardize Complaints-To as deployed? References: <4161AC98.1010000@isode.com> In-Reply-To: <4161AC98.1010000@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alexey Melnikov wrote: > Hi, > I would like to poll the WG about fate of the Complaints-To header. > I would ask people to voice their opinion about the following > question: should Complaints-To be standardized as described in section > 6.20 of draft-ietf-usefor-article-13.txt? > > If the answer to this question is "yes", than it will be added to > draft-ietf-usefor-usefor-01.txt. Otherwise I will reopen the > discussion whether it should be an email address or an URL. Could I ask people who answered "yes" to this question to list software that generates this header? Thanks, Alexey From owner-ietf-usefor Tue Oct 19 05:07:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JC7l98055636 for ; Tue, 19 Oct 2004 05:07:47 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JC7lqN055635 for ietf-usefor-skb; Tue, 19 Oct 2004 05:07:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp814.mail.ukl.yahoo.com (smtp814.mail.ukl.yahoo.com [217.12.12.204]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JC7jp2055617 for ; Tue, 19 Oct 2004 05:07:46 -0700 (PDT) (envelope-from chl@clerew.man.ac.uk) Received: from unknown (HELO host81-144-66-10.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.66.10 with poptime) by smtp814.mail.ukl.yahoo.com with SMTP; 19 Oct 2004 12:07:41 -0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id i9JBqjE09856 for ; Tue, 19 Oct 2004 12:52:46 +0100 (BST) To: "Usefor WG" Subject: Header Table Date: Tue, 19 Oct 2004 12:52:37 +0100 From: "Charles Lindsey" Content-Type: multipart/mixed; boundary=----------p274O9WLZJUvIFimG3INvK MIME-Version: 1.0 Message-ID: User-Agent: Opera M2/7.54 (SunOS, build 751) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------------p274O9WLZJUvIFimG3INvK Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Our Chair has asked me to produce this table showing where the various Netnews headers are generated and where they are consumed. Hopefully, this may be useful in our discussions, and maybe it should evan appear as an Appendix in one of the drafts. It needs to be viewed in a wide window, or in landscape if prented (there is a FF character at a suitable place). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ------------p274O9WLZJUvIFimG3INvK Content-Disposition: attachment; filename=header-use Content-Type: application/octet-stream; name=header-use Content-Transfer-Encoding: 8bit Table showing Generation and Consumption of Netnews Headers. ------------------------------------------------------------ Notation -------- G (C, U) indicate where the header is normally Generated (Checked[1], Used). g (c, u) indicate where the header is occasionally generated (checked, used). Header poster posting inject- relay- serv- reading follow- reply reader special gateway gateway moder- agent ing ing ing agent up agent scripts in out ator [2] [2] agent agent agent agent [3] ------------------------------------------------------------------------------------------------------------------------- Used in Transit ------------------------------------------------------------------------------------------------------------------------- Message-ID - g G U U - - - - - c/g c - Newsgroups G g C/U[4] U C/U U g[5] - u - G - U Path - g[6] G U/G U/G - - - - - - - C Injection-Date - - C/G U U - - - - - - U C Distribution G g - U U u g[5] - - - - - - Control G - - u[7] U - - - - - - C g Approved G - U[4] u U - - - - - - - G Supersedes G - - u[7] U - - - - - - - - Expires G - - - U - - - - - - - - ------------------------------------------------------------------------------------------------------------------------- Used for Reading/Followup/Reply ------------------------------------------------------------------------------------------------------------------------- >From g G g C/g C - - U U - - - - Reply-To g G - - - - - U - - - - - Followup-To G - - - - - U - - - - - - Mail-Copies-To - G - - - - U U - - - - - References g - - - - U U/G - - - - - - Xref - - - - G U - - - - - - - Content-* G G g - - U - - - - U U - Header poster posting inject- relay- serv- reading follow- reply reader special gateway gateway moder- agent ing ing ing agent up agent scripts in out ator [2] [2] agent agent agent agent [3] ------------------------------------------------------------------------------------------------------------------------- Used by humans and special scripts ------------------------------------------------------------------------------------------------------------------------- Date - G C[8] C[8] C[8] u - - U - g U c/g Subject G - C - C u g[5] - U - - - - Sender - G - - - - - u U U G - - Organization - G g - - - - - U - - - - Keywords G - - - - - - - U U - - - Summary G - - - - - - - U - - - - Posted-And- - G - - - - G - U - - - - Mailed Archive - G - - - - - - - U - - - Lines - G - - - - - - U - - - - User-Agent - G g - - - - - U - - - - Injection-Info - - C/G - - - - - u U - - C Complaints-To - - C/G - - - - - U U - - C Notes ----- [1] Checking is usually just for the presence of absence of the header. [2] Shown under poster if a per-article affair; Shown under posting agent if normally set automatically/by configuration. [3] For operations not part of the normal duties of the regular agents, but which need to rely on the structure and semantics of the header. In addition. just about any header may be used in a killfile. [4] To detect moderated articles already approved. [5] Defaults set by followup agent. [6] Posting agent may set . [7] For articles arriving later than their cancels. Also to ensure further propagation of group control messages. [8] For detecting >24 hours into the future, or when Injection-Date absent. ------------p274O9WLZJUvIFimG3INvK-- From owner-ietf-usefor Tue Oct 19 19:12:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9K2CQqw087409 for ; Tue, 19 Oct 2004 19:12:26 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9K2CQg1087408 for ietf-usefor-skb; Tue, 19 Oct 2004 19:12:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp814.mail.ukl.yahoo.com (smtp814.mail.ukl.yahoo.com [217.12.12.204]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9K2CPZ0087385 for ; Tue, 19 Oct 2004 19:12:25 -0700 (PDT) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host62-172-24-61.midband.mdip.bt.net) (ietf-usefor@imc.org@62.172.24.61 with poptime) by smtp814.mail.ukl.yahoo.com with SMTP; 20 Oct 2004 02:12:25 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id i9K2CCB17774 for ietf-usefor@imc.org; Wed, 20 Oct 2004 03:12:12 +0100 (BST) To: LIST: ietf-usefor@imc.org; Xref: clerew local.usefor:20241 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Standardize Complaints-To as deployed? Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> Date: Tue, 19 Oct 2004 20:57:44 GMT Lines: 39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <417414F5.6020500@isode.com> Alexey Melnikov writes: >Alexey Melnikov wrote: >> Hi, >> I would like to poll the WG about fate of the Complaints-To header. >> I would ask people to voice their opinion about the following >> question: should Complaints-To be standardized as described in section >> 6.20 of draft-ietf-usefor-article-13.txt? >> >> If the answer to this question is "yes", than it will be added to >> draft-ietf-usefor-usefor-01.txt. Otherwise I will reopen the >> discussion whether it should be an email address or an URL. >Could I ask people who answered "yes" to this question to list software >that generates this header? No software generates this header, but lots of software generates the X-Complaints-To header (and for email too, I believe), which is essentially identical (but we cannot standardize X-headers). No regular agent needs to recognize it, but doubtless lots of people (spam fighters and the like) have scripts which use it; It would be trivial to modify such scripts to recognize Complaints-To alongside X-Complaints-To. A similar relation exists between the new Archive header and the current X-No-Archive header (but only Google actually uses this header, so far as anyone knows, and there have been hints that Google would likely recognize the new one alongside the old one). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Oct 27 09:05:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RG5PYp096004 for ; Wed, 27 Oct 2004 09:05:25 -0700 (PDT) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RG5P51096003 for ietf-usefor-skb; Wed, 27 Oct 2004 09:05:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RG5LCj095996 for ; Wed, 27 Oct 2004 09:05:22 -0700 (PDT) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CMqIe-0001qO-00 for ; Wed, 27 Oct 2004 18:05:24 +0200 Received: from c-134-93-16.hh.dial.de.ignite.net ([62.134.93.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 18:05:24 +0200 Received: from nobody by c-134-93-16.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Oct 2004 18:05:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Standardize Complaints-To as deployed? Date: Wed, 27 Oct 2004 18:04:56 +0200 Organization: Lines: 10 Message-ID: <417FC728.78B7@xyzzy.claranet.de> References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-93-16.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alexey Melnikov wrote: > Could I ask people who answered "yes" to this question to > list software that generates this header? At the moment you'd only find X-Complaints-To: (used by many news servers). IMHO the idea is to get rid of the "X-" here. Bye, Frank From owner-ietf-usefor Mon Nov 1 17:44:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA21iEwV044043 for ; Mon, 1 Nov 2004 17:44:14 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA21iEeB044042 for ietf-usefor-skb; Mon, 1 Nov 2004 17:44:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA21iEnw044013 for ; Mon, 1 Nov 2004 17:44:14 -0800 (PST) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id iA21iHsb012547 for ; Mon, 1 Nov 2004 17:44:17 -0800 Received: (qmail 27744 invoked by uid 1000); 2 Nov 2004 01:44:17 -0000 To: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? In-Reply-To: (Charles Lindsey's message of "Tue, 19 Oct 2004 20:57:44 GMT") References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> From: Russ Allbery Organization: The Eyrie Date: Mon, 01 Nov 2004 17:44:17 -0800 Message-ID: <87sm7t6n4e.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (Catching up from having been on vacation.) Charles Lindsey writes: > No software generates this header, but lots of software generates the > X-Complaints-To header (and for email too, I believe), which is > essentially identical (but we cannot standardize X-headers). I would be curious to know what software other than INN generates X-Complaints-To. It, like X-Trace, is an INN invention, and I don't know if anyone else has copied it. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Nov 2 04:37:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2Cbd3X002284 for ; Tue, 2 Nov 2004 04:37:39 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2Cbd6K002283 for ietf-usefor-skb; Tue, 2 Nov 2004 04:37:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2Cbbjg002270 for ; Tue, 2 Nov 2004 04:37:38 -0800 (PST) (envelope-from alexey.melnikov-usefor@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 2 Nov 2004 12:37:34 +0000 Message-ID: <41877F8C.7000402@isode.com> Date: Tue, 02 Nov 2004 12:37:32 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Allbery CC: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> In-Reply-To: <87sm7t6n4e.fsf@windlord.stanford.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: >(Catching up from having been on vacation.) > >Charles Lindsey writes: > > >>No software generates this header, but lots of software generates the >>X-Complaints-To header (and for email too, I believe), which is >>essentially identical (but we cannot standardize X-headers). >> >> > >I would be curious to know what software other than INN generates >X-Complaints-To. It, like X-Trace, is an INN invention, and I don't know >if anyone else has copied it. > > At this time I am tempted to say that X-Complaints-To is deprecated and it is function is incorporated into Injection-Info. Alexey From owner-ietf-usefor Tue Nov 2 09:12:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2HCUJY000265 for ; Tue, 2 Nov 2004 09:12:30 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2HCUS9000264 for ietf-usefor-skb; Tue, 2 Nov 2004 09:12:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2HCT4Z000257 for ; Tue, 2 Nov 2004 09:12:29 -0800 (PST) (envelope-from news@clerew.man.ac.uk) Received: from host81-144-72-27.midband.mdip.bt.net [81.144.72.27] by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.148) id 4187bffe.b3f2.10 for ietf-usefor@imc.org; Tue, 2 Nov 2004 17:12:30 +0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id iA2HCFZ28105 for ietf-usefor@imc.org; Tue, 2 Nov 2004 17:12:15 GMT To: LIST: ietf-usefor@imc.org; Xref: clerew local.usefor:20244 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Standardize Complaints-To as deployed? Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> Date: Tue, 2 Nov 2004 17:00:11 GMT Lines: 53 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <87sm7t6n4e.fsf@windlord.stanford.edu> Russ Allbery writes: >(Catching up from having been on vacation.) >Charles Lindsey writes: >> No software generates this header, but lots of software generates the >> X-Complaints-To header (and for email too, I believe), which is >> essentially identical (but we cannot standardize X-headers). >I would be curious to know what software other than INN generates >X-Complaints-To. It, like X-Trace, is an INN invention, and I don't know >if anyone else has copied it. A quick poke around part of my newspool revealed 90% of articles using X-Trace, and 40% using X-Complaints-To. Harder to tell which of those were or were not using INN as injecting agent, but I then grepped for Paths of the form ...!example.net.POSTED!not-for-mail, which I think can safely be assumed *not* to have used INN for injecting, and I found examples of the following forms: 202932:X-Complaints-To: abuse@brightview.com 203490:X-Complaints-To: abuse@cv.net 203451:X-Complaints-To: abuse@earthlink.net 203105:X-Complaints-To: abuse@nildram.net 202898:X-Complaints-To: abuse@prodigy.net 203455:X-Complaints-To: abuse@ptd.net 202656:X-Complaints-To: abuse@readfreenews.com 203485:X-Complaints-To: abuse@rr.com 202848:X-Complaints-To: abuse@virgin.net 202900:X-Complaints-To: abuse@zen.co.uk 202833:X-Complaints-To: http://www.ntlworld.com/netreport and in a separate bit of grepping: X-Complaints-To: abuse@giganews.com Don't worry about the ntlworld one. They are known to be terminally clueless :-( . Perhaps Bill Davidsen could comment on what Prodigy are using. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Tue Nov 2 09:30:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2HUrKA007191 for ; Tue, 2 Nov 2004 09:30:53 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2HUrV0007190 for ietf-usefor-skb; Tue, 2 Nov 2004 09:30:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.Stanford.EDU (smtp2.Stanford.EDU [171.67.16.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2HUqdL007179 for ; Tue, 2 Nov 2004 09:30:52 -0800 (PST) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id iA2HUsUe031851 for ; Tue, 2 Nov 2004 09:30:55 -0800 Received: (qmail 18247 invoked by uid 1000); 2 Nov 2004 17:30:54 -0000 To: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? In-Reply-To: (Charles Lindsey's message of "Tue, 2 Nov 2004 17:00:11 GMT") References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> From: Russ Allbery Organization: The Eyrie Date: Tue, 02 Nov 2004 09:30:54 -0800 Message-ID: <87pt2wyx81.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey writes: > Harder to tell which of those were or were not using INN as injecting > agent, but I then grepped for Paths of the form > ...!example.net.POSTED!not-for-mail, which I think can safely be assumed > *not* to have used INN for injecting, and I found examples of the > following forms: Not a safe assumption. > Perhaps Bill Davidsen could comment on what Prodigy are using. Prodigy ran INN at least in part, last I'd heard. The count of X-Trace in your sample is suspiciously high, causing me to suspect the integrity of your sample. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Tue Nov 2 12:01:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2K1x9o061541 for ; Tue, 2 Nov 2004 12:01:59 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2K1wtq061531 for ietf-usefor-skb; Tue, 2 Nov 2004 12:01:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2K1rni061468 for ; Tue, 2 Nov 2004 12:01:54 -0800 (PST) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CP4qi-0001J3-00 for ; Tue, 02 Nov 2004 21:01:48 +0100 Received: from du-001-184.access.de.clara.net ([212.82.227.184]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Nov 2004 21:01:48 +0100 Received: from nobody by du-001-184.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Nov 2004 21:01:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Standardize Complaints-To as deployed? Date: Tue, 02 Nov 2004 21:00:31 +0100 Organization: Lines: 21 Message-ID: <4187E75F.1099@xyzzy.claranet.de> References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-184.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alexey Melnikov wrote: > I am tempted to say that X-Complaints-To is deprecated and > it is function is incorporated into Injection-Info. Good riddance. But how am I supposed to derive an abuse address from the Injection-Info ? Without the old examples the new Usefor-01 is gibberish for me. Add news@ to the path-identity maybe ? Is that guaranteed to be good for Injection-info ? What about a news@ wanting abuse reports sent to another address like abuse@ ? For your idea we need at least an example and instructions. 4.1.4 in Useage doesn't help to understand Injection-Info. Usefor-13 before the split was monstrous, OTOH it was clear. It's no more fun to read the split drafts. Bye, Frank From owner-ietf-usefor Wed Nov 3 04:07:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3C7P5I091400 for ; Wed, 3 Nov 2004 04:07:25 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3C7Pqn091399 for ietf-usefor-skb; Wed, 3 Nov 2004 04:07:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3C7ObE091276 for ; Wed, 3 Nov 2004 04:07:24 -0800 (PST) (envelope-from alexey.melnikov-usefor@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 3 Nov 2004 12:07:14 +0000 Message-ID: <4188C9F0.6020905@isode.com> Date: Wed, 03 Nov 2004 12:07:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Ellermann CC: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> In-Reply-To: <4187E75F.1099@xyzzy.claranet.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann wrote: >Alexey Melnikov wrote: > > >>I am tempted to say that X-Complaints-To is deprecated and >>it is function is incorporated into Injection-Info. >> >> > >Good riddance. But how am I supposed to derive an abuse >address from the Injection-Info ? Without the old examples >the new Usefor-01 is gibberish for me. > >Add news@ to the path-identity maybe ? Is that guaranteed >to be good for Injection-info ? What about a news@ wanting >abuse reports sent to another address like abuse@ ? > >For your idea we need at least an example and instructions. >4.1.4 in Useage doesn't help to understand Injection-Info. > > Of course, this would be addressed in the upcoming USEFOR document. >Usefor-13 before the split was monstrous, OTOH it was clear. >It's no more fun to read the split drafts. > > From owner-ietf-usefor Wed Nov 3 04:11:00 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3CB0dd094218 for ; Wed, 3 Nov 2004 04:11:00 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3CB0HW094217 for ietf-usefor-skb; Wed, 3 Nov 2004 04:11:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3CAxmv094204 for ; Wed, 3 Nov 2004 04:10:59 -0800 (PST) (envelope-from alexey.melnikov-usefor@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Wed, 3 Nov 2004 12:10:58 +0000 Message-ID: <4188CAD0.1080902@isode.com> Date: Wed, 03 Nov 2004 12:10:56 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Frank Ellermann CC: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> <4188C9F0.6020905@isode.com> In-Reply-To: <4188C9F0.6020905@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alexey Melnikov wrote: > Frank Ellermann wrote: > >> Alexey Melnikov wrote: >> >>> I am tempted to say that X-Complaints-To is deprecated and >>> it is function is incorporated into Injection-Info. >> >> Good riddance. But how am I supposed to derive an abuse >> address from the Injection-Info ? Without the old examples >> the new Usefor-01 is gibberish for me. >> >> Add news@ to the path-identity maybe ? Is that guaranteed >> to be good for Injection-info ? What about a news@ wanting >> abuse reports sent to another address like abuse@ ? >> >> For your idea we need at least an example and instructions. >> 4.1.4 in Useage doesn't help to understand Injection-Info. > > Of course, this would be addressed in the upcoming USEFOR document. Just to clarify: in my original message I was talking conceptually. All affected document will have to be updated. (And I was talking about adding a new field to Injection-Info that would contain an email address.) From owner-ietf-usefor Wed Nov 3 07:34:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FYBU0083364 for ; Wed, 3 Nov 2004 07:34:12 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FYBVO083363 for ietf-usefor-skb; Wed, 3 Nov 2004 07:34:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FYAG4083288 for ; Wed, 3 Nov 2004 07:34:11 -0800 (PST) (envelope-from richard@highwayman.com) Received: from gti.noc.demon.net ([195.11.55.101] helo=rnc1.al.cl.cam.ac.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1CPN98-000Ain-7R; Wed, 03 Nov 2004 15:34:02 +0000 Message-ID: Date: Wed, 3 Nov 2004 15:32:22 +0000 To: Charles Lindsey Cc: ietf-usefor@imc.org From: Richard Clayton Subject: Re: Standardize Complaints-To as deployed? References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.02 M Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message , Charles Lindsey writes >>I would be curious to know what software other than INN generates >>X-Complaints-To. It, like X-Trace, is an INN invention, and I don't know >>if anyone else has copied it. > >A quick poke around part of my newspool revealed 90% of articles using >X-Trace, and 40% using X-Complaints-To. I have a database of approximately 25 million article headers dating from July 26 through to October 18th (this is pretty much a "full feed" of non-binaries for this period: I gathered them from an experimental system running next to the !demon! peering machine) Of these... 3,620,184 (13.8%) have X-Trace 1,033,266 ( 4.0%) have X-Complaints-To 14,422,971 (55.2%) have both 7,049,506 (27.0%) have neither >Harder to tell which of those were or were not using INN as injecting >agent, but I then grepped for Paths of the form >...!example.net.POSTED!not-for-mail, which I think can safely be assumed >*not* to have used INN for injecting, and I found examples of the >following forms: >202932:X-Complaints-To: abuse@brightview.com >203490:X-Complaints-To: abuse@cv.net >203451:X-Complaints-To: abuse@earthlink.net >203105:X-Complaints-To: abuse@nildram.net >202898:X-Complaints-To: abuse@prodigy.net >203455:X-Complaints-To: abuse@ptd.net >202656:X-Complaints-To: abuse@readfreenews.com >203485:X-Complaints-To: abuse@rr.com >202848:X-Complaints-To: abuse@virgin.net >202900:X-Complaints-To: abuse@zen.co.uk >202833:X-Complaints-To: http://www.ntlworld.com/netreport there's all sorts of other stuff out there... eg X-Complaints-To: Please report abuse to abuse@usenet4all.com but the overwhelming majority are valid looking email addresses. If it is useful I could give an account of what proportion were nicely formed BTW "X-Trace" is a complete mess to parse automatically, so it's use to anyone other than the injection site is limited (and it may in some cases not assist over-much in identifying that site) - -- richard @ highwayman . com "Nothing seems the same Still you never see the change from day to day And no-one notices the customs slip away" -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA+AwUBQYj6BhfnRQV/feRLEQJ2SACfQTByvjzpL0+f2tiukTEwsDyY08QAl1FI qZPmDhy8yG33hLP1SArNOy4= =gx9v -----END PGP SIGNATURE----- From owner-ietf-usefor Wed Nov 3 09:12:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3HCfv3026658 for ; Wed, 3 Nov 2004 09:12:42 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3HCfNt026656 for ietf-usefor-skb; Wed, 3 Nov 2004 09:12:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3HCeVm026570 for ; Wed, 3 Nov 2004 09:12:41 -0800 (PST) (envelope-from news@clerew.man.ac.uk) Received: from host62-172-28-77.midband.mdip.bt.net [62.172.28.77] by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.148) id 41891183.571c.25a for ietf-usefor@imc.org; Wed, 3 Nov 2004 17:12:35 +0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id iA3HCNF07150 for ietf-usefor@imc.org; Wed, 3 Nov 2004 17:12:23 GMT To: LIST: ietf-usefor@imc.org; Xref: clerew local.usefor:20250 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Standardize Complaints-To as deployed? Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> Date: Wed, 3 Nov 2004 12:15:55 GMT Lines: 35 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4187E75F.1099@xyzzy.claranet.de> Frank Ellermann writes: >Alexey Melnikov wrote: >> I am tempted to say that X-Complaints-To is deprecated and >> it is function is incorporated into Injection-Info. >Good riddance. But how am I supposed to derive an abuse >address from the Injection-Info ? Without the old examples >the new Usefor-01 is gibberish for me. Presumably there would be another parameter to the Injection-Info header of the form: Injection-Info: foo.net; ... ; complaints-to="abuse@foo.net"; ... Indeed, that was the original proposal when Injection-Info was first mooted, but the WG decided that it wanted a separate Complaints-To header. I would prefer to stay with that. I think it depends on which headers the "ordinary user" actually needs to see. It could be argued that the rest of the Injection-Info header is mostly for geeks, rather than for ordinary users. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Wed Nov 3 14:40:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3MeeiK060234 for ; Wed, 3 Nov 2004 14:40:40 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3MeeSY060233 for ietf-usefor-skb; Wed, 3 Nov 2004 14:40:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3MeacQ060162 for ; Wed, 3 Nov 2004 14:40:37 -0800 (PST) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CPTns-0004Is-00 for ; Wed, 03 Nov 2004 23:40:32 +0100 Received: from c-134-93-84.hh.dial.de.ignite.net ([62.134.93.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Nov 2004 23:40:32 +0100 Received: from nobody by c-134-93-84.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Nov 2004 23:40:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Standardize Complaints-To as deployed? Date: Wed, 03 Nov 2004 23:39:42 +0100 Organization: Lines: 13 Message-ID: <41895E2E.5C57@xyzzy.claranet.de> References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> <4188C9F0.6020905@isode.com> <4188CAD0.1080902@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-93-84.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alexey Melnikov wrote: > I was talking about adding a new field to Injection-Info Okay, then it's clear, and Charles said the same. I like this proposal, it's less trouble to catch _one_ forged header with all the injection info (for injecting agents). The geeks will love it, as Charles said, and only geeks need the complaint address. And for spammers it's more difficult to forge the complete Injection-Info. Besides I like KISS instead of "yet another header". Bye, Frank From owner-ietf-usefor Wed Nov 3 14:49:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3MnnW2063576 for ; Wed, 3 Nov 2004 14:49:49 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3MnnGq063575 for ietf-usefor-skb; Wed, 3 Nov 2004 14:49:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3MnnFb063569 for ; Wed, 3 Nov 2004 14:49:49 -0800 (PST) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id iA3Mnrn2018328 for ; Wed, 3 Nov 2004 14:49:53 -0800 Received: (qmail 5729 invoked by uid 1000); 3 Nov 2004 22:49:53 -0000 To: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? In-Reply-To: <41895E2E.5C57@xyzzy.claranet.de> (Frank Ellermann's message of "Wed, 03 Nov 2004 23:39:42 +0100") References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> <4188C9F0.6020905@isode.com> <4188CAD0.1080902@isode.com> <41895E2E.5C57@xyzzy.claranet.de> From: Russ Allbery Organization: The Eyrie Date: Wed, 03 Nov 2004 14:49:53 -0800 Message-ID: <87sm7qwnse.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann writes: > Okay, then it's clear, and Charles said the same. I like > this proposal, it's less trouble to catch _one_ forged > header with all the injection info (for injecting agents). > The geeks will love it, as Charles said, and only geeks > need the complaint address. And for spammers it's more > difficult to forge the complete Injection-Info. Besides > I like KISS instead of "yet another header". Bye, Frank I'm not particularly a fan of Injection-Info, but I'm willing to keep it around as a compromise and given that, I think it probably does make sense to combine the two. I still do think that the complaint parameter, however we represent it, should be a URL rather than an e-mail address. This is one of those principals like not imposing arbitrary limits on fields. A URL is more general and more flexible than an e-mail address; I don't know if, ten years down the road, we'll regret having only an e-mail address or will want a URL, but I don't see any reason to risk it. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Thu Nov 4 06:52:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4EqIGW096080 for ; Thu, 4 Nov 2004 06:52:18 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4EqIFL096079 for ietf-usefor-skb; Thu, 4 Nov 2004 06:52:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4EqFOW096069 for ; Thu, 4 Nov 2004 06:52:16 -0800 (PST) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CPiyH-0005iz-00 for ; Thu, 04 Nov 2004 15:52:17 +0100 Received: from c-134-93-89.hh.dial.de.ignite.net ([62.134.93.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Nov 2004 15:52:17 +0100 Received: from nobody by c-134-93-89.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Nov 2004 15:52:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Standardize Complaints-To as deployed? Date: Thu, 04 Nov 2004 15:50:28 +0100 Organization: Lines: 34 Message-ID: <418A41B4.7498@xyzzy.claranet.de> References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> <4188C9F0.6020905@isode.com> <4188CAD0.1080902@isode.com> <41895E2E.5C57@xyzzy.claranet.de> <87sm7qwnse.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-93-89.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: > I'm not particularly a fan of Injection-Info, but I'm willing > to keep it around as a compromise and given that, I think it > probably does make sense to combine the two. And I'm no fan of your URL idea, but with a MIME parameter in Injection-Info you're very near to your goal: You could use the format in RfC 2017 with its folding rules. Don't mention RfC 2231, or I'd continue my whining about complaint URLs ;-) > not imposing arbitrary limits on fields. A URL is more > general and more flexible than an e-mail address; I don't > know if, ten years down the road, we'll regret having only > an e-mail address or will want a URL That's why you want a URL, because we'll regret it as soon as it's available. Injection-Info: stuff; more=stuff; abuse-reports*1="mailto:" abuse-reports*2="news%40funny.example" abuse-reports*3="?subject=complaint%20about%20" abuse-reports*4="Message-ID%20%3Crandom+timestamp%40" abuse-reports*5="spammer.domain.example%3E&Cc=" abuse-reports*6="abuse%40news.funny.example" Flexible indeed. And several pages of security considerations plus an appendix I "IRIs in the abuse-reports parameter of Injection-Info". At least nobody wanted XML and a schema for Injection-Info, today you never know ;-) Bye, Frank From owner-ietf-usefor Thu Nov 4 08:25:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4GP90M028438 for ; Thu, 4 Nov 2004 08:25:09 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4GP9u4028436 for ietf-usefor-skb; Thu, 4 Nov 2004 08:25:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.Stanford.EDU (smtp3.Stanford.EDU [171.67.16.138]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4GP9Hd028429 for ; Thu, 4 Nov 2004 08:25:09 -0800 (PST) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id iA4GPB7a006052 for ; Thu, 4 Nov 2004 08:25:11 -0800 Received: (qmail 32305 invoked by uid 1000); 4 Nov 2004 16:25:11 -0000 To: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? In-Reply-To: <418A41B4.7498@xyzzy.claranet.de> (Frank Ellermann's message of "Thu, 04 Nov 2004 15:50:28 +0100") References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> <4188C9F0.6020905@isode.com> <4188CAD0.1080902@isode.com> <41895E2E.5C57@xyzzy.claranet.de> <87sm7qwnse.fsf@windlord.stanford.edu> <418A41B4.7498@xyzzy.claranet.de> From: Russ Allbery Organization: The Eyrie Date: Thu, 04 Nov 2004 08:25:11 -0800 Message-ID: <87u0s5oa3c.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann writes: > That's why you want a URL, because we'll regret it as soon as > it's available. > Injection-Info: > stuff; more=stuff; abuse-reports*1="mailto:" > abuse-reports*2="news%40funny.example" > abuse-reports*3="?subject=complaint%20about%20" > abuse-reports*4="Message-ID%20%3Crandom+timestamp%40" > abuse-reports*5="spammer.domain.example%3E&Cc=" > abuse-reports*6="abuse%40news.funny.example" > Flexible indeed. How is this any worse than not providing a complaints-to address at all? Most of what makes that look like such a mess, of course, is the decision to use MIME-style parameters for Injection-Info, not anything about the content of the abuse-reports parameter. > And several pages of security considerations plus an appendix I "IRIs in > the abuse-reports parameter of Injection-Info". I believe that the security considerations of visiting URLs are already dealt with in adequate depth by other RFCs that we can simply refer to, although I've not checked personally. However, if people would prefer to have both an email and a url parameter, that would also be fine with me. And I have no problem with lots of ranting against using anything other than a simple mailto URL in the USEAGE document. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Thu Nov 4 09:12:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HCXc2049480 for ; Thu, 4 Nov 2004 09:12:33 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4HCXwh049479 for ietf-usefor-skb; Thu, 4 Nov 2004 09:12:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HCW2B049471 for ; Thu, 4 Nov 2004 09:12:33 -0800 (PST) (envelope-from news@clerew.man.ac.uk) Received: from host81-144-72-189.midband.mdip.bt.net [81.144.72.189] by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.151) id 418a6302.13db4.0 for ietf-usefor@imc.org; Thu, 4 Nov 2004 17:12:34 +0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id iA4HCOe17772 for ietf-usefor@imc.org; Thu, 4 Nov 2004 17:12:24 GMT To: LIST: ietf-usefor@imc.org; Xref: clerew local.usefor:20256 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Usefor Web Site Message-ID: X-Newsreader: NN version 6.5.2 (NOV) Date: Thu, 4 Nov 2004 16:28:09 GMT Lines: 20 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: www.imc.org/ietf-usefor now contains all the documents and other links that were present on the Landfield site. It also contains the last two years of archives in html from the old mailing list, and the whole archive in mbox format. I shall transfer the rest of the html archives presently (but I need to write some scripts first), and then the Landfield site can finally be abandoned (I shall, of course, leave a pointer to the new site there). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Thu Nov 4 09:12:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HCYFu049490 for ; Thu, 4 Nov 2004 09:12:34 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4HCYKI049489 for ietf-usefor-skb; Thu, 4 Nov 2004 09:12:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HCXYI049473 for ; Thu, 4 Nov 2004 09:12:33 -0800 (PST) (envelope-from news@clerew.man.ac.uk) Received: from host81-144-72-189.midband.mdip.bt.net [81.144.72.189] by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.151) id 418a6303.13db4.1 for ietf-usefor@imc.org; Thu, 4 Nov 2004 17:12:35 +0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id iA4HCNe17767 for ietf-usefor@imc.org; Thu, 4 Nov 2004 17:12:24 GMT To: LIST: ietf-usefor@imc.org; Xref: clerew local.usefor:20255 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Standardize Complaints-To as deployed? Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> Date: Thu, 4 Nov 2004 16:23:43 GMT Lines: 28 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Richard Clayton writes: >In message , Charles Lindsey > writes >>202833:X-Complaints-To: http://www.ntlworld.com/netreport >there's all sorts of other stuff out there... eg > X-Complaints-To: Please report abuse to abuse@usenet4all.com >but the overwhelming majority are valid looking email addresses. If it >is useful I could give an account of what proportion were nicely formed For a header that is nowhere documented officially, that is not bad going. Of course, if we bless it with standardization, then the malformed ones should wither away over time (and with the throwing of suitable LARTs). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Thu Nov 4 09:12:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HCZfM049498 for ; Thu, 4 Nov 2004 09:12:35 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA4HCZJs049497 for ietf-usefor-skb; Thu, 4 Nov 2004 09:12:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA4HCY88049482 for ; Thu, 4 Nov 2004 09:12:34 -0800 (PST) (envelope-from news@clerew.man.ac.uk) Received: from host81-144-72-189.midband.mdip.bt.net [81.144.72.189] by lon-mail-3.gradwell.net with esmtp (Gradwell gwh-smtpd 1.151) id 418a6304.13db4.2 for ietf-usefor@imc.org; Thu, 4 Nov 2004 17:12:36 +0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id iA4HCNr17760 for ietf-usefor@imc.org; Thu, 4 Nov 2004 17:12:23 GMT To: LIST: ietf-usefor@imc.org; Xref: clerew local.usefor:20254 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Re: Standardize Complaints-To as deployed? Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> <4188C9F0.6020905@isode.com> <4188CAD0.1080902@isode.com> <41895E2E.5C57@xyzzy.claranet.de> <87sm7qwnse.fsf@windlord.stanford.edu> Date: Thu, 4 Nov 2004 16:20:04 GMT Lines: 46 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <87sm7qwnse.fsf@windlord.stanford.edu> Russ Allbery writes: >Frank Ellermann writes: >> Okay, then it's clear, and Charles said the same. I like >> this proposal, it's less trouble to catch _one_ forged >> header with all the injection info (for injecting agents). >> The geeks will love it, as Charles said, and only geeks >> need the complaint address. And for spammers it's more >> difficult to forge the complete Injection-Info. Besides >> I like KISS instead of "yet another header". Bye, Frank >I'm not particularly a fan of Injection-Info, but I'm willing to keep it >around as a compromise and given that, I think it probably does make sense >to combine the two. >I still do think that the complaint parameter, however we represent it, >should be a URL rather than an e-mail address. This is one of those >principals like not imposing arbitrary limits on fields. A URL is more >general and more flexible than an e-mail address; I don't know if, ten >years down the road, we'll regret having only an e-mail address or will >want a URL, but I don't see any reason to risk it. The people who were arguing against URLs were really arguing against URLs that pointed to web sites (like the ntlworld one that I quoted). It needs to be made clear that Netnews and the Web are different media, and things must be so that a user who has News access but no Web access is not disadvantaged. Now if we were to restrict the URL to be only 'mailto', then I might buy it, but then you have the problem that if you give them an inch the more clueless providers out there will just take a mile and use 'http' URLs, legally or not. So my preference is to leave it as just the email address (and using a Complaints-To header just to emphasise the point). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Thu Nov 4 19:12:37 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA53Cb7b086674 for ; Thu, 4 Nov 2004 19:12:37 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA53CbU3086670 for ietf-usefor-skb; Thu, 4 Nov 2004 19:12:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp809.mail.ukl.yahoo.com (smtp809.mail.ukl.yahoo.com [217.12.12.199]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA53CZtD086617 for ; Thu, 4 Nov 2004 19:12:36 -0800 (PST) (envelope-from news@clerew.man.ac.uk) Received: from unknown (HELO host81-144-71-164.midband.mdip.bt.net) (ietf-usefor@imc.org@81.144.71.164 with poptime) by smtp809.mail.ukl.yahoo.com with SMTP; 5 Nov 2004 03:12:20 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id iA53CAB22387 for ietf-usefor@imc.org; Fri, 5 Nov 2004 03:12:10 GMT To: LIST: ietf-usefor@imc.org; Xref: clerew local.usefor:20259 Newsgroups: local.usefor Path: clerew!chl From: "Charles Lindsey" Subject: Path Punctuation summary Content-Type: text/plain; charset=iso-8859-1 Message-ID: Content-Transfer-Encoding: 8bit X-Newsreader: NN version 6.5.2 (NOV) Mime-Version: 1.0 Date: Thu, 4 Nov 2004 21:35:49 GMT Lines: 117 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I first posted this in the middle of August, when I was away from home (which maybe explains why it never made it to the list). So when I was home again, and it was clear that it had not made it, I posted it again on August 27th. I don't know whether it made it that time (did any of you see it?), but what is clear is that Landfield was in a bad state at that time because nothing had been archived since August 13th. At some later stage, in the middle of September, some of the missing articles miraculously appeared in the Archive, but not this one (and I think serveral other people's must be missing also because the archive is showing only two messages posted at all in the last 5 days of August). So here it is again, for the third time :-( . There was earlier discussion concerning which delimiters could be used on the Path header, having regard to the vagueness of the word "punctuation" as used in RFC 1036. Given that the checks we have put into the Path-header are generally agreed to be desirable for tracing the origin of scams of various sorts, and that the principle problem seems to be whether the characters proposed as delimiters for this purpose would cause problems with existing implementations, here is a summary of some of the options we could consider. First, the scheme as proposed requires that relaying agents should be able to make the following assertions when they add a new path-identity to the Path-header: #1 I am the injecting site. #2 I have checked the identity of the previous site, and I believe the path-identity inserted by that site to be correct. #3 I have checked the identity of the previous site, and I do not believe the path-identity claimed by that site; here is what I believe to be the true identity of that site. #4 I have made no checks on the identity of the previous site. In the following running example injector.com always uses #1 new-site.com always uses #2 or #3 good-site.com always uses #2 or #3 old-site always uses #4 dodgy.com was a bogus identity actually inserted by mallet.com A. Current draft: ----------------- Uses '%' for #1, '/' for #2, '?' for #3 amd '!' for #4 Path: good-site.com/mallet.com?dodgy.com!old-site.com! new-site.com/injector.com%not-for-mail B. Henry's proposal : ------------------------------------------------------------------ Uses '@' for #1, ',' for #2, ' ' for #3 amd '!' for #4, since it is clear from RFC 1036 that all of those are intended to be usable as delimiters. Path: good-site.com,mallet.com dodgy.com!old-site.com! new-site.com,injector.com@not-for-mail Observe that the ' ' delimiter turns up rather conveniently as a separator between the correct and bogus identities of mallet.com. One would need to discuss whether FWS as well as SP should delimit this case. C. The Diablo scheme -------------------- I still have not been able to find documentation on this, but from observed instances it appears to work as follows: Path: good-site.com!mallet.com.MISMATCH!dodgy.com!old-site.com! new-site.com!injector.com.POSTED!not-for-mail I see 2 problems with this one: 1: Any site which peers with injector.com (e.g. new-site.com) would normally scan the received Path for occurrences of "injector.com", and would send the article back to injector.com if it was not found (which, of course, it isn't here ecause it recorded itself as "injector.com.POSTED"). 2: It provides no distinction betwen cases #2 and #4, which rather defeats the object of the whole exercise. D. Another possible scheme -------------------------- If you want to avoid all delimiters other than '!', and to overcome the problems with the Diablo scheme, then here is one which relies on special keywords "M", "MISMATCH" and "POSTED" in places where the current syntax would expect a path-identity. Path: good-site.com!M!mallet.com!MISMATCH!dodgy.com!old-site.com! new-site.com!M!injector.com!POSTED!not-for-mail It makes the Path a little longer, but not unacceptably so, and assumes that those keywords will never represent real sites. Comments? I think I would prefer Henry's scheme out of that bunch, but there might also be the possibility of using some of the other delimiters known to be used in the BNews implementation, which Bruce considers might be safe. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor Fri Nov 5 04:18:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5CINhl029064 for ; Fri, 5 Nov 2004 04:18:23 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5CINo9029062 for ietf-usefor-skb; Fri, 5 Nov 2004 04:18:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5CIJ8o028890 for ; Fri, 5 Nov 2004 04:18:19 -0800 (PST) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CQ32h-0005bv-00 for ; Fri, 05 Nov 2004 13:18:11 +0100 Received: from c-134-88-38.hh.dial.de.ignite.net ([62.134.88.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Nov 2004 13:18:11 +0100 Received: from nobody by c-134-88-38.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Nov 2004 13:18:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Standardize Complaints-To as deployed? Date: Fri, 05 Nov 2004 13:16:33 +0100 Organization: Lines: 40 Message-ID: <418B6F21.5A5D@xyzzy.claranet.de> References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> <4188C9F0.6020905@isode.com> <4188CAD0.1080902@isode.com> <41895E2E.5C57@xyzzy.claranet.de> <87sm7qwnse.fsf@windlord.stanford.edu> <418A41B4.7498@xyzzy.claranet.de> <87u0s5oa3c.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-38.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: [weird mailto: abuse URL as multiline 2231 parameter] > How is this any worse than not providing a complaints-to > address at all? The alternative is a plain mailbox address, not "no abuse address at all". >> several pages of security considerations plus an appendix I >> "IRIs in the abuse-reports parameter of Injection-Info". > I believe that the security considerations of visiting URLs > are already dealt with in adequate depth by other RFCs that > we can simply refer to, Probably, 2396bis is already in the RfC-editor queue. But I'm lost with IRIs, all I know for sure about IRIs is "this doesn't work with my good old Mozilla 3 without UTF-8". > However, if people would prefer to have both an email and a > url parameter, that would also be fine with me. That would cover GMaNe, your article has the following headers: X-Complaints-To: usenet@sea.gmane.org X-Trace: sea.gmane.org 1099585603 14799 80.91.229.6 (4 Nov 2004 16:26:43 GMT) NNTP-Posting-Host: deer.gmane.org NNTP-Posting-Date: Thu, 4 Nov 2004 16:26:43 +0000 (UTC) X-Report-Spam: http://spam.gmane.org/gmane.ietf.usenet.format:27779 Please don't click on the link, "unreporting" reported spam with GMaNe can be tricky. With both formats in Injection-Info GMaNe could replace four headers by a single header. And it would be easy to replace this stuff if it's reinjected somehow elsewhere. Bye, Frank From owner-ietf-usefor Fri Nov 5 04:33:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5CXuUf039825 for ; Fri, 5 Nov 2004 04:33:56 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5CXuq6039824 for ietf-usefor-skb; Fri, 5 Nov 2004 04:33:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5CXs5K039811 for ; Fri, 5 Nov 2004 04:33:55 -0800 (PST) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CQ3Hv-0006Z7-00 for ; Fri, 05 Nov 2004 13:33:55 +0100 Received: from c-134-88-38.hh.dial.de.ignite.net ([62.134.88.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Nov 2004 13:33:55 +0100 Received: from nobody by c-134-88-38.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Nov 2004 13:33:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Standardize Complaints-To as deployed? Date: Fri, 05 Nov 2004 13:33:02 +0100 Organization: Lines: 19 Message-ID: <418B72FE.2420@xyzzy.claranet.de> References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-38.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: > Of course, if we bless it with standardization, then the > malformed ones should wither away over time (and with the > throwing of suitable LARTs). A new Whatever: doesn't exist yet, and as soon as it exists getting rid of a few malformed Whatever: should be easy. But IMHO you can't "deprecate" old X-Whatever:, because I'm free to invent and use X-Whatever: in any form I like. No X-Whatever: can be "malformed", it's unstructured gibberish. I've seen the same idea of "deprecating" X-Archived-At:, but AFAIK that's not how it's supposed to work. Please correct me if my idea of X- headers is wrong. Bye, Frank From owner-ietf-usefor Fri Nov 5 05:14:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5DEHl1057716 for ; Fri, 5 Nov 2004 05:14:17 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5DEHnc057715 for ietf-usefor-skb; Fri, 5 Nov 2004 05:14:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5DEGrE057697 for ; Fri, 5 Nov 2004 05:14:16 -0800 (PST) (envelope-from usenet-format@gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CQ3uz-00014p-00 for ; Fri, 05 Nov 2004 14:14:17 +0100 Received: from c-134-88-38.hh.dial.de.ignite.net ([62.134.88.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Nov 2004 14:14:17 +0100 Received: from nobody by c-134-88-38.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Nov 2004 14:14:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Path Punctuation summary Date: Fri, 05 Nov 2004 14:12:47 +0100 Organization: Lines: 35 Message-ID: <418B7C4F.86C@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-38.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: > I think I would prefer Henry's scheme out of that bunch Yes, it's nice. For a scheme based on s-o-1036 (only "!") like POSTED and MISMATCH I'd prefer other "keywords": POSTED => LOCALHOST MISMATCH => INVALID But TEST for M would result in messy Path: headers, that idea probably can't fly. I don't like M, MISMATCH, and POSTED because it's very near to odd cases like host TV. tv = 65.201.175.144 The poor TV has a serious problem with a bug (?) in 2821: | A domain (or domain name) consists of one or more | dot-separated components. True. | The domain name, as described in this document and in [22], | is the entire, fully-qualified name (often referred to as | an "FQDN"). True, [22] is 1035 resp. Std 13 | Domain = (sub-domain 1*("." sub-domain)) / address-literal But that's wrong, or isn't it ? There's no dot in FQDN tv. Bye, Frank From owner-ietf-usefor Fri Nov 5 09:12:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5HCWJQ043397 for ; Fri, 5 Nov 2004 09:12:32 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5HCWl5043396 for ietf-usefor-skb; Fri, 5 Nov 2004 09:12:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5HCWgU043390 for ; Fri, 5 Nov 2004 09:12:32 -0800 (PST) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id iA5HCX58004833 for ; Fri, 5 Nov 2004 09:12:34 -0800 Received: (qmail 6446 invoked by uid 1000); 5 Nov 2004 17:12:33 -0000 To: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? In-Reply-To: <418B72FE.2420@xyzzy.claranet.de> (Frank Ellermann's message of "Fri, 05 Nov 2004 13:33:02 +0100") References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <418B72FE.2420@xyzzy.claranet.de> From: Russ Allbery Organization: The Eyrie Date: Fri, 05 Nov 2004 09:12:33 -0800 Message-ID: <87k6t0rzi6.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann writes: > But IMHO you can't "deprecate" old X-Whatever:, because I'm > free to invent and use X-Whatever: in any form I like. No > X-Whatever: can be "malformed", it's unstructured gibberish. Headers beginning with X-* have no special meaning or significance as of RFC 2822. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Fri Nov 5 09:11:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5HBxJd043246 for ; Fri, 5 Nov 2004 09:11:59 -0800 (PST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA5HBx66043245 for ietf-usefor-skb; Fri, 5 Nov 2004 09:11:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.123]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5HBwPl043239 for ; Fri, 5 Nov 2004 09:11:58 -0800 (PST) (envelope-from rra@stanford.edu) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id iA5HBxg5004660 for ; Fri, 5 Nov 2004 09:12:00 -0800 Received: (qmail 6431 invoked by uid 1000); 5 Nov 2004 17:11:59 -0000 To: ietf-usefor@imc.org Subject: Re: Standardize Complaints-To as deployed? In-Reply-To: <418B6F21.5A5D@xyzzy.claranet.de> (Frank Ellermann's message of "Fri, 05 Nov 2004 13:16:33 +0100") References: <4161AC98.1010000@isode.com> <417414F5.6020500@isode.com> <87sm7t6n4e.fsf@windlord.stanford.edu> <41877F8C.7000402@isode.com> <4187E75F.1099@xyzzy.claranet.de> <4188C9F0.6020905@isode.com> <4188CAD0.1080902@isode.com> <41895E2E.5C57@xyzzy.claranet.de> <87sm7qwnse.fsf@windlord.stanford.edu> <418A41B4.7498@xyzzy.claranet.de> <87u0s5oa3c.fsf@windlord.stanford.edu> <418B6F21.5A5D@xyzzy.claranet.de> From: Russ Allbery Organization: The Eyrie Date: Fri, 05 Nov 2004 09:11:59 -0800 Message-ID: <87oeicrzj4.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Frank Ellermann writes: > Russ Allbery wrote: > [weird mailto: abuse URL as multiline 2231 parameter] >> How is this any worse than not providing a complaints-to >> address at all? > The alternative is a plain mailbox address, not "no abuse > address at all". Why do you think that? I don't understand why anyone thinks that banning URLs is going to convince ISPs to provide plain mailbox addresses as abuse reporting venues when they wanted to use a web form. If I were an ISP convinced I wanted to use a web form, requiring an address would just mean that I didn't provide that parameter and instead added some other header with the URL. I understand the behavior that people want to modify here, but the way in which people are trying to go about modifying behavior is, frankly, not going to work, and hurts our future flexibility. > That would cover GMaNe, your article has the following headers: > X-Complaints-To: usenet@sea.gmane.org > X-Trace: sea.gmane.org 1099585603 14799 80.91.229.6 > (4 Nov 2004 16:26:43 GMT) > NNTP-Posting-Host: deer.gmane.org > NNTP-Posting-Date: Thu, 4 Nov 2004 16:26:43 +0000 (UTC) > X-Report-Spam: > http://spam.gmane.org/gmane.ietf.usenet.format:27779 The Gmane X-Report-Spam header is something completely different than what we're talking about, unless I'm seriously mistaken as to what it's for. I believe that it is for collaborative spam filtering, not for abuse complaints. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor Fri Nov 5 12:09:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA5K9F6M017866