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