Count of senders to this mailing list, April 30
Harald Alvestrand <harald@alvestrand.no> Mon, 30 April 2007 14:15 UTC
Return-path: <owner-ietf-usefor@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiWfT-00057g-J4 for usefor-archive@lists.ietf.org; Mon, 30 Apr 2007 10:15:55 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiWfS-0005Ek-7N for usefor-archive@lists.ietf.org; Mon, 30 Apr 2007 10:15:55 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UEDPX0073606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 07:13:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UEDPHG073605; Mon, 30 Apr 2007 07:13:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UED4Sl073557 for <ietf-usefor@imc.org>; Mon, 30 Apr 2007 07:13:25 -0700 (MST) (envelope-from harald@alvestrand.no)
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 906CA2596D1 for <ietf-usefor@imc.org>; Mon, 30 Apr 2007 16:13:04 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28171-01 for <ietf-usefor@imc.org>; Mon, 30 Apr 2007 16:12:59 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D9892596CB for <ietf-usefor@imc.org>; Mon, 30 Apr 2007 16:12:59 +0200 (CEST)
Message-ID: <4635F96B.7030201@alvestrand.no>
Date: Mon, 30 Apr 2007 16:12:59 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Usenet <ietf-usefor@imc.org>
Subject: Count of senders to this mailing list, April 30
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: owner-ietf-usefor@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Thought I might just as well sum for the month... 1 21 32.31 "Charles Lindsey" <chl@clerew.man.ac.uk> 2 19 61.54 Russ Allbery <rra@stanford.edu> 3 11 78.46 Frank Ellermann <nobody@xyzzy.claranet.de> 4 9 92.31 Harald Alvestrand <harald@alvestrand.no> 5 2 95.38 "Forrest J. Cavalier III" <mibsoft@mibsoftware.com> 6 1 96.92 Dan Schlitt <schlitt@world.std.com> 7 1 98.46 Richard Clayton <richard@highwayman.com> 8 1 100.00 rbabel@babylon.pfm-mainz.de (Ralph Babel from the peanut gallery) Total: 65 messages Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UEDPX0073606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2007 07:13:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3UEDPHG073605; Mon, 30 Apr 2007 07:13:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3UED4Sl073557 for <ietf-usefor@imc.org>; Mon, 30 Apr 2007 07:13:25 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 906CA2596D1 for <ietf-usefor@imc.org>; Mon, 30 Apr 2007 16:13:04 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28171-01 for <ietf-usefor@imc.org>; Mon, 30 Apr 2007 16:12:59 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D9892596CB for <ietf-usefor@imc.org>; Mon, 30 Apr 2007 16:12:59 +0200 (CEST) Message-ID: <4635F96B.7030201@alvestrand.no> Date: Mon, 30 Apr 2007 16:12:59 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Usenet <ietf-usefor@imc.org> Subject: Count of senders to this mailing list, April 30 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Thought I might just as well sum for the month... 1 21 32.31 "Charles Lindsey" <chl@clerew.man.ac.uk> 2 19 61.54 Russ Allbery <rra@stanford.edu> 3 11 78.46 Frank Ellermann <nobody@xyzzy.claranet.de> 4 9 92.31 Harald Alvestrand <harald@alvestrand.no> 5 2 95.38 "Forrest J. Cavalier III" <mibsoft@mibsoftware.com> 6 1 96.92 Dan Schlitt <schlitt@world.std.com> 7 1 98.46 Richard Clayton <richard@highwayman.com> 8 1 100.00 rbabel@babylon.pfm-mainz.de (Ralph Babel from the peanut gallery) Total: 65 messages Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3TLtp7V031620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Apr 2007 14:55:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3TLtpcT031619; Sun, 29 Apr 2007 14:55:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3TLtnbF031612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Sun, 29 Apr 2007 14:55:50 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HiHMm-0001s8-DZ for ietf-usefor@imc.org; Sun, 29 Apr 2007 23:55:38 +0200 Received: from du-001-227.access.de.clara.net ([212.82.227.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 29 Apr 2007 23:55:36 +0200 Received: from nobody by du-001-227.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 29 Apr 2007 23:55:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: Fwd: draft-resnick-2822upd-01 posted Date: Sun, 29 Apr 2007 23:53:34 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 15 Message-ID: <463513DE.65F8@xyzzy.claranet.de> References: <p0630000fc2580090b3f7@[216.43.25.67]> 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-227.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Pete Resnick wrote: > Please follow the discussion on ietf-822@imc.org. [...] > <http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt> My attempt to post a rationale why NO-WS-CTL is bad and "canonical" Message-IDs are good on the rfc822 list was rather clumsy. Please help to improve this if you think that RFC.ietf-usefor-usefor-12 got this right (modulo "magic SP" and other Netnews peculiarities): <http://permalink.gmane.org/gmane.ietf.rfc822/11834> Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3T2WZhQ050901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Apr 2007 19:32:35 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3T2WZO0050900; Sat, 28 Apr 2007 19:32:35 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.20.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3T2WYZk050891 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:32:34 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 20CA84DFFF for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:32:34 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id C4DA24DFFA for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:32:33 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id BB6ABE790B; Sat, 28 Apr 2007 19:32:33 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: #1416 Injection-Date: current wording proposal (corrected) Organization: The Eyrie User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) Date: Sat, 28 Apr 2007 19:32:33 -0700 Message-ID: <87slaj6hby.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Gr. Ignore the previous version of this message. Saving the file before regenerating the diff is useful. Please ignore the previous version and use this one instead. Here's the updated wording proposal taking Frank's review into account. This time I'll try XML diff, which I think is a little more readable (and way easier to prepare) than trying to extract meaning from the text diff with all the section numbering and pagination changes. I think it may be worthwhile to reach consensus on several parts of this separately. For example, if we decide that the whole current history section is fine, I can incorporate that into the draft and then stop including it in further diffs for discussion. --- usepro.xml 2007-02-19 22:20:06.000000000 -0800 +++ usepro-1416.xml 2007-04-28 19:30:11.000000000 -0700 @@ -165,8 +165,9 @@ <t>"Injecting" an article is the processing of a proto-article by an injecting agent. Normally this action is done once and only - once for a given article. "Reinjecting" an article is passing an - already-injected article to an injection agent.</t> + once for a given article. "Multiple injection" is passing the + same article to multiple injecting agents, either serially or in + parallel.</t> <t>A "gateway" is software which receives news articles and converts them to messages of some other kind (such as <xref @@ -446,6 +447,68 @@ </section> </section> + <section anchor="history" + title="Article History and Duplicate Suppression"> + <t>Netnews normally uses a flood-fill algorithm for propagation of + articles in which each news server offers articles it accepts to + multiple peers and each news server may be offered the same + article from multiple other news servers. Accordingly, duplicate + suppression is key; if a news server accepted every article it was + offered, it may needlessly accept (and then potentially + retransmit) dozens of copies of every article.</t> + + <t>Relaying and serving agents therefore MUST keep a record of + articles they have already seen and use that record to reject + additional offers of the same article. This record is called the + history file or database.</t> + + <t>Each article is uniquely identified by its message identifier, + so a relaying or serving agent could satisfy this requirement by + storing a record of every message identifier that agent has ever + seen. Such a history database would grow without bound, however, + so it is common and permitted to optimize based on the + Injection-Date or Date header field of an article as follows. (In + the following discussion, the "date" of an article is defined to + be the date represented by its Injection-Date header field if + present, otherwise its Date header field.) + <list style="symbols"> + <t>Agents MAY select a cutoff interval and reject any article + with a date farther in the past than that cutoff interval. If + this interval is shorter than the time it takes for an article + to propagate through the network, the agent may reject an + article it had not yet seen, so it ought not be aggressively + short. For Usenet, for example, a cutoff interval of no less + than seven days is conventional.</t> + + <t>Agents that enforce such a cutoff MAY then drop records of + articles that had dates older than the cutoff from their + history databases. If such an article were offered to the + agent again, it would be rejected due to the cutoff date, so + the history record is no longer required to suppress the + duplicate.</t> + + <t>As an optimization for easier history database + manipulation, agents MAY instead drop history records written + longer ago than the cutoff interval plus one day. If this + retention mechanism is used, the history retention period MUST + be longer than the cutoff interval to allow for articles dated + in the future unless the agent rejects all articles dated in + the future. One day is the maximum allowed error into the + future for article dates, so it is a convenient and safe + extension for the retention interval.</t> + </list> + </t> + + <t>This is just one implementation strategy for article history, + albeit the most common one. Relaying and serving agents are not + required to use this strategy, only to meet the requirement of not + accepting an article more than once. However, implementors of + general-purpose Netnews relaying and serving agents who do not + have extensive experience with Netnews and the subtle effects of + its flood-fill algorithm are encouraged to use the above algorithm + by default.</t> + </section> + <section anchor="posting" title="Duties of a Posting Agent"> <t>A posting agent is the component of a user agent that assists a poster in creating a valid proto-article and forwarding it to an @@ -453,9 +516,33 @@ <t>Posting agents SHOULD ensure that proto-articles they create are valid according to <xref target="USEFOR" /> and any other - applicable policies. They MUST NOT create any Injection-Date or - Injection-Info header fields; these headers will be added by the - injecting agent.</t> + applicable policies. They MUST NOT create an Injection-Info + header field; this header field will be added by the injecting + agent.</t> + + <t>If a proto-article contains both Message-ID and Date header + fields, posting agents MAY add an Injection-Date header field to + that proto-article immediately before passing that proto-article + to an injection agent. They SHOULD do so if the Date header field + (representing the composition time of the proto-article) is more + than a day in the past at the time of injection. If the + proto-article is being sent to more than one injecting agent, see + <xref target="multi-injection" />.</t> + + <t>The Injection-Date header field is new in this revision of the + Netnews protocol and is designed to permit the Date header field + to hold the composition date (as defined in section 3.6.1 of <xref + target="RFC2822" />), even if the proto-article is not injected + for some time after its composition. However, note that all + implementations predating this specification ignore the + Injection-Date header field and use the Date header field in its + stead for rejecting articles older than their cutoff (see <xref + target="history" />), and injecting agents predating this + specification do not add an Injection-Date header. Articles with + a Date header field substantially in the past will still be + rejected by implementations predating this specification, + regardless of the Injection-Date header field, and may suffer poor + propagation.</t> <t>Contrary to <xref target="RFC2822" />, which implies that the mailbox or mailboxes in the From header field should be that of @@ -478,48 +565,70 @@ agent.</t> <t>A proto-article has the same format as a normal article - except that the Injection-Date, Injection-Info, and Xref header - fields MUST NOT be present; the Path header field MUST NOT - contain a "POSTED" <diag-keyword>; and any of the following - mandatory header fields MAY be omitted: Message-ID, Date, and - Path. In all other respects, a proto-article MUST be a valid - Netnews article. In particular, the header fields which may be - omitted MUST NOT be present with invalid content.</t> + except that the Injection-Info and Xref header fields MUST NOT + be present; the Path header field MUST NOT contain a "POSTED" + <diag-keyword>; and any of the following mandatory header + fields MAY be omitted: Message-ID, Date, and Path. In all other + respects, a proto-article MUST be a valid Netnews article. In + particular, the header fields which may be omitted MUST NOT be + present with invalid content.</t> <t>If a posting agent intends to offer the same proto-article to - multiple injecting agents, the header fields Message-ID and Date - MUST be present and identical in all copies of the - proto-article.</t> + multiple injecting agents, the header fields Message-ID, Date, + and Injection-Date MUST be present and identical in all copies + of the proto-article. See <xref target="multi-injection" />.</t> </section> - <section anchor="reinjection" title="Reinjection of Articles"> - <t>A given article SHOULD be processed by an injecting agent - once and only once. The Injection-Date or Injection-Info - header fields are added by an injecting agent and are not - permitted in a proto-article. Their presence (or the presence - of other unstandardized or obsolete trace headers such as - NNTP-Posting-Host, NNTP-Posting-Date, or X-Trace) indicates - that the proto-article is instead an article and has already - been processed by an injecting agent. A posting agent SHOULD - normally reject such articles.</t> - - <t>In the exceptional case that an article needs to be - reinjected for some reason (such as transferring an article from - one Netnews to another where those networks have no relaying - agreement), the posting agent doing the reinjection MUST convert - the article back into a proto-article before passing it to an - injecting agent (such as by renaming the Injection-Info and - Injection-Date header fields and removing any Xref header field) - and MUST perform the date checks on the existing Injection-Date - or Date header fields that would otherwise be done by the - injecting agent.</t> - - <t>Reinjecting articles may cause loops, loss of trace - information, and other problems and should only be done with - care and when there is no available alternative. A posting - agent that does reinjection is a limited type of gateway and as - such is subject to all of the requirements of an incoming - gateway in addition to the requirements of a posting agent.</t> + <section anchor="multi-injection" + title="Multiple Injection of Articles"> + <t>Under some circumstances (posting to multiple disjoint + networks, injecting agents with spotty connectivity, or + redundancy, for example), a posting agent may wish to offer the + same article to multiple injecting agents. In this unusual + case, the goal is to not create multiple independent articles + but rather to inject the same article at multiple points and let + the normal duplicate suppression facility of Netnews (see + <xref target="history" />) ensure that any given agent only + accepts the article once.</t> + + <t>Whenever possible, multiple injection SHOULD be done by + offering the same proto-article to multiple injecting agents. + The posting agent MUST supply the Message-ID, Date, and + Injection-Date header fields, and the proto-article offered to + each injecting agent MUST be identical.</t> + + <t>In some cases, offering the same proto-article to all + injecting agents may not be possible (such as when transferring, + after the fact, articles found on one Netnews network to + another, unconnected one). In this case, the posting agent MUST + convert the article back into a proto-article before passing it + to another injecting agent, but it MUST retain unmodified the + Message-ID, Date, and Injection-Date header fields. It MUST NOT + add an Injection-Date header field if it is missing from the + existing article. It MUST remove any Xref header field and + either rename or remove any Injection-Info header field and + other trace fields.</t> + + <t>Multiple injection inherently risks duplicating articles. + Multiple injection after the fact, by converting an article back + to a proto-article and injecting it again, additionally risks + loops, loss of trace information, and other problems and should + be done with care and only when there is no alternative. The + requirement to retain Message-ID, Date, and Injection-Date + header fields minimizes the possibility of a loop and ensures + that the newly injected article is not treated as a new, + separate article.</t> + + <t>Multiple injection of an article listing one or more + moderated newsgroups in its Newsgroups header field SHOULD only + be done by a moderator and MUST only be done after the + proto-article is approved for all moderated groups to which it + is posted and has an Approved header field. Multiple injection + of an unapproved article intended for moderated newsgroups will + normally only result in the moderator receiving multiple copies, + and if the newsgroup status is not consistent across all + injecting agents, may result in duplication of the article or + other problems.</t> </section> <section anchor="followups" title="Followups"> @@ -644,23 +753,24 @@ <t>It MUST reject any proto-article that does not have the proper mandatory header fields for a proto-article; that has - Injection-Date, Injection-Info, or Xref header fields; that - has a Path header field containing the "POSTED" - <diag-keyword>; or that is not syntactically valid as - defined by <xref target="USEFOR" />. It SHOULD reject any - proto-article which contains a header field deprecated for - Netnews. It MAY reject any proto-article that contains trace - header fields indicating that it was already injected by an - injecting agent that did not add Injection-Info or - Injection-Date.</t> + Injection-Info or Xref header fields; that has a Path header + field containing the "POSTED" <diag-keyword>; or that is + not syntactically valid as defined by <xref target="USEFOR" + />. It SHOULD reject any proto-article which contains a + header field deprecated for Netnews. It MAY reject any + proto-article that contains trace header fields indicating + that it was already injected by an injecting agent that did + not add Injection-Info or Injection-Date.</t> <t>It SHOULD reject any article whose Date header field is more than 24 hours into the future (and MAY use a margin less than 24 hours). It SHOULD reject any article whose Date - header appears to be stale (more than 72 hours into the past, - for example, or too old to still be recorded in the database - of a relaying agent the injecting agent will be using) since - not all news servers support Injection-Date.</t> + header is too far into the past (older than the cutoff + interval of a relaying agent the injecting agent is using, for + example), since not all news servers support Injection-Date + and only the injecting agent can provide a useful error + message to the posting agent. This interval SHOULD NOT be any + shorter than 72 hours into the past.</t> <t>It SHOULD reject any proto-article whose Newsgroups header field does not contain at least one <newsgroup-name> for a @@ -704,8 +814,14 @@ the source of the article and possibly other trace information as described in Section 3.2.8 of <xref target="USEFOR" />.</t> - <t>The injecting agent MUST then add an Injection-Date header - field containing the current date and time.</t> + <t>If the proto-article already had an Injection-Date header + field, it MUST NOT be modified or replaced. If the + proto-article had both a Message-ID header field and a Date + header field, an Injection-Date header field MUST NOT be + added, since the proto-article may have been multiply injected + by a posting agent that predates this standard. Otherwise, + the injecting agent MUST add an Injection-Date header field + containing the current date and time.</t> <t>Finally, the injecting agent forwards the article to one or more relaying agents, and the injection process is @@ -801,18 +917,15 @@ field or Message-ID header field, or without either an Injection-Date or Date header field.</t> - <t>It MUST reject any article that has already been - successfully sent to it, based on the Message-ID header field - of the article. To satisfy this requirement, a relaying agent - normally keeps a database of message identifiers it has - already accepted.</t> - <t>It MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that - date predates the earliest articles of which it keeps record - or if that date is more than 24 hours into the future. It MAY - reject articles with dates in the future with a smaller margin - than 24 hours.</t> + date is more than 24 hours into the future. It MAY reject + articles with dates in the future with a smaller margin than + 24 hours.</t> + + <t>It MUST reject any article that has already been + successfully sent to it or that is dated older than its cutoff + date, as described in <xref target="history" />.</t> <t>It SHOULD reject any article that does not include all the mandatory header fields. It MAY reject any article that @@ -886,16 +999,13 @@ <t>It MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that - date predates the earliest articles of which it keeps record - or if that date is more than 24 hours into the future. It MAY - reject articles with dates in the future with a smaller margin - than 24 hours.</t> + date is more than 24 hours into the future. It MAY reject + articles with dates in the future with a smaller margin than + 24 hours.</t> <t>It MUST reject any article that has already been - successfully sent to it, based on the Message-ID header field - of the article. To satisfy this requirement, a relaying agent - normally keeps a database of message identifiers it has - already accepted.</t> + successfully sent to it or that is dated older than its cutoff + date, as described in <xref target="history" />.</t> <t>It SHOULD reject any article that matches an already-received and honored cancel message or Supersedes @@ -1003,8 +1113,7 @@ for reasons understood by the moderator (such as delays in the moderation process) in which case they MAY substitute the current date. Any Injection-Date, Injection-Info, or Xref - header fields already present (though there should be none) - MUST be removed.</t> + header fields already present MUST be removed.</t> <t>Any Path header field MUST either be removed or truncated to only those entries following its "POSTED" -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3T2S7sf050258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Apr 2007 19:28:07 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3T2S7BM050257; Sat, 28 Apr 2007 19:28:07 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.20.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3T2S6VE050234 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:28:06 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7553B4DFFA for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:28:06 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 25CE04DFF8 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:28:06 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 19B4DE790B; Sat, 28 Apr 2007 19:28:06 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: #1416 Injection-Date: current wording proposal Organization: The Eyrie Date: Sat, 28 Apr 2007 19:28:06 -0700 Message-ID: <877irv7w3t.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Here's the updated wording proposal taking Frank's review into account. This time I'll try XML diff, which I think is a little more readable (and way easier to prepare) than trying to extract meaning from the text diff with all the section numbering and pagination changes. I think it may be worthwhile to reach consensus on several parts of this separately. For example, if we decide that the whole current history section is fine, I can incorporate that into the draft and then stop including it in further diffs for discussion. --- usepro.xml 2007-02-19 22:20:06.000000000 -0800 +++ usepro-1416.xml 2007-04-28 19:04:17.000000000 -0700 @@ -165,8 +165,9 @@ <t>"Injecting" an article is the processing of a proto-article by an injecting agent. Normally this action is done once and only - once for a given article. "Reinjecting" an article is passing an - already-injected article to an injection agent.</t> + once for a given article. "Multiple injection" is passing the + same article to multiple injecting agents, either serially or in + parallel.</t> <t>A "gateway" is software which receives news articles and converts them to messages of some other kind (such as <xref @@ -446,6 +447,68 @@ </section> </section> + <section anchor="history" + title="Article History and Duplicate Suppression"> + <t>Netnews normally uses a flood-fill algorithm for propagation of + articles in which each news server offers articles it accepts to + multiple peers and each news server may be offered the same + article from multiple other news servers. Accordingly, duplicate + suppression is key; if a news server accepted every article it was + offered, it may needlessly accept (and then potentially + retransmit) dozens of copies of every article.</t> + + <t>Relaying and serving agents therefore MUST keep a record of + articles they have already seen and use that record to reject + additional offers of the same article. This record is called the + history file or database.</t> + + <t>Each article is uniquely identified by its message identifier, + so a relaying or serving agent could satisfy this requirement by + storing a record of every message identifier that agent has ever + seen. Such a history database would grow without bound, however, + so it is common and permitted to optimize based on the + Injection-Date or Date header field of an article as follows. (In + the following discussion, the "date" of an article is defined to + be the date represented by its Injection-Date header field if + present, otherwise its Date header field.) + <list style="symbols"> + <t>Agents MAY select a cutoff interval and reject any article + with a date farther in the past than that cutoff interval. If + this interval is shorter than the time it takes for an article + to propagate through the network, the agent may reject an + article it had not yet seen, so it ought not be aggressively + short. For Usenet, for example, a cutoff interval of no less + than seven days is conventional.</t> + + <t>Agents that enforce such a cutoff MAY then drop records of + articles that had dates older than the cutoff from their + history databases. If such an article were offered to the + agent again, it would be rejected due to the cutoff date, so + the history record is no longer required to suppress the + duplicate.</t> + + <t>As an optimization for easier history database + manipulation, agents MAY instead drop history records written + longer ago than the cutoff interval plus one day. If this + retention mechanism is used, the history retention period MUST + be longer than the cutoff interval to allow for articles dated + in the future unless the agent rejects all articles dated in + the future. One day is the maximum allowed error into the + future for article dates, so it is a convenient and safe + extension for the retention interval.</t> + </list> + </t> + + <t>This is just one implementation strategy for article history, + albeit the most common one. Relaying and serving agents are not + required to use this strategy, only to meet the requirement of not + accepting an article more than once. However, implementors of + general-purpose Netnews relaying and serving agents who do not + have extensive experience with Netnews and the subtle effects of + its flood-fill algorithm are encouraged to use the above algorithm + by default.</t> + </section> + <section anchor="posting" title="Duties of a Posting Agent"> <t>A posting agent is the component of a user agent that assists a poster in creating a valid proto-article and forwarding it to an @@ -453,9 +516,33 @@ <t>Posting agents SHOULD ensure that proto-articles they create are valid according to <xref target="USEFOR" /> and any other - applicable policies. They MUST NOT create any Injection-Date or - Injection-Info header fields; these headers will be added by the - injecting agent.</t> + applicable policies. They MUST NOT create an Injection-Info + header field; this header field will be added by the injecting + agent.</t> + + <t>If a proto-article contains both Message-ID and Date header + fields, posting agents MAY add an Injection-Date header field to + that proto-article immediately before passing that proto-article + to an injection agent. They SHOULD do so if the Date header field + (representing the composition time of the proto-article) is more + than a day in the past at the time of injection. If the + proto-article is being sent to more than one injecting agent, see + <xref target="multi-injection" />.</t> + + <t>The Injection-Date header field is new in this revision of the + Netnews protocol and is designed to permit the Date header field + to hold the composition date (as defined in section 3.6.1 of <xref + target="RFC2822" />), even if the proto-article is not injected + for some time after its composition. However, note that all + implementations predating this specification ignore the + Injection-Date header field and use the Date header field in its + stead for rejecting articles older than their cutoff (see <xref + target="history" />), and injecting agents predating this + specification do not add an Injection-Date header. Articles with + a Date header field substantially in the past will still be + rejected by implementations predating this specification, + regardless of the Injection-Date header field, and may suffer poor + propagation.</t> <t>Contrary to <xref target="RFC2822" />, which implies that the mailbox or mailboxes in the From header field should be that of @@ -478,48 +565,70 @@ agent.</t> <t>A proto-article has the same format as a normal article - except that the Injection-Date, Injection-Info, and Xref header - fields MUST NOT be present; the Path header field MUST NOT - contain a "POSTED" <diag-keyword>; and any of the following - mandatory header fields MAY be omitted: Message-ID, Date, and - Path. In all other respects, a proto-article MUST be a valid - Netnews article. In particular, the header fields which may be - omitted MUST NOT be present with invalid content.</t> + except that the Injection-Info and Xref header fields MUST NOT + be present; the Path header field MUST NOT contain a "POSTED" + <diag-keyword>; and any of the following mandatory header + fields MAY be omitted: Message-ID, Date, and Path. In all other + respects, a proto-article MUST be a valid Netnews article. In + particular, the header fields which may be omitted MUST NOT be + present with invalid content.</t> <t>If a posting agent intends to offer the same proto-article to - multiple injecting agents, the header fields Message-ID and Date - MUST be present and identical in all copies of the - proto-article.</t> + multiple injecting agents, the header fields Message-ID, Date, + and Injection-Date MUST be present and identical in all copies + of the proto-article. See <xref target="multi-injection" />.</t> </section> - <section anchor="reinjection" title="Reinjection of Articles"> - <t>A given article SHOULD be processed by an injecting agent - once and only once. The Injection-Date or Injection-Info - header fields are added by an injecting agent and are not - permitted in a proto-article. Their presence (or the presence - of other unstandardized or obsolete trace headers such as - NNTP-Posting-Host, NNTP-Posting-Date, or X-Trace) indicates - that the proto-article is instead an article and has already - been processed by an injecting agent. A posting agent SHOULD - normally reject such articles.</t> - - <t>In the exceptional case that an article needs to be - reinjected for some reason (such as transferring an article from - one Netnews to another where those networks have no relaying - agreement), the posting agent doing the reinjection MUST convert - the article back into a proto-article before passing it to an - injecting agent (such as by renaming the Injection-Info and - Injection-Date header fields and removing any Xref header field) - and MUST perform the date checks on the existing Injection-Date - or Date header fields that would otherwise be done by the - injecting agent.</t> - - <t>Reinjecting articles may cause loops, loss of trace - information, and other problems and should only be done with - care and when there is no available alternative. A posting - agent that does reinjection is a limited type of gateway and as - such is subject to all of the requirements of an incoming - gateway in addition to the requirements of a posting agent.</t> + <section anchor="multi-injection" + title="Multiple Injection of Articles"> + <t>Under some circumstances (posting to multiple disjoint + networks, injecting agents with spotty connectivity, or + redundancy, for example), a posting agent may wish to offer the + same article to multiple injecting agents. In this unusual + case, the goal is to not create multiple independent articles + but rather to inject the same article at multiple points and let + the normal duplicate suppression facility of Netnews (see + <xref target="history" />) ensure that any given agent only + accepts the article once.</t> + + <t>Whenever possible, multiple injection SHOULD be done by + offering the same proto-article to multiple injecting agents. + The posting agent MUST supply the Message-ID, Date, and + Injection-Date header fields, and the proto-article offered to + each injecting agent MUST be identical.</t> + + <t>In some cases, offering the same proto-article to all + injecting agents may not be possible (such as when transferring, + after the fact, articles found on one Netnews network to + another, unconnected one). In this case, the posting agent MUST + convert the article back into a proto-article before passing it + to another injecting agent, but it MUST retain unmodified the + Message-ID, Date, and Injection-Date header fields. It MUST NOT + add an Injection-Date header field if it is missing from the + existing article. It MUST remove any Xref header field and + either rename or remove any Injection-Info header field and + other trace fields.</t> + + <t>Multiple injection inherently risks duplicating articles. + Multiple injection after the fact, by converting an article back + to a proto-article and injecting it again, additionally risks + loops, loss of trace information, and other problems and should + be done with care and only when there is no alternative. The + requirement to retain Message-ID, Date, and Injection-Date + header fields minimizes the possibility of a loop and ensures + that the newly injected article is not treated as a new, + separate article.</t> + + <t>Multiple injection of an article listing one or more + moderated newsgroups in its Newsgroups header field SHOULD only + be done by a moderator and SHOULD only be done after the + proto-article is approved for all moderated groups to which it + is posted and has an Approved header field. Multiple injection + of an unapproved article intended for moderated newsgroups will + normally only result in the moderator receiving multiple copies, + and if the newsgroup status is not consistent across all + injecting agents, may result in duplication of the article or + other problems.</t> </section> <section anchor="followups" title="Followups"> @@ -644,23 +753,24 @@ <t>It MUST reject any proto-article that does not have the proper mandatory header fields for a proto-article; that has - Injection-Date, Injection-Info, or Xref header fields; that - has a Path header field containing the "POSTED" - <diag-keyword>; or that is not syntactically valid as - defined by <xref target="USEFOR" />. It SHOULD reject any - proto-article which contains a header field deprecated for - Netnews. It MAY reject any proto-article that contains trace - header fields indicating that it was already injected by an - injecting agent that did not add Injection-Info or - Injection-Date.</t> + Injection-Info or Xref header fields; that has a Path header + field containing the "POSTED" <diag-keyword>; or that is + not syntactically valid as defined by <xref target="USEFOR" + />. It SHOULD reject any proto-article which contains a + header field deprecated for Netnews. It MAY reject any + proto-article that contains trace header fields indicating + that it was already injected by an injecting agent that did + not add Injection-Info or Injection-Date.</t> <t>It SHOULD reject any article whose Date header field is more than 24 hours into the future (and MAY use a margin less than 24 hours). It SHOULD reject any article whose Date - header appears to be stale (more than 72 hours into the past, - for example, or too old to still be recorded in the database - of a relaying agent the injecting agent will be using) since - not all news servers support Injection-Date.</t> + header is too far into the past (older than the cutoff + interval of a relaying agent the injecting agent is using, for + example), since not all news servers support Injection-Date + and only the injecting agent can provide a useful error + message to the posting agent. This interval SHOULD NOT be any + shorter than 72 hours into the past.</t> <t>It SHOULD reject any proto-article whose Newsgroups header field does not contain at least one <newsgroup-name> for a @@ -704,8 +814,14 @@ the source of the article and possibly other trace information as described in Section 3.2.8 of <xref target="USEFOR" />.</t> - <t>The injecting agent MUST then add an Injection-Date header - field containing the current date and time.</t> + <t>If the proto-article already had an Injection-Date header + field, it MUST NOT be modified or replaced. If the + proto-article had both a Message-ID header field and a Date + header field, an Injection-Date header field MUST NOT be + added, since the proto-article may have been multiply injected + by a posting agent that predates this standard. Otherwise, + the injecting agent MUST add an Injection-Date header field + containing the current date and time.</t> <t>Finally, the injecting agent forwards the article to one or more relaying agents, and the injection process is @@ -801,18 +917,15 @@ field or Message-ID header field, or without either an Injection-Date or Date header field.</t> - <t>It MUST reject any article that has already been - successfully sent to it, based on the Message-ID header field - of the article. To satisfy this requirement, a relaying agent - normally keeps a database of message identifiers it has - already accepted.</t> - <t>It MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that - date predates the earliest articles of which it keeps record - or if that date is more than 24 hours into the future. It MAY - reject articles with dates in the future with a smaller margin - than 24 hours.</t> + date is more than 24 hours into the future. It MAY reject + articles with dates in the future with a smaller margin than + 24 hours.</t> + + <t>It MUST reject any article that has already been + successfully sent to it or that is dated older than its cutoff + date, as described in <xref target="history" />.</t> <t>It SHOULD reject any article that does not include all the mandatory header fields. It MAY reject any article that @@ -886,16 +999,13 @@ <t>It MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that - date predates the earliest articles of which it keeps record - or if that date is more than 24 hours into the future. It MAY - reject articles with dates in the future with a smaller margin - than 24 hours.</t> + date is more than 24 hours into the future. It MAY reject + articles with dates in the future with a smaller margin than + 24 hours.</t> <t>It MUST reject any article that has already been - successfully sent to it, based on the Message-ID header field - of the article. To satisfy this requirement, a relaying agent - normally keeps a database of message identifiers it has - already accepted.</t> + successfully sent to it or that is dated older than its cutoff + date, as described in <xref target="history" />.</t> <t>It SHOULD reject any article that matches an already-received and honored cancel message or Supersedes @@ -1003,8 +1113,7 @@ for reasons understood by the moderator (such as delays in the moderation process) in which case they MAY substitute the current date. Any Injection-Date, Injection-Info, or Xref - header fields already present (though there should be none) - MUST be removed.</t> + header fields already present MUST be removed.</t> <t>Any Path header field MUST either be removed or truncated to only those entries following its "POSTED" -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3T2P3A4049862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Apr 2007 19:25:03 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3T2P3EC049861; Sat, 28 Apr 2007 19:25:03 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.20.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3T2OgYV049796 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:25:02 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6DB2E4C891 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:24:42 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 0CAC54C49B for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 19:24:42 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id E1895E790B; Sat, 28 Apr 2007 19:24:41 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1416: Reinjection and Injection-Date proposed text In-Reply-To: <462B978D.4816@xyzzy.claranet.de> (Frank Ellermann's message of "Sun, 22 Apr 2007 19:12:45 +0200") Organization: The Eyrie References: <87slatkn3x.fsf@windlord.stanford.edu> <462B978D.4816@xyzzy.claranet.de> Date: Sat, 28 Apr 2007 19:24:41 -0700 Message-ID: <87k5vv7w9i.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Frank Ellermann <nobody@xyzzy.claranet.de> writes: > Russ Allbery wrote: >> + it ought not be aggressively short. For For Usenet, for example, >> + a cutoff interval of no less than seven days is conventional. > Yes, no MUSTard needed here, the consequences are clear. Commercial > servers with shorter cutoff intervals for "binary" newsgroups may > need the support staff to answer complaints by their angry customers. Just for clarity in the discussion (I don't think a wording change is needed), note that the cutoff date for history retention is independent of the period of article retention in the spool. Usually the latter is longer than the former, but it may also be shorter. They don't need to be related. Normally, the cutoff date is set uniformly across the server regardless of the group, but the article retention period may be set much shorter for binary groups. The requirement is then that the server keep a record of those received and expired binary articles in the history file even after deleting the article off disk until they meet the cutoff requirements. >> - MUST NOT create any Injection-Date or Injection-Info header >> - fields; these headers will be added by the injecting agent. >> + MUST NOT create an Injection-Info header field; this headers will >> + be added by the injecting agent. > Nit: s/headers/header field/ Thanks, fixed. >> + The Injection-Date header field is new in this revision of the >> + Netnews protocol and is designed to permit the Date header field to >> + hold the composition date, even if the proto-article is not injected >> + for some time after its composition. > Please add a reference to RFC 2822 here, it's likely not only you who > hates this, it needs a compelling justification. Yes, good idea. Done. >> + Posting agents MAY add an Injection-Date header field and SHOULD do >> + so if the Date header field (representing the composition time of >> + the proto-article) is more than a day in the past in case the >> + injecting agent predates this specification. > I think you're mixing unrelated concepts here. The SHOULD is clear, > it doesn't need the qualifier starting with "in case...". The SHOULD > addresses the "stale 2822 date" issue among other problems. Yes, I think you're right. > The MAY is something more subtle, and from the text it's not clear if > this is limited to "more than a day ago". I _guess_ that the MAY is > about multiple injections, and you want to allow that posting agents > create their own unique Message-ID + Injection-Date combination. And > with some reading between the lines such smart posting agents might even > decide to ignore RFC 2822 and force a corresponding unique Date. The intention was to allow posting agents to add an Injection-Date header field any time they feel like it. The other point that's missing here is that the Injection-Date header shouldn't be added at the same point the Date header is. I now have: If a proto-article contains both Message-ID and Date header fields, posting agents MAY add an Injection-Date header field to that proto- article immediately before passing that proto-article to an injection agent. They SHOULD do so if the Date header field (representing the composition time of the proto-article) is more than a day in the past at the time of injection. If the proto-article is being sent to more than one injecting agent, see Section 3.4.2. The Injection-Date header field is new in this revision of the Netnews protocol and is designed to permit the Date header field to hold the composition date (as defined in section 3.6.1 of [RFC2822]), even if the proto-article is not injected for some time after its composition. However, note that all implementations predating this specification ignore the Injection-Date header field and use the Date header field in its stead for rejecting articles older than their cutoff (see Section 3.3), and injecting agents predating this specification do not add an Injection-Date header. Articles with a Date header field substantially in the past will still be rejected by implementations predating this specification, regardless of the Injection-Date header field, and may suffer poor propagation. on the grounds of putting the requirement first and then the explanation. >> + the header field Injection-Date SHOULD be present and identical in >> + all copies of the proto-article. See Section 3.4.2. > Yes, and the MAY mentioned above might be also related to 3.4.2, If > that's the case you've just overwritten it here by a SHOULD, or is the > MAY about a 3rd case ? Like a posting agent always creating its own > Injection-Date even if it's not one of the two SHOULDs, that could be a > 3rd case. In that case I hope that it gets "identical" right under all > foreseeable circumstances wrt the "multi-SHOULD". This was a bit of a mess. In my current draft, I've simplified this whole situation by saying that posting agents doing multiple injection MUST add the Injection-Date header field. This makes all existing multiple injection posting agents non-compliant, but we also did the same thing with injecting agents and their Injection-Date requirement, so this seems symmetric. I would prefer that the whole Injection-Date feature be either a SHOULD or a MUST, rather than using differing levels of requirement for different agents. Thoughts? And does anyone want to argue that the whole feature should be a SHOULD? >> + the goal is to not create multiple independent articles but >> + rather to inject the same article at multiple points and use the >> + normal duplicate suppression facility of Netnews (see Section 3.3) >> + ensure that any given agent only accepts the article once. > Nit: s/use/let/ Fixed. > The move from "reinjection" to "multiple injection" resulted in a > far better readable story. Yes, I was rather happy with that. Thanks to Harald for the suggestion. I think that casting of the idea makes everything much simpler. >> - A posting agent SHOULD normally reject such articles. > Odd, was that really a "posting agent" rejecting articles ? Yeah. Dumb idea on my part, in retrospect. It was discussed in some of the side-threads of this overall discussion, and I decided to drop it as part of these changes since the bits that it was referring to have now substantially changed anyway. >> + The posting agent MUST supply the Message-ID, Date, and >> + Injection-Date header fields, and the proto-article offered to >> + each injecting agent MUST be identical. > Some lines above it was a "multi-SHOULD", now you have a "multi-MUST" > for the Injection-Date. How about this: > | The posting agent MUST supply the Message-ID and the Date, it > | SHOULD also supply an Injection-Date, and the proto-article > | offered to each injecting agent MUST be identical. > Arguably you can also use MUST here as you have it, and replace > the "multi-SHOULD" at the end of 3.4.1 by MUST. But that would > render all existing posting agents with no idea about the new > Injection-Date as "non-conforming" when they try multi-Injection. As mentioned above, I went the MUST route, but I think it's a debatable point and I'd love to hear other comments. >> + It MUST remove any Xref header field and either rename or remove >> + any Injection-Info header field and other trace fields. > I see why they MUST remove Injection-Info, an old injecting agent would > let it pass causing havoc. But why MUST a posting agent remove Xref, > this job could be handled by the injecting agent ? > Is it "a simple MUST is better than more convoluted statements", > or do I miss a serious Xref-problem here ? It's more the former, plus backwards compatibility. Existing injecting agents will reject articles with Xref rather than remove the header. It seems simple enough given the other context to have posting agents remove it, and existing posting agents remove it, so I just said MUST instead of adding the explanation that existing injecting agents will reject and then go through and try to change the language to allow injecting agents to cope with it. >> + SHOULD only be done after the proto-article is approved for >> + all moderated groups to which it is posted and has an Approved >> + header field. > What's a good excuse to violate this SHOULD ? Is it a moderator > removing moderated and unapproved newsgroups, and injecting the article > at least for the approved or unmoderated newsgroups ? If there's no > good excuse I prefer a MUST. If the moderator changed anything about the Newsgroups header field, it would no longer be multiple injection as defined in this document. I can't think of any reason to ever violate that SHOULD, so I've provisionally changed it to MUST. (Well, I suppose there's the case where one has access to several injecting agents, each of which are unreliable, and therefore one is using multiple injection to try to increase the chances that at least one copy of the article gets to the moderator, but this is enough of a special case that I don't think we need to call that multiple injection as opposed to the poster intentionally posting several articles.) >> + This interval SHOULD NOT be any shorter than 72 hours into the >> + past. > That's a rather short minimum, barely enough for a normal weekend. > For this radical approach, how about a MUST NOT ? Disclaimer, I've > no idea about what's usual for "binary" newsgroups. But I doubt > that they have any use for the 2822-Date concept like "text" groups > or, more important, mail2news gateways. On Usenet, I think a MUST NOT would probably be warranted, but I wasn't comfortable enough saying that there would be no reason to ever use a shorter interval in any Netnews implementation. I don't really feel strongly about this, but I mildly lean towards SHOULD NOT here just on the grounds of permitting an out for some reason that we didn't anticipate. Of course, the presence of this provision for injecting agents in the draft at all is still being debated. I know Charles would prefer that it be removed, and I would like to get more feedback on that. >> + If the proto-article had both a Message-ID header field and a >> + Date header field, an Injection-Date header field MUST NOT be >> + added, since the proto-article may have been multiply injected >> + by a posting agent that predates this standard. Otherwise, the >> + injecting agent MUST add an Injection-Date header field >> + containing the current date and time. > We really need to check that you use MUST and SHOULD consistently. > How about a 2 * 2 table, two for legacy vs. new posting agent, and two > for legacy vs. new injecting agent, stating that all new agents MUST get > it right, resulting in an overall SHOULD for "any" agent. > Your MUST NOT + MUST above talks about new injecting agents. For the > MUST NOT it's obvious, a legacy agent doesn't know what the > Injection-Date is and has no problem with not adding it. But the MUST > is only for new agents. Overall it's a SHOULD, and legacy agents have a > good excuse to violate the overall SHOULD. Here's what it looked like before I started writing this section of my reply: Legacy posting agent, legacy injecting agent: No one will add Injection-Date since neither agent knows about it, although as a generic unknown header, either agent is permitted to do so. Legacy posting agent, compliant injecting agent: Posting agent won't add Injection-Date. Injecting agent MUST add Injection-Date if one or both of Date and Message-ID are not specified, otherwise MUST NOT (since multiple injection may be happening). Compliant posting agent, legacy injecting agent: Posting agent MAY add Injection-Date any time, SHOULD if the Date is more than a day in the past at the time of injection, MUST if doing multiple injection. The injecting agent doesn't know about the header and therefore will do nothing with it. Compliant posting agent, compliant injecting agent: Posting agent MAY add Injection-Date any time, SHOULD if the Date is more than a day in the past at the time of injection, MUST if doing multiple injection. Injecting agent generally MUST add the header if the posting agent doesn't. The one exception is if the posting agent provides both Message-ID and Date but not Injection-Date, which it is always allowed to do and which doesn't even violate a SHOULD if the Date is fresh. In this case, the injecting agent MUST NOT add it either. Looking at that table, and given that we have spelled out elsewhere how to handle articles with no Injection-Date, I think I agree with your point and don't see a reason for the injection agent requirement to be MUST. We already have a scenario in which a post only handled by compliant agents gets no Injection-Date and it doesn't break anything, so it seems like addition of Injection-Date by an injecting agent need only be a SHOULD. Opinions? This situation might change if we went with Charles's approach where injecting agents are permitted to add Injection-Date to posts that already have both Message-ID and Date. In that case, there is no gap. >> + It MAY reject articles with dates in the future with a smaller >> + margin than 24 hours. > Does that really help ? It's there to make it clear that some agents do not give you 24 hours of leeway and this is permitted in the protocol. It's redundant with the general rule that anyone can reject any article for any reason they please, but I felt like it was worth drawing special attention to this so that people don't think they can rely on having 24 hours of slop in the date checking. >> + the Date header field, and reject the article if that date is >> + more than 24 hours into the future. It MAY reject articles with >> + dates in the future with a smaller margin than 24 hours. > Same here, let's stick to one day, and get rid of less than one day. This wording should be identical to the wording called out above, so I'll change both if we decide to change it. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3T1iuUX045319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Apr 2007 18:44:56 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3T1iuVT045318; Sat, 28 Apr 2007 18:44:56 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3T1iXHk045276 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 18:44:55 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 37FB74C24A for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 18:44:33 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 2CA314BFA5 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 18:44:31 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 22481E790B; Sat, 28 Apr 2007 18:44:31 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities In-Reply-To: <JH6ALt.5Jr@clerew.man.ac.uk> (Charles Lindsey's message of "Fri, 27 Apr 2007 20:08:17 GMT") Organization: The Eyrie References: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> <87k5w5m93o.fsf@windlord.stanford.edu> <JGyF0L.DBH@clerew.man.ac.uk> <87slarxa1i.fsf@windlord.stanford.edu> <JH6ALt.5Jr@clerew.man.ac.uk> Date: Sat, 28 Apr 2007 18:44:31 -0700 Message-ID: <87odl86jk0.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > Russ Allbery <rra@stanford.edu> writes: >> I agree that that's the explanation, but it's a big wad of parenthetical >> in the middle of the point. Hm. >> How about: >> "... Using "!!", and thereby adding <diag-match> since the > ^ > a >> <path-identity> is verified, is RECOMMENDED." > ^ > clearly/obviously > Yes, something like that would be fine. Here is the modified text proposal (as an XML diff): --- usepro.xml 2007-02-19 22:20:06.000000000 -0800 +++ usepro-1414.xml 2007-04-28 18:43:12.000000000 -0700 @@ -373,16 +373,22 @@ specification will add only single "!" characters between <path-identity> strings.</t> - <t>The agent MUST then prepend its own <path-identity> to - the Path header field content.</t> - - <t>The agent MAY then prepend additional <path-identity>s - for itself to the Path header field content, following each - <path-identity> so added with either "!!" or "!". This - is permitted for agents that have multiple - <path-identity>s (such as during a transition from one to - another). Each of these <path-identity>s MUST meet the - requirements set out in <xref target="path" />.</t> + <t>The agent MAY then prepend to the Path header field + content "!" or "!!" followed by an additional + <path-identity> for itself other than its primary one. + Using "!!", and thereby adding a <diag-match> since the + <path-identity clearly is verified, is RECOMMENDED. This + step may be repeated any number of times. This is permitted + for agents that have multiple <path-identity>s (such as + during a transition from one to another). Each of these + <path-identity>s MUST meet the requirements set out in + <xref target="path" />.</t> + + <t>Finally, the agent MUST prepend its primary + <path-identity> to the Path header field content. The + primary <path-identity> is the <path-identity> it + normally advertises to its peers for their use in generating + <path-diagnostic>s as described above.</t> </list> </t> -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S52fcw057060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 22:02:41 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S52fQM057059; Fri, 27 Apr 2007 22:02:41 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S52K0d056982 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 22:02:40 -0700 (MST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2) for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 00:02:17 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: <p0630000fc2580090b3f7@[216.43.25.67]> X-Mailer: Eudora [Macintosh version 6.3a0] Date: Sat, 28 Apr 2007 00:02:21 -0500 To: USEFOR:; From: Pete Resnick <presnick@qualcomm.com> Subject: Fwd: draft-resnick-2822upd-01 posted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Please follow the discussion on ietf-822@imc.org. --- begin forwarded text Date: Thu, 26 Apr 2007 16:55:06 -0500 To: ietf-822@imc.org From: Pete Resnick <presnick@qualcomm.com> Subject: draft-resnick-2822upd-01 posted You may have noticed that 2822upd-01 was posted. <http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt> Also: <http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.html> <http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.xml> <http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.txt> To make rfcdiff work, I've put a copy of RFC 2822 on my web site with some of the later sections rearranged so that they're in the same order as the current draft. You can see the diffs between the two here: <http://tools.ietf.org/rfcdiff?url1=http://www.qualcomm.com/~presnick/rfc2822-fixed.txt&url2=http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt> Though overall very few, there are real changes from 2822 in this document that need review. See the changes section at the bottom. I did *not* go whole hog and switch to Bruce's syntax, simply because I wanted to limit the number of changes and see if we can't get this thing to Draft along with 2821bis. But I did incorporate (hopefully all of) the corrections that you all have pointed out over the last couple of years. Please review with a fine toothed comb. If there are more than just a few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who have at assorted time offered assistance) to start an issues list. Thanks in advance for your assistance. pr --- end forwarded text -- Pete Resnick <http://www.qualcomm.com/~presnick/> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4K4wS049664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 21:20:04 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S4K43L049663; Fri, 27 Apr 2007 21:20:04 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.stanford.edu (smtp3.Stanford.EDU [171.67.20.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4JhPA049594 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:20:03 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1D57E4CA02 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:19:43 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 032754C9DA for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:19:41 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id ED8CEE7BC6; Fri, 27 Apr 2007 21:19:40 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity In-Reply-To: <JH68nC.3G9@clerew.man.ac.uk> (Charles Lindsey's message of "Fri, 27 Apr 2007 19:26:00 GMT") Organization: The Eyrie References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> <87fy6rx9lc.fsf@windlord.stanford.edu> <JH68nC.3G9@clerew.man.ac.uk> Date: Fri, 27 Apr 2007 21:19:40 -0700 Message-ID: <87647hqgf7.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > Russ Allbery <rra@stanford.edu> writes: >> Point 1 says "use the actual name of your system in the Path." I think >> that's pretty clearly the best option and the one that provides the >> maximum amount of useful trace information. Does anyone really >> disagree with that? > I think the WG previously took the view that the actual name of the > system and an MX to reach its admins were equally suitable. But if the > WG now wants to say that the actual address is Point 1 and an MX is > Point 2, then I would not argue too hard against it. Actually, the > really REALLY best practice is to provide both an A/AAAA _and_ an MX, > and that might be worth pointing out It's a minor point, and somewhat off-topic, but I feel obligated to point out whenever it seems appropriate that hosts running SMTP daemons with A records do not need MX records. A remarkable number of people (which I expect does *not* include you -- this was just a rant trigger) seem to be confused about this these days and write stupid spam filtering software under the assumption that A records are not sufficient for delivering e-mail. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CoBB048462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S4CnEo048457; Fri, 27 Apr 2007 21:12:49 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CSIf048396 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:12:48 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew^man#ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4632c9ac.11d3e.a8 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:28 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3S4CSB4012257 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 05:12:28 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3S4CSF5012254 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:28 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24627 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1416 Injection-Date - Summary of options Message-ID: <JH6Azo.5zn@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <JF7Fto.G8J@clerew.man.ac.uk> <JGnGvq.274@clerew.man.ac.uk> <87lkgqlvb0.fsf@windlord.stanford.edu> <871widm39z.fsf@windlord.stanford.edu> <JGyHBE.Fpr@clerew.man.ac.uk> <87odlfx9z0.fsf@windlord.stanford.edu> Date: Fri, 27 Apr 2007 20:16:36 GMT Lines: 32 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87odlfx9z0.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Charles Lindsey <chl@clerew.man.ac.uk> writes: >> However, I am a bit dubious about mentioning exact figures like "72 >> hours", especially as you now speak elsewhere of "1 week" as a normal >> cutoff time (I had always understood that a 3-day cutoff was common >> amongst the large relay-only sites). That "72" may be justified here, >> but there was another "72" elsewhere in your draft that is much more >> doubtful. >I'm trying to find a balance between being conservative in what one sends >and liberal in what one accepts, and three days and seven days are the >most common lower cutoff numbers that I've seen. It's not clear to me the >best way to handle this. I would be inclined to mention in in the Moderators bit (as indeed was done in Usepro-06), but not in the duties of an injecting agent. Essentially, if a guy is slow at injecting an article he wrote some days earlier, then it is his problem if it gets lost. But you can hardly blame that guy in the case where it was the Moderator who mucked it up. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4Cpxx048475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S4CpsK048469; Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CSYO048395 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:12:48 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3*clerew&man#ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4632c9ab.20a.3e5 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:27 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3S4CRBI012249 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 05:12:28 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3S4CRC0012246 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:27 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24626 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities Message-ID: <JH6ALt.5Jr@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> <87k5w5m93o.fsf@windlord.stanford.edu> <JGyF0L.DBH@clerew.man.ac.uk> <87slarxa1i.fsf@windlord.stanford.edu> Date: Fri, 27 Apr 2007 20:08:17 GMT Lines: 57 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87slarxa1i.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Charles Lindsey <chl@clerew.man.ac.uk> writes: >> Russ Allbery <rra@stanford.edu> writes: >> OK, so what about #1415? I seem to remember suggesting a revised wording >> for the introductory paragraph of 3.2.1 of the form: >> Except possibly when relaying to other hosts on the same site, every >> injecting, relaying, or serving agent that accepts an article MUST >> update the Path header field .... >This part of #1415 I still don't agree with, and I didn't get the feeling >there was a consensus in favor of (see also Richard's comments). I'm not >horribly *upset* by your proposal either, but so far it seemed like >discussion was running 2 to 1 against. OK, it is down as an Issue, so in due course the WG will have to decide it one way or the other. The Sky will not Fall In either way. I raised it because I had understood that is what the WG had originally agreed. >>> Here's the new text rendered: >> Yes that is much better. I would suggest, however >> "... Using "!!" is RECOMMENDED (where the second "!" is intended to >> be interpreted as a <diag-match>, such as might have been added in >> Step 3 if that additional <path-identity> has been placed there by a >> separate agent). >I agree that that's the explanation, but it's a big wad of parenthetical >in the middle of the point. Hm. >How about: > "... Using "!!", and thereby adding <diag-match> since the ^ a > <path-identity> is verified, is RECOMMENDED." ^ clearly/obviously Yes, something like that would be fine. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4Cple048479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S4CpFg048470; Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CTPh048397 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:12:48 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew#man$ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4632c9ac.1231c.aa for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:28 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3S4CSHc012265 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 05:12:28 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3S4CSUm012262 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:28 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24628 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1416 Injection-Date - Summary of options Message-ID: <JH6BB4.6Cr@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <JF7Fto.G8J@clerew.man.ac.uk> <87fy6tm8kh.fsf@windlord.stanford.edu> <JGyGzD.FC2@clerew.man.ac.uk> <87k5w3x9r8.fsf@windlord.stanford.edu> Date: Fri, 27 Apr 2007 20:23:28 GMT Lines: 63 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87k5w3x9r8.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Charles Lindsey <chl@clerew.man.ac.uk> writes: >> Russ Allbery <rra@stanford.edu> writes: >>> I believe that an injecting agent MUST reject an article that already >>> has an Injection-Info header and MAY reject an article that contains >>> other trace headers that it happens to recognize. Removing headers or >>> renaming headers provided by a posting agent I believe is a SHOULD NOT. >>> So some disagreement here. >> I could almost be persuaded of this. My only doubt arises from the case >> where an article prepared on a small private (one-node) network is then >> (for redundancy or other reasons) is to be forwarded to two places, one >> of which accepts relaying and the other insists it is injecting... >> In that case, different versions of the article have to be sent to the >> two sites. >Correct. The existing software for doing these sorts of things does >handle this. In INN, for instance, you would use a conventional nntpsend >feed for the relaying site and an rpost feed for the injecting site. >> That is not impossible, but it is a nuisance, especially if the site >> actually believes (though misunderstanding) that it is relaying in both >> cases (in which case you would then argue, I suppose, that it needs to >> be "educated"). >Well, yes, because the site that requires injection is *not* relaying, by >definition. But the point of rpost is to convert a relaying attempt into >an injecting attempt. OK, I think you have persuaded me on that one. >> However, even if Injection-Info is removed by a reinjector, I would >> still prefer any original Path to be retained (even if that results in >> two "POSTED"s within it). A Path is meant to record an article's >> history, and destroying a part of that history may hinder subsequent >> troubleshooting. >I can be convinced that injecting agents shouldn't reject a Path >containing two POSTEDs. Anyone else have an opinion on that? Is there >any drawback to not allowing that? AFAIR, the WG always accepted that could happen. In cases where things have gone wrong, or malpractice is suspected, not throwing away what might be useful evidence is never a good idea. Some sites copy original Paths into an X-header, but I see no gain in doing that as opposed to just leaving the Path as received and prepending new stuff in the usual way. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4Cpjb048472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S4Co9M048465; Fri, 27 Apr 2007 21:12:50 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CRMt048386 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:12:48 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew$man&ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4632c9ab.eceb.80c for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:27 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3S4CRjP012241 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 05:12:27 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3S4CRus012238 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:27 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24625 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JH69JF.4Fn@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> <462DE96C.30809@alvestrand.no> Date: Fri, 27 Apr 2007 19:45:15 GMT Lines: 37 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <462DE96C.30809@alvestrand.no> Harald Alvestrand <harald@alvestrand.no> writes: >Charles, >which part of RESOLVED didn't you understand? We may have resolved what we are going to say, but not necessarily how we are going to say it. For example, I find the text that you yourself wrote when you first proposed the idea that names which did not immediately resolve in the DNS should be allowed (and which can still be found as '2nd alternative' in Usepro-06) is superior to the present text. >Charles Lindsey wrote: >> bogus.bogus.com - score 0 marks >> >This is where you get confused. >bogus.bogus.com WILL yield a SOA - the SOA of .com. Indeed, which is why simply looking for SOA is not enough. For sure we do not want to allow bogus.bogus.com. Interestingly, the DKIM WG has been looking at this, and to do it properly you really need some widely publicised and maintained list of TLDs/zones. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CpUX048471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S4CoXu048464; Fri, 27 Apr 2007 21:12:50 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CRjB048382 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:12:48 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew&man#ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4632c9aa.23e0.104 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:26 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3S4CQYZ012225 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 05:12:26 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3S4CQdd012222 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:26 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24623 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JH68nC.3G9@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> <87fy6rx9lc.fsf@windlord.stanford.edu> Date: Fri, 27 Apr 2007 19:26:00 GMT Lines: 30 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87fy6rx9lc.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Charles Lindsey <chl@clerew.man.ac.uk> writes: >> And if you say that Point 2 allows "any DNS record or none at all", then >> what is the purpose of Point 1? Remember that we are trying to give some >> rough "decreasing order of preference". >Point 1 says "use the actual name of your system in the Path." I think >that's pretty clearly the best option and the one that provides the >maximum amount of useful trace information. Does anyone really disagree >with that? I think the WG previously took the view that the actual name of the system and an MX to reach its admins were equally suitable. But if the WG now wants to say that the actual address is Point 1 and an MX is Point 2, then I would not argue too hard against it. Actually, the really REALLY best practice is to provide both an A/AAAA _and_ an MX, and that might be worth pointing out -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CpdO048473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S4Cobc048466; Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CTvk048398 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:12:48 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew^man&ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4632c9ad.13fe3.16b for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:29 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3S4CTLB012273 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 05:12:29 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3S4CTrn012270 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:29 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24629 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1416 Injection-Date - Summary of options Message-ID: <JH6BGo.6K1@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <JF7Fto.G8J@clerew.man.ac.uk> <87fy6tm8kh.fsf@windlord.stanford.edu> <JGyGzD.FC2@clerew.man.ac.uk> <462DFCE4.1050500@alvestrand.no> <87slapitjw.fsf@windlord.stanford.edu> Date: Fri, 27 Apr 2007 20:26:48 GMT Lines: 31 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87slapitjw.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Harald Alvestrand <harald@alvestrand.no> writes: >> I still think that having the posting agent specify injection-date is a >> Bad Idea, but I could be willing to be part of the "rough" in "rough >> consensus". >After writing the text, I think it's weird, but it's not quite as bad as I >thought it was going to be. It does have the merit of closely mirroring >how Date works today, and if we're going to change something in this area, >sticking as close to what we know works as possible seems like a good idea >to me. +1 It may well be that most 'normal' posting agents leave it to the injecting agent, but for the guy who is doing something slightly out of the ordinary (multiple injection, delayed injection, etc) it does have some advantages, and I can't see any disadvantage. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4Cp3K048480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3S4CpFk048474; Fri, 27 Apr 2007 21:12:51 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3S4CRfg048385 for <ietf-usefor@imc.org>; Fri, 27 Apr 2007 21:12:48 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3$clerew#man^ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4632c9ab.266b.40b for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:27 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3S4CRum012233 for <ietf-usefor@imc.org>; Sat, 28 Apr 2007 05:12:27 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3S4CQSI012230 for ietf-usefor@imc.org; Sat, 28 Apr 2007 05:12:27 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24624 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JH692q.3xB@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> <462DD864.5ABB@xyzzy.claranet.de> Date: Fri, 27 Apr 2007 19:35:14 GMT Lines: 39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <462DD864.5ABB@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes: >Charles Lindsey wrote: >> bogus.example.com where example.com yields just an SOA - score 10 marks >> bogus.bogus.com - score 0 marks >> bogus.bogus - score 0 marks >> a <path-nodot> - score 15 marks >s/15/5/ :-) >We can't have a DNS tutorial in the NetNews protocol spec. Sure. We can use wording which indicates how the <path-identity> is to be interpreted without going into DNS technicalities. "The domain in the <path-identity> MUST/SHOULD/MAY be chosen so that it is possible to identify the host-concerned/the admine-concerned/whatever-else ...". > And I hope they don't find 2142 as it is today, >for cases when they're interested in something that's not abuse@. I think we have made a deliberate choice not to _endorse_ 2142, but that is not to say that it is wrong to follow it (though not at the level of detail that it tries to insist on). USEAGE could try to pick up the pieces. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3Q5Dthf090708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2007 22:13:55 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3Q5Dte5090704; Wed, 25 Apr 2007 22:13:55 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3Q5DXq3090674 for <ietf-usefor@imc.org>; Wed, 25 Apr 2007 22:13:54 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D075259766; Thu, 26 Apr 2007 07:13:31 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28978-02; Thu, 26 Apr 2007 07:13:26 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5AA9B259762; Thu, 26 Apr 2007 07:13:26 +0200 (CEST) Message-ID: <463034F4.5040804@alvestrand.no> Date: Thu, 26 Apr 2007 07:13:24 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Frank Ellermann <nobody@xyzzy.claranet.de> Cc: ietf-usefor@imc.org Subject: Re: OT: nslookup -q=soa bogus.bogus.com References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> <462DE96C.30809@alvestrand.no> <462DED0D.722D@xyzzy.claranet.de> In-Reply-To: <462DED0D.722D@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Frank Ellermann wrote: > Harald Alvestrand wrote: > > >> bogus.bogus.com WILL yield a SOA - the SOA of .com. >> > > `nslookup -q=soa bogus.bogus.com` results in an error > with my version of nslookup, it gives up for NXDOMAIN. > I was talking about Charles' tree-climbing exercise; if you cut off labels until you find something, you will eventually look up ".com". Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHEWat057136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 10:14:32 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OHEWnR057135; Tue, 24 Apr 2007 10:14:32 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OHEBTQ057119 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 10:14:32 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 46AC04CEC2 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 10:14:11 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 17B934CADA for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 10:14:11 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 136FCE7E8E; Tue, 24 Apr 2007 10:14:11 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1416 Injection-Date - Summary of options In-Reply-To: <462DFCE4.1050500@alvestrand.no> (Harald Alvestrand's message of "Tue, 24 Apr 2007 14:49:40 +0200") Organization: The Eyrie References: <JF7Fto.G8J@clerew.man.ac.uk> <87fy6tm8kh.fsf@windlord.stanford.edu> <JGyGzD.FC2@clerew.man.ac.uk> <462DFCE4.1050500@alvestrand.no> Date: Tue, 24 Apr 2007 10:14:11 -0700 Message-ID: <87slapitjw.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Harald Alvestrand <harald@alvestrand.no> writes: > I still think that having the posting agent specify injection-date is a > Bad Idea, but I could be willing to be part of the "rough" in "rough > consensus". After writing the text, I think it's weird, but it's not quite as bad as I thought it was going to be. It does have the merit of closely mirroring how Date works today, and if we're going to change something in this area, sticking as close to what we know works as possible seems like a good idea to me. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OCnll5030726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 05:49:47 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OCnlnt030725; Tue, 24 Apr 2007 05:49:47 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OCnkZL030719 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 05:49:46 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD75F25972E; Tue, 24 Apr 2007 14:49:45 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18151-07; Tue, 24 Apr 2007 14:49:40 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D895E25972D; Tue, 24 Apr 2007 14:49:40 +0200 (CEST) Message-ID: <462DFCE4.1050500@alvestrand.no> Date: Tue, 24 Apr 2007 14:49:40 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Charles Lindsey <chl@clerew.man.ac.uk> Cc: ietf-usefor@imc.org Subject: Re: #1416 Injection-Date - Summary of options References: <JF7Fto.G8J@clerew.man.ac.uk> <87fy6tm8kh.fsf@windlord.stanford.edu> <JGyGzD.FC2@clerew.man.ac.uk> In-Reply-To: <JGyGzD.FC2@clerew.man.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey wrote: > In <87fy6tm8kh.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: > > >> Charles Lindsey <chl@clerew.man.ac.uk> writes: >> > > >>> I think we have now said everything that is to be said on this, so I >>> have produced a summary of where I think we have got to. >>> > > >> Thank you very much for writing this up. >> > > OK, so it seems my summary is largely accepted, modulo any additions > arising from my more recent message regarding moderators. So it should now > be just a straight question of choosing IC or IR. > > Don't bet on it. I haven't bothered commenting on your text in detail, since I find it more constructive to comment on Russ' proposed texts. I still think that having the posting agent specify injection-date is a Bad Idea, but I could be willing to be part of the "rough" in "rough consensus". Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OCldi4030666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 05:47:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OCldgD030665; Tue, 24 Apr 2007 05:47:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OClb1Y030656 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 05:47:38 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7077F25972E; Tue, 24 Apr 2007 14:47:37 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18151-05; Tue, 24 Apr 2007 14:47:32 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7825C25972D; Tue, 24 Apr 2007 14:47:32 +0200 (CEST) Message-ID: <462DFC64.30204@alvestrand.no> Date: Tue, 24 Apr 2007 14:47:32 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Frank Ellermann <nobody@xyzzy.claranet.de> Cc: ietf-usefor@imc.org Subject: Re: Reject vs. fix References: <JF7Fto.G8J@clerew.man.ac.uk> <87fy6tm8kh.fsf@windlord.stanford.edu> <462B9DFF.44B7@xyzzy.claranet.de> In-Reply-To: <462B9DFF.44B7@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> My technical opinion: I think it's reasonable for a posting agent (under the control of the poster) to "fix" articles. I think it's unreasonable for an injecting agent (under the control of the news admin) to do so. Frank Ellermann wrote: > Russ Allbery wrote: > > >> I believe that an injecting agent MUST reject an article that >> already has an Injection-Info header and MAY reject an article >> that contains other trace headers that it happens to recognize. >> Removing headers or renaming headers provided by a posting >> agent I believe is a SHOULD NOT. >> > > >> So some disagreement here. >> > > The idea is important, rejecting is clearer than most attempts > to automatically "fix" articles. It needs human intervention. > > Frank > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OBoBic025038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 04:50:11 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OBoBLH025037; Tue, 24 Apr 2007 04:50:11 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OBo9X6025031 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 04:50:10 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HgJX0-0004X9-4B for ietf-usefor@imc.org; Tue, 24 Apr 2007 13:50:02 +0200 Received: from 1cust218.tnt5.hbg2.deu.da.uu.net ([149.225.16.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 13:50:02 +0200 Received: from nobody by 1cust218.tnt5.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 13:50:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities Date: Tue, 24 Apr 2007 13:47:45 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 9 Message-ID: <462DEE61.3796@xyzzy.claranet.de> References: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> <87k5w5m93o.fsf@windlord.stanford.edu> <JGyF0L.DBH@clerew.man.ac.uk> <87slarxa1i.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust218.tnt5.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Russ Allbery wrote: > How about: > "... Using "!!", and thereby adding <diag-match> since the > <path-identity> is verified, is RECOMMENDED." Sure. I thought the rationale is obvious, but explicitly stating it in one short sentence is better. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OBiOT4024602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 04:44:24 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OBiO5x024601; Tue, 24 Apr 2007 04:44:24 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OBiMlU024594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 04:44:24 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HgJRK-0003Yu-Et for ietf-usefor@imc.org; Tue, 24 Apr 2007 13:44:10 +0200 Received: from 1cust218.tnt5.hbg2.deu.da.uu.net ([149.225.16.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 13:44:10 +0200 Received: from nobody by 1cust218.tnt5.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 13:44:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: OT: nslookup -q=soa bogus.bogus.com (was: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity) Date: Tue, 24 Apr 2007 13:42:05 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 15 Message-ID: <462DED0D.722D@xyzzy.claranet.de> References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> <462DE96C.30809@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust218.tnt5.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Harald Alvestrand wrote: > bogus.bogus.com WILL yield a SOA - the SOA of .com. `nslookup -q=soa bogus.bogus.com` results in an error with my version of nslookup, it gives up for NXDOMAIN. > NEW TECHNICAL ARGUMENTS Just an off topic technical observation, the question of "zone cuts" is quite interesting, but admittedlly not here. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OBQhgj022774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 04:26:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OBQh8j022773; Tue, 24 Apr 2007 04:26:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OBQgn6022766 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 04:26:42 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E329D25972D; Tue, 24 Apr 2007 13:26:41 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15959-09; Tue, 24 Apr 2007 13:26:36 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADDD7259725; Tue, 24 Apr 2007 13:26:36 +0200 (CEST) Message-ID: <462DE96C.30809@alvestrand.no> Date: Tue, 24 Apr 2007 13:26:36 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Charles Lindsey <chl@clerew.man.ac.uk> Cc: ietf-usefor@imc.org Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> In-Reply-To: <JGyABr.8J5@clerew.man.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles, which part of RESOLVED didn't you understand? Charles Lindsey wrote: > In <87ejmfkm6i.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: > > In the following, "bogus" means a component that fails to resolve, > "example" means a component that resolves to an IP or MX, or even an SOA, > possibly via CNAMEs, and ".com" could as well be ".org", ".co.uk" etc. > > example.example.com yields the IP of the relaying host - score 60 marks. > example.example.com yields a useful MX - score 40 marks > (i.e. it works with some suitable RFC 2142 identity > such as news@/postmaster@/whatever) > bogus.example.com where example.com yields a useful MX - score 20 marks > bogus.example.com where example.com yields just an SOA - score 10 marks > bogus.bogus.com - score 0 marks > This is where you get confused. bogus.bogus.com WILL yield a SOA - the SOA of .com. So you cannot programmatically tell the difference between "bogus.bogus.com" and "bogus.example.com" without giving special treatment to ".com". One example of such a situation is where "bogus.com" is registered with Verisign, but no DNS service has been established yet. (Verisign allows that; others, such as .no, don't). The current text covers that situation. There has been no support for changing it. Unless you have NEW TECHNICAL ARGUMENTS - which means something DIFFERENT from "I like" or "I think the group should like", your harping on the issue is OUT OF ORDER. Harald Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OAJ8GU017537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Apr 2007 03:19:08 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3OAJ8Du017536; Tue, 24 Apr 2007 03:19:08 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3OAIkXK017521 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 03:19:07 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HgI6W-000664-JM for ietf-usefor@imc.org; Tue, 24 Apr 2007 12:18:36 +0200 Received: from 1cust218.tnt5.hbg2.deu.da.uu.net ([149.225.16.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 12:18:36 +0200 Received: from nobody by 1cust218.tnt5.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Tue, 24 Apr 2007 12:18:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Date: Tue, 24 Apr 2007 12:13:56 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 19 Message-ID: <462DD864.5ABB@xyzzy.claranet.de> References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> 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: 1cust218.tnt5.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey wrote: > bogus.example.com where example.com yields just an SOA - score 10 marks > bogus.bogus.com - score 0 marks > bogus.bogus - score 0 marks > a <path-nodot> - score 15 marks s/15/5/ >> I think the current wording is fine and already excludes bogus TLDs. > Only in a very half-hearted sort of way. We can't have a DNS tutorial in the NetNews protocol spec. Folks interested in the merits of MX or DDDS or RP and so on need to look elsewhere. And I hope they don't find 2142 as it is today, for cases when they're interested in something that's not abuse@. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NHpiZD077149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 10:51:44 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NHpiBw077148; Mon, 23 Apr 2007 10:51:44 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NHphk3077142 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:51:44 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D14044CDF3 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:51:43 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id AF6084CDA9 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:51:43 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id A9A28E7D27; Mon, 23 Apr 2007 10:51:43 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity In-Reply-To: <JGyABr.8J5@clerew.man.ac.uk> (Charles Lindsey's message of "Mon, 23 Apr 2007 12:21:27 GMT") Organization: The Eyrie References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> <JGyABr.8J5@clerew.man.ac.uk> Date: Mon, 23 Apr 2007 10:51:43 -0700 Message-ID: <87fy6rx9lc.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > Russ Allbery <rra@stanford.edu> writes: >> Sure it does. Point 2 allows any DNS record or none at all. > We seem to have reached the point now where it is agreed by the WG that > we want to allow various things (including MX records and also things > that do not resolve at all in the DNS, even though a 'stub' does > resolve, but excluding things that are totally unrelated to the DNS, > such as bogus TLDs). The question now is whether the present wording is > the best way to describe what we want to allow. > And if you say that Point 2 allows "any DNS record or none at all", then > what is the purpose of Point 1? Remember that we are trying to give some > rough "decreasing order of preference". Point 1 says "use the actual name of your system in the Path." I think that's pretty clearly the best option and the one that provides the maximum amount of useful trace information. Does anyone really disagree with that? > In the following, "bogus" means a component that fails to resolve, > "example" means a component that resolves to an IP or MX, or even an > SOA, possibly via CNAMEs, and ".com" could as well be ".org", ".co.uk" > etc. > example.example.com yields the IP of the relaying host - score 60 marks. > example.example.com yields a useful MX - score 40 marks > (i.e. it works with some suitable RFC 2142 identity > such as news@/postmaster@/whatever) I think the main place we disagree is over the usefulness of an MX record. If I have the FQDN of the host, I can figure out somewhere reasonable to mail. An MX may save me a small amount of time, but usually it's pretty obvious. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NHmCUM076604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 10:48:12 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NHmC2T076603; Mon, 23 Apr 2007 10:48:12 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NHmBDF076596 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:48:11 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9C0264CB0D for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:48:11 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 760B64BEE8 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:48:11 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6F58FE7D27; Mon, 23 Apr 2007 10:48:11 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1416 Injection-Date - Summary of options In-Reply-To: <JGyGzD.FC2@clerew.man.ac.uk> (Charles Lindsey's message of "Mon, 23 Apr 2007 14:45:13 GMT") Organization: The Eyrie References: <JF7Fto.G8J@clerew.man.ac.uk> <87fy6tm8kh.fsf@windlord.stanford.edu> <JGyGzD.FC2@clerew.man.ac.uk> Date: Mon, 23 Apr 2007 10:48:11 -0700 Message-ID: <87k5w3x9r8.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > Russ Allbery <rra@stanford.edu> writes: >> Charles Lindsey <chl@clerew.man.ac.uk> writes: >>> I2. MUST/SHOULD remove/rename Injection-Info (plus NNTP-Posting-*, >>> X-Trace, etc.) and SHOULD provide fresh Injection-Info. MAY reject >>> (reinjected) articles already containing those headers. >> I believe that an injecting agent MUST reject an article that already >> has an Injection-Info header and MAY reject an article that contains >> other trace headers that it happens to recognize. Removing headers or >> renaming headers provided by a posting agent I believe is a SHOULD NOT. >> So some disagreement here. > This arises when an article has been "reinjected" for some strange > reason. Essentially, you are saying that it is the responsibility of > the reinjector to remove any existing Injection-Info, otherwise the > injecting agent will throw it back at him. Correct. > I could almost be persuaded of this. My only doubt arises from the case > where an article prepared on a small private (one-node) network is then > (for redundancy or other reasons) is to be forwarded to two places, one > of which accepts relaying and the other insists it is injecting (even > though IHAVE has been used, as now permitted by INN). INN doesn't permit IHAVE in a default configuration, to note. > In that case, different versions of the article have to be sent to the > two sites. Correct. The existing software for doing these sorts of things does handle this. In INN, for instance, you would use a conventional nntpsend feed for the relaying site and an rpost feed for the injecting site. > That is not impossible, but it is a nuisance, especially if the site > actually believes (though misunderstanding) that it is relaying in both > cases (in which case you would then argue, I suppose, that it needs to > be "educated"). Well, yes, because the site that requires injection is *not* relaying, by definition. But the point of rpost is to convert a relaying attempt into an injecting attempt. > However, even if Injection-Info is removed by a reinjector, I would > still prefer any original Path to be retained (even if that results in > two "POSTED"s within it). A Path is meant to record an article's > history, and destroying a part of that history may hinder subsequent > troubleshooting. I can be convinced that injecting agents shouldn't reject a Path containing two POSTEDs. Anyone else have an opinion on that? Is there any drawback to not allowing that? >> However, I think the best solution to this is, rather than tackling the >> gateways section, to write a separate section about multiple injection >> to replace the section about reinjection. > However, reinjection is not always associated with multiple injection, > so it still needs some mention. It is if you define multiple injection that way. :) See my proposed new section and see what you think. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NHhWiI075763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 10:43:32 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NHhWO6075762; Mon, 23 Apr 2007 10:43:32 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NHhVBI075755 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:43:31 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 568F94C172 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:43:31 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 1629E4C67F for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:43:31 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 0D193E7D27; Mon, 23 Apr 2007 10:43:31 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1416 Injection-Date - Summary of options In-Reply-To: <JGyHBE.Fpr@clerew.man.ac.uk> (Charles Lindsey's message of "Mon, 23 Apr 2007 14:52:26 GMT") Organization: The Eyrie References: <JF7Fto.G8J@clerew.man.ac.uk> <JGnGvq.274@clerew.man.ac.uk> <87lkgqlvb0.fsf@windlord.stanford.edu> <871widm39z.fsf@windlord.stanford.edu> <JGyHBE.Fpr@clerew.man.ac.uk> Date: Mon, 23 Apr 2007 10:43:31 -0700 Message-ID: <87odlfx9z0.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > However, I am a bit dubious about mentioning exact figures like "72 > hours", especially as you now speak elsewhere of "1 week" as a normal > cutoff time (I had always understood that a 3-day cutoff was common > amongst the large relay-only sites). That "72" may be justified here, > but there was another "72" elsewhere in your draft that is much more > doubtful. I'm trying to find a balance between being conservative in what one sends and liberal in what one accepts, and three days and seven days are the most common lower cutoff numbers that I've seen. It's not clear to me the best way to handle this. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NHgMG5075551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 10:42:22 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NHgMdo075550; Mon, 23 Apr 2007 10:42:22 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NHg2gl075492 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:42:22 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8C2094C331 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:42:01 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 6A16F4C172 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 10:42:01 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6538DE7D27; Mon, 23 Apr 2007 10:42:01 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities In-Reply-To: <JGyF0L.DBH@clerew.man.ac.uk> (Charles Lindsey's message of "Mon, 23 Apr 2007 14:02:45 GMT") Organization: The Eyrie References: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> <87k5w5m93o.fsf@windlord.stanford.edu> <JGyF0L.DBH@clerew.man.ac.uk> Date: Mon, 23 Apr 2007 10:42:01 -0700 Message-ID: <87slarxa1i.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > Russ Allbery <rra@stanford.edu> writes: >> Easy one first. Here is my proposed text for #1414, which also >> addresses part of Charles's concerns in #1415. There hasn't been any >> subsequent discussion of my original response to #1414, so I'm going to >> go with my preferred option of MUST/SHOULD for "!" vs. "!!". > OK, so what about #1415? I seem to remember suggesting a revised wording > for the introductory paragraph of 3.2.1 of the form: > Except possibly when relaying to other hosts on the same site, every > injecting, relaying, or serving agent that accepts an article MUST > update the Path header field .... > So if the point is accepted, that wording should still work. See issue > tracker #1415 for full discussion. This part of #1415 I still don't agree with, and I didn't get the feeling there was a consensus in favor of (see also Richard's comments). I'm not horribly *upset* by your proposal either, but so far it seemed like discussion was running 2 to 1 against. >> Here's the new text rendered: >> 4. The agent MAY then prepend to the Path header field content "!" >> or "!!" followed by an additional <path-identity> for itself >> other than its primary one. Using "!!" is RECOMMENDED. This >> step may be repeated any number of times. This is permitted for >> agents that have multiple <path-identity>s (such as during a >> transition from one to another). Each of these <path-identity>s >> MUST meet the requirements set out in Section 3.2. >> 5. Finally, the agent MUST prepend its primary <path-identity> to >> the Path header field content. The primary <path-identity> is >> the <path-identity> it normally advertises to its peers for their >> use in generating <path-diagnostic>s as described above. > Yes that is much better. I would suggest, however > "... Using "!!" is RECOMMENDED (where the second "!" is intended to > be interpreted as a <diag-match>, such as might have been added in > Step 3 if that additional <path-identity> has been placed there by a > separate agent). I agree that that's the explanation, but it's a big wad of parenthetical in the middle of the point. Hm. How about: "... Using "!!", and thereby adding <diag-match> since the <path-identity> is verified, is RECOMMENDED." -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NGCYiG062427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 09:12:34 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NGCYIh062425; Mon, 23 Apr 2007 09:12:34 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NGCBJs062364 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 09:12:32 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3$clerew&man&ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 462cdad2.5f67.1b for ietf-usefor@imc.org; Mon, 23 Apr 2007 17:12:02 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3NGC1Hi025308 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 17:12:01 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3NGC1wC025305 for ietf-usefor@imc.org; Mon, 23 Apr 2007 17:12:01 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24608 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities Message-ID: <JGyF0L.DBH@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> <87k5w5m93o.fsf@windlord.stanford.edu> Date: Mon, 23 Apr 2007 14:02:45 GMT Lines: 60 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87k5w5m93o.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Harald Tveit Alvestrand <harald@alvestrand.no> writes: >> #1414: USEPRO 3.2.1: delimiter for multiple Path identities >> No discussion >> #1415: USEPRO 3.2.1: Number of path entries per site >> Discussion, but no proposed text. >Easy one first. Here is my proposed text for #1414, which also addresses >part of Charles's concerns in #1415. There hasn't been any subsequent >discussion of my original response to #1414, so I'm going to go with my >preferred option of MUST/SHOULD for "!" vs. "!!". OK, so what about #1415? I seem to remember suggesting a revised wording for the introductory paragraph of 3.2.1 of the form: Except possibly when relaying to other hosts on the same site, every injecting, relaying, or serving agent that accepts an article MUST update the Path header field .... So if the point is accepted, that wording should still work. See issue tracker #1415 for full discussion. >Here's the new text rendered: > 4. The agent MAY then prepend to the Path header field content "!" > or "!!" followed by an additional <path-identity> for itself > other than its primary one. Using "!!" is RECOMMENDED. This > step may be repeated any number of times. This is permitted for > agents that have multiple <path-identity>s (such as during a > transition from one to another). Each of these <path-identity>s > MUST meet the requirements set out in Section 3.2. > 5. Finally, the agent MUST prepend its primary <path-identity> to > the Path header field content. The primary <path-identity> is > the <path-identity> it normally advertises to its peers for their > use in generating <path-diagnostic>s as described above. Yes that is much better. I would suggest, however "... Using "!!" is RECOMMENDED (where the second "!" is intended to be interpreted as a <diag-match>, such as might have been added in Step 3 if that additional <path-identity> has been placed there by a separate agent). IOW, software/humans reading the Path do not need to be aware whether successive <path-identity>s were added by the same of by different agents. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NGCYvQ062430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 09:12:34 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NGCY4c062426; Mon, 23 Apr 2007 09:12:34 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NGCBU8062366 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 09:12:32 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3$clerew$man#ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 462cdad5.bb5f.32b for ietf-usefor@imc.org; Mon, 23 Apr 2007 17:12:05 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3NGC2co025325 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 17:12:02 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3NGC1gL025322 for ietf-usefor@imc.org; Mon, 23 Apr 2007 17:12:01 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24610 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1416 Injection-Date - Summary of options Message-ID: <JGyHBE.Fpr@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <JF7Fto.G8J@clerew.man.ac.uk> <JGnGvq.274@clerew.man.ac.uk> <87lkgqlvb0.fsf@windlord.stanford.edu> <871widm39z.fsf@windlord.stanford.edu> Date: Mon, 23 Apr 2007 14:52:26 GMT Lines: 44 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <871widm39z.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: > 4. Moderators are encouraged to retain the Message-ID header field > if it is valid, and also retain the Date header field unless it > appears to be stale (72 hours or more in the past) for reasons > understood by the moderator (such as delays in the moderation > process) in which case they MAY substitute the current date. Any > Injection-Date, Injection-Info, or Xref header fields already > present (though there should be none) MUST be removed. >I'm dropping the "(though there should be none)" when proposing wording >for this change, since it's now more likely. OK. >>> There is a separate but related question of whether, for the benefit of >>> legacy injecting and relaying agents, he might need to do something >>> about a Date header that had been rendered unusually stale because of >>> hiw own delay. Usepro-06 made some special provision for this, and I >>> think Usepro-07 does also. Normally, of course, Date should be left >>> strictly alone as being a matter to be determined by the Poster, but >>> one can hardly blame the Poster for subsequent delays caused by the >>> moderator. >> Yup. >And the current provision is also quoted above. However, I am a bit dubious about mentioning exact figures like "72 hours", especially as you now speak elsewhere of "1 week" as a normal cutoff time (I had always understood that a 3-day cutoff was common amongst the large relay-only sites). That "72" may be justified here, but there was another "72" elsewhere in your draft that is much more doubtful. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NGCY2o062424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 09:12:34 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NGCX6b062423; Mon, 23 Apr 2007 09:12:33 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NGCB3O062363 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 09:12:32 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew^man#ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 462cdad2.ec9a.d0 for ietf-usefor@imc.org; Mon, 23 Apr 2007 17:12:02 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3NGC0cP025300 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 17:12:00 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3NGC1oD025295 for ietf-usefor@imc.org; Mon, 23 Apr 2007 17:12:01 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24607 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JGyABr.8J5@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> <87ejmfkm6i.fsf@windlord.stanford.edu> Date: Mon, 23 Apr 2007 12:21:27 GMT Lines: 68 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87ejmfkm6i.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Charles Lindsey <chl@clerew.man.ac.uk> writes: >> On the contrary, Russ has agreed, more or less, with the list of >> existing practices thst we need to accomodate, but clearly the present >> wording does not allow all of them (in particular, it seems not to allow >> MX records in any shape or form). >Sure it does. Point 2 allows any DNS record or none at all. We seem to have reached the point now where it is agreed by the WG that we want to allow various things (including MX records and also things that do not resolve at all in the DNS, even though a 'stub' does resolve, but excluding things that are totally unrelated to the DNS, such as bogus TLDs). The question now is whether the present wording is the best way to describe what we want to allow. And if you say that Point 2 allows "any DNS record or none at all", then what is the purpose of Point 1? Remember that we are trying to give some rough "decreasing order of preference". Essentially, we want the <path-identity>s that are used to be "helpful" to both software and humans that have occasion to use them. Suppose we award marks for "helpfulness" (note, I am not suggesting we write the document in these terms). In the following, "bogus" means a component that fails to resolve, "example" means a component that resolves to an IP or MX, or even an SOA, possibly via CNAMEs, and ".com" could as well be ".org", ".co.uk" etc. example.example.com yields the IP of the relaying host - score 60 marks. example.example.com yields a useful MX - score 40 marks (i.e. it works with some suitable RFC 2142 identity such as news@/postmaster@/whatever) bogus.example.com where example.com yields a useful MX - score 20 marks bogus.example.com where example.com yields just an SOA - score 10 marks bogus.bogus.com - score 0 marks bogus.bogus - score 0 marks a <path-nodot> - score 15 marks So an ideal site could score 100 marks; 60 marks and even 40 marks could be normal and acceptable; But below 40 is getting a bit dodgy, though allowable; And zero is quite unacceptable. So it those marks reflect our gut feeling of what we want to see, then the question is what wording would best convey that gut feeling (though not with such a fine-grained level of detail)? My concern is that the present wording gets no way near it. We should be able to do much better. >I think the current wording is fine and already excludes bogus TLDs. Only in a very half-hearted sort of way. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NGCX7S062422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 09:12:34 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3NGCXAu062419; Mon, 23 Apr 2007 09:12:33 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3NGCBWP062362 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 09:12:32 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3$clerew&man*ac$uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 462cdad2.64ac.c for ietf-usefor@imc.org; Mon, 23 Apr 2007 17:12:02 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3NGC16P025317 for <ietf-usefor@imc.org>; Mon, 23 Apr 2007 17:12:01 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3NGC1rZ025314 for ietf-usefor@imc.org; Mon, 23 Apr 2007 17:12:01 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24609 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1416 Injection-Date - Summary of options Message-ID: <JGyGzD.FC2@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <JF7Fto.G8J@clerew.man.ac.uk> <87fy6tm8kh.fsf@windlord.stanford.edu> Date: Mon, 23 Apr 2007 14:45:13 GMT Lines: 122 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87fy6tm8kh.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Charles Lindsey <chl@clerew.man.ac.uk> writes: >> I think we have now said everything that is to be said on this, so I >> have produced a summary of where I think we have got to. >Thank you very much for writing this up. OK, so it seems my summary is largely accepted, modulo any additions arising from my more recent message regarding moderators. So it should now be just a straight question of choosing IC or IR. >> I2. MUST/SHOULD remove/rename Injection-Info (plus NNTP-Posting-*, >> X-Trace, etc.) and SHOULD provide fresh Injection-Info. MAY reject >> (reinjected) articles already containing those headers. >I believe that an injecting agent MUST reject an article that already has >an Injection-Info header and MAY reject an article that contains other >trace headers that it happens to recognize. Removing headers or renaming >headers provided by a posting agent I believe is a SHOULD NOT. >So some disagreement here. This arises when an article has been "reinjected" for some strange reason. Essentially, you are saying that it is the responsibility of the reinjector to remove any existing Injection-Info, otherwise the injecting agent will throw it back at him. I could almost be persuaded of this. My only doubt arises from the case where an article prepared on a small private (one-node) network is then (for redundancy or other reasons) is to be forwarded to two places, one of which accepts relaying and the other insists it is injecting (even though IHAVE has been used, as now permitted by INN). In that case, different versions of the article have to be sent to the two sites. That is not impossible, but it is a nuisance, especially if the site actually believes (though misunderstanding) that it is relaying in both cases (in which case you would then argue, I suppose, that it needs to be "educated"). However, even if Injection-Info is removed by a reinjector, I would still prefer any original Path to be retained (even if that results in two "POSTED"s within it). A Path is meant to record an article's history, and destroying a part of that history may hinder subsequent troubleshooting. Better the evidence of reinjection should be there for all to see. Moreover, if by some complicated means the article ever propagates back towards one of the "pre-historic" sites, it would still be in order not to send it there on the grounds that is had already been there once. >> We disagree on the following two possibilities: > >> IC. Injecting agents MUST insert Injection-Date when it is absent >> (unless it is apparent that this is a reinjection). >> Good News IC: This provides immediate beneffit to the posting agent >> which has delayed injection, even if P5 is not implemented. >> Bad News IC: Until multi-injecting sites can be assumed to have >> implemented P6 this can cause re-acceptance of articles at later >> relaying agents if one of the multi-injected versions suffers >> substantial delay en route. So the existing behaviour is changed to >> that extent. > >> IR. Injecting agents MUST NOT insert Injection-Date if both (Date AND >> Message-ID are already present). >> Good News IR: Inverse of the Bad News IC. >> Bad News IR: Posting agents with delayed injection see no benefit >> unless/until they implement P5. >I think that's a fair summary of the options. OK, so are we ready to count heads on that? Essentially, it is a choice between accepting an occasional duplicate article at un-upgraded sites, versus not getting the full benefit of Injection-Date with current posting agents as soon as injecting/relaying agents start to recognize it. >> Gateways: >> --------- >> And especially Gateways from one Netnews system A to another one B, in >> particular from small private one-node networks into Usenet: >> G1. MUST retain all headers as received (including in particular Date >> and Injection-Date), unless some EXCEPTION applies, as listed below. >> G2. MUST hand article to an injecting agent, or else perform all the >> duties on an injecting agent (except perhaps insertion of >> Injection-Date) themselves and then relay. >However, I think the best solution to this is, rather than tackling the >gateways section, to write a separate section about multiple injection to >replace the section about reinjection. However, reinjection is not always associated with multiple injection, so it still needs some mention. For sure, Gateways have to do the right thing in the ways I have outlined, whether we use the word "reinjection" or not. The problem is that such reinjectors may not think to regard themselves as gatweways unless we point it out to them. I have read your revised wordings to implement all these things, but I need to examine them more carefully before responding. I notice that Frank has made some comments, not all of which I agree with. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MJphQp011133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 12:51:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MJpheK011132; Sun, 22 Apr 2007 12:51:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MJpMNK011060 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 12:51:42 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 432224C438 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 12:51:22 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 0C6CF4C312 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 12:51:22 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id EC4AFE7BAB; Sun, 22 Apr 2007 12:51:21 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities In-Reply-To: <462BA063.7AEE@xyzzy.claranet.de> (Frank Ellermann's message of "Sun, 22 Apr 2007 19:50:27 +0200") Organization: The Eyrie References: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> <87k5w5m93o.fsf@windlord.stanford.edu> <462BA063.7AEE@xyzzy.claranet.de> Date: Sun, 22 Apr 2007 12:51:21 -0700 Message-ID: <87slastcg6.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Frank Ellermann <nobody@xyzzy.claranet.de> writes: > Russ Allbery wrote: >> + The primary <path-identity> is the <path-identity> >> + it normally advertises to its peers for their use in >> + generating <path-diagnostic>s as described above.</t> > Good. An XML-editor keeping ">" as is only because it's > allowed would make me nervous, but that's off topic... :-) XML editor? What's that? :) (I'm too anal about indentation and whitespace and all the XML editors I've used do things subtlely wrong for me.) -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MHpGQa089888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 10:51:16 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MHpGew089887; Sun, 22 Apr 2007 10:51:16 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MHpEEv089871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 10:51:15 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HfgDH-0004jy-0z for ietf-usefor@imc.org; Sun, 22 Apr 2007 19:51:03 +0200 Received: from 1cust144.tnt1.hbg2.deu.da.uu.net ([149.225.10.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 19:51:03 +0200 Received: from nobody by 1cust144.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 19:51:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: #1414: USEPRO 3.2.1: delimiter for multiple Path identities Date: Sun, 22 Apr 2007 19:50:27 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 17 Message-ID: <462BA063.7AEE@xyzzy.claranet.de> References: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> <87k5w5m93o.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust144.tnt1.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Russ Allbery wrote: >+ <t>The agent MAY then prepend to the Path header field >+ content "!" or "!!" followed by an additional >+ <path-identity> for itself other than its primary one. >+ Using "!!" is RECOMMENDED. [...] Is that new ? I thought that's already accepted text. >+ The primary <path-identity> is the <path-identity> >+ it normally advertises to its peers for their use in >+ generating <path-diagnostic>s as described above.</t> Good. An XML-editor keeping ">" as is only because it's allowed would make me nervous, but that's off topic... :-) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MHfPpI088242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 10:41:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MHfPfU088241; Sun, 22 Apr 2007 10:41:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MHfMqA088228 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 10:41:24 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hfg3d-0003Vr-BT for ietf-usefor@imc.org; Sun, 22 Apr 2007 19:41:05 +0200 Received: from 1cust144.tnt1.hbg2.deu.da.uu.net ([149.225.10.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 19:41:05 +0200 Received: from nobody by 1cust144.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 19:41:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Reject vs. fix (was: #1416 Injection-Date - Summary of options) Date: Sun, 22 Apr 2007 19:40:15 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 15 Message-ID: <462B9DFF.44B7@xyzzy.claranet.de> References: <JF7Fto.G8J@clerew.man.ac.uk> <87fy6tm8kh.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust144.tnt1.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Russ Allbery wrote: > I believe that an injecting agent MUST reject an article that > already has an Injection-Info header and MAY reject an article > that contains other trace headers that it happens to recognize. > Removing headers or renaming headers provided by a posting > agent I believe is a SHOULD NOT. > So some disagreement here. The idea is important, rejecting is clearer than most attempts to automatically "fix" articles. It needs human intervention. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MHR1is085901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 10:27:01 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MHR1tl085900; Sun, 22 Apr 2007 10:27:01 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MHQwrJ085880 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 10:27:00 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hffpx-0001fh-RH for ietf-usefor@imc.org; Sun, 22 Apr 2007 19:26:57 +0200 Received: from 1cust144.tnt1.hbg2.deu.da.uu.net ([149.225.10.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 19:26:57 +0200 Received: from nobody by 1cust144.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 19:26:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: #1416 Injection-Date - Summary of options Date: Sun, 22 Apr 2007 19:26:36 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 11 Message-ID: <462B9ACC.7F15@xyzzy.claranet.de> References: <JF7Fto.G8J@clerew.man.ac.uk> <JGnGvq.274@clerew.man.ac.uk> <87lkgqlvb0.fsf@windlord.stanford.edu> <46253AB0.1923@xyzzy.claranet.de> <87wt05kom8.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust144.tnt1.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Russ Allbery wrote: > Look good? Yes, I read and answered in reverse chronological order, see my longer reply to your long diff with a question about the second moderator multi-SHOULD. I tried to figure out why it's no MUSTard. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MHJ9T1084613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Apr 2007 10:19:09 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3MHJ922084612; Sun, 22 Apr 2007 10:19:09 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3MHIkFI084547 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 10:19:08 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hffht-0000RF-53 for ietf-usefor@imc.org; Sun, 22 Apr 2007 19:18:37 +0200 Received: from 1cust144.tnt1.hbg2.deu.da.uu.net ([149.225.10.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 19:18:37 +0200 Received: from nobody by 1cust144.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sun, 22 Apr 2007 19:18:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: #1416: Reinjection and Injection-Date proposed text Date: Sun, 22 Apr 2007 19:12:45 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 157 Message-ID: <462B978D.4816@xyzzy.claranet.de> References: <87slatkn3x.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust144.tnt1.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Russ Allbery wrote: > +3.3. Article History and Duplicate Suppression [...] Very clear, thanks. >+ it ought not be aggressively short. For For Usenet, for example, >+ a cutoff interval of no less than seven days is conventional. Yes, no MUSTard needed here, the consequences are clear. Commercial servers with shorter cutoff intervals for "binary" newsgroups may need the support staff to answer complaints by their angry customers. >- MUST NOT create any Injection-Date or Injection-Info header >- fields; these headers will be added by the injecting agent. >+ MUST NOT create an Injection-Info header field; this headers will >+ be added by the injecting agent. Nit: s/headers/header field/ >+ The Injection-Date header field is new in this revision of the >+ Netnews protocol and is designed to permit the Date header field to >+ hold the composition date, even if the proto-article is not injected >+ for some time after its composition. Please add a reference to RFC 2822 here, it's likely not only you who hates this, it needs a compelling justification. >+ Posting agents MAY add an Injection-Date header field and SHOULD do >+ so if the Date header field (representing the composition time of >+ the proto-article) is more than a day in the past in case the >+ injecting agent predates this specification. I think you're mixing unrelated concepts here. The SHOULD is clear, it doesn't need the qualifier starting with "in case...". The SHOULD addresses the "stale 2822 date" issue among other problems. The MAY is something more subtle, and from the text it's not clear if this is limited to "more than a day ago". I _guess_ that the MAY is about multiple injections, and you want to allow that posting agents create their own unique Message-ID + Injection-Date combination. And with some reading between the lines such smart posting agents might even decide to ignore RFC 2822 and force a corresponding unique Date. >+ Note, though, that articles with a Date header field substantially >+ in the past will still be rejected by implementations predating >+ this specification, regardless of the Injection-Date header field, >+ and may suffer poor propagation. Okay, it's not only "between the lines", and I like that, too. >+ the header field Injection-Date SHOULD be present and identical in >+ all copies of the proto-article. See Section 3.4.2. Yes, and the MAY mentioned above might be also related to 3.4.2, If that's the case you've just overwritten it here by a SHOULD, or is the MAY about a 3rd case ? Like a posting agent always creating its own Injection-Date even if it's not one of the two SHOULDs, that could be a 3rd case. In that case I hope that it gets "identical" right under all foreseeable circumstances wrt the "multi-SHOULD". >+ the goal is to not create multiple independent articles but >+ rather to inject the same article at multiple points and use the >+ normal duplicate suppression facility of Netnews (see Section 3.3) >+ ensure that any given agent only accepts the article once. Nit: s/use/let/ The move from "reinjection" to "multiple injection" resulted in a far better readable story. >- A posting agent SHOULD normally reject such articles. Odd, was that really a "posting agent" rejecting articles ? >+ The posting agent MUST supply the Message-ID, Date, and >+ Injection-Date header fields, and the proto-article offered to >+ each injecting agent MUST be identical. Some lines above it was a "multi-SHOULD", now you have a "multi-MUST" for the Injection-Date. How about this: | The posting agent MUST supply the Message-ID and the Date, it | SHOULD also supply an Injection-Date, and the proto-article | offered to each injecting agent MUST be identical. Arguably you can also use MUST here as you have it, and replace the "multi-SHOULD" at the end of 3.4.1 by MUST. But that would render all existing posting agents with no idea about the new Injection-Date as "non-conforming" when they try multi-Injection. >+ It MUST remove any Xref header field and either rename or remove >+ any Injection-Info header field and other trace fields. I see why they MUST remove Injection-Info, an old injecting agent would let it pass causing havoc. But why MUST a posting agent remove Xref, this job could be handled by the injecting agent ? Is it "a simple MUST is better than more convoluted statements", or do I miss a serious Xref-problem here ? >+ SHOULD only be done after the proto-article is approved for >+ all moderated groups to which it is posted and has an Approved >+ header field. What's a good excuse to violate this SHOULD ? Is it a moderator removing moderated and unapproved newsgroups, and injecting the article at least for the approved or unmoderated newsgroups ? If there's no good excuse I prefer a MUST. >+ This interval SHOULD NOT be any shorter than 72 hours into the >+ past. That's a rather short minimum, barely enough for a normal weekend. For this radical approach, how about a MUST NOT ? Disclaimer, I've no idea about what's usual for "binary" newsgroups. But I doubt that they have any use for the 2822-Date concept like "text" groups or, more important, mail2news gateways. >+ If the proto-article had both a Message-ID header field and a >+ Date header field, an Injection-Date header field MUST NOT be >+ added, since the proto-article may have been multiply injected >+ by a posting agent that predates this standard. Otherwise, the >+ injecting agent MUST add an Injection-Date header field >+ containing the current date and time. We really need to check that you use MUST and SHOULD consistently. How about a 2 * 2 table, two for legacy vs. new posting agent, and two for legacy vs. new injecting agent, stating that all new agents MUST get it right, resulting in an overall SHOULD for "any" agent. Your MUST NOT + MUST above talks about new injecting agents. For the MUST NOT it's obvious, a legacy agent doesn't know what the Injection-Date is and has no problem with not adding it. But the MUST is only for new agents. Overall it's a SHOULD, and legacy agents have a good excuse to violate the overall SHOULD. >+ It MAY reject articles with dates in the future with a smaller >+ margin than 24 hours. Does that really help ? Otherwise strike it, we have a precision of "days" elsewhere, not "hours", and "days" allow us to ignore all plausible timezone issues. >+ the Date header field, and reject the article if that date is >+ more than 24 hours into the future. It MAY reject articles with >+ dates in the future with a smaller margin than 24 hours. Same here, let's stick to one day, and get rid of less than one day. Impression without checking the details: the quoted parts are now clearer than in I-D.ietf-usefor-usepro-06. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M5DfkF054601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 22:13:41 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3M5DfIi054600; Sat, 21 Apr 2007 22:13:41 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.stanford.edu (smtp3.Stanford.EDU [171.67.20.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M5DdFa054588 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 22:13:39 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7EA1A4C7EB for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 22:13:39 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 265184C7B4 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 22:13:39 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 21617E79F2; Sat, 21 Apr 2007 22:13:39 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: #1416: Reinjection and Injection-Date proposed text Organization: The Eyrie Date: Sat, 21 Apr 2007 22:13:38 -0700 Message-ID: <87slatkn3x.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Okay, here we go. Some time away from this, while unfortunate for progress in the working group, definitely cleared my head and gave me a new perspective. Here's a concrete wording proposal. This implements the IR proposal rather than the IC proposal in Charles's writeup. If we decide to go with IC, the modifications should be slight. This will hopefully give us something more concrete to discuss, and I think we'll be able to quickly reach consensus on some parts of it. After some time away and reconsidering this, I favor Harold's (and, I think, Charles's) proposal of simply not worrying about the case that was giving me so much heartburn and simply ruling out serial multiple injection in cases where you have to drop the Injection-Date header field in the main language of the standard. If someone wants to handle that separately as a gateway, I think the out is there, and we don't need to draw a bright arrow to it. Please pay special attention to the new Article History and Duplicate Suppression section and the Multiple Injection of Articles section that replaces the whole Reinjection section in the current draft. The former should hopefully be uncontroversial and address many of Frank's concerns. Hopefully a unified diff is reasonably readable. If folks would like me to send out the complete revised text, let me know. I've omitted the obvious diffs to section numbers and the like, so this diff probably won't apply entirely cleanly. --- draft-ietf-usefor-usepro-07.txt 2007-02-19 22:20:36.000000000 -0800 +++ usepro-1416.txt 2007-04-21 22:08:45.000000000 -0700 @@ -309,8 +309,8 @@ "Injecting" an article is the processing of a proto-article by an injecting agent. Normally this action is done once and only once for - a given article. "Reinjecting" an article is passing an already- - injected article to an injection agent. + a given article. "Multiple injection" is passing the same article to + multiple injecting agents, either serially or in parallel. A "gateway" is software which receives news articles and converts them to messages of some other kind (such as [RFC2822] mail @@ -631,7 +631,72 @@ baz.isp.example, bar.isp.example, and foo-news folded the Path header field. -3.3. Duties of a Posting Agent +3.3. Article History and Duplicate Suppression + + Netnews normally uses a flood-fill algorithm for propagation of + articles in which each news server offers articles it accepts to + multiple peers and each news server may be offered the same article + from multiple other news servers. Accordingly, duplicate suppression + is key; if a news server accepted every article it was offered, it + may needlessly accept (and then potentially retransmit) dozens of + copies of every article. + + Relaying and serving agents therefore MUST keep a record of articles + they have already seen and use that record to reject additional + offers of the same article. This record is called the history file + or database. + + Each article is uniquely identified by its message identifier, so a + relaying or serving agent could satisfy this requirement by storing a + record of every message identifier that agent has ever seen. Such a + history database would grow without bound, however, so it is common + and permitted to optimize based on the Injection-Date or Date header + field of an article as follows. (In the following discussion, the + "date" of an article is defined to be the date represented by its + Injection-Date header field if present, otherwise its Date header + field.) + + o Agents MAY select a cutoff interval and reject any article with a + date farther in the past than that cutoff interval. If this + interval is shorter than the time it takes for an article to + propagate through the network, the agent may reject an article it + had not yet seen, so it ought not be aggressively short. For + Usenet, for example, a cutoff interval of no less than seven days + is conventional. + + + + + +Allbery & Lindsey Expires July 5, 2007 [Page 12] + +Internet-Draft Netnews Architecture and Protocols January 2007 + + + o Agents that enforce such a cutoff MAY then drop records of + articles that had dates older than the cutoff from their history + databases. If such an article were offered to the agent again, it + would be rejected due to the cutoff date, so the history record is + no longer required to suppress the duplicate. + + o As an optimization for easier history database manipulation, + agents MAY instead drop history records written longer ago than + the cutoff interval plus one day. If this retention mechanism is + used, the history retention period MUST be longer than the cutoff + interval to allow for articles dated in the future unless the + agent rejects all articles dated in the future. One day is the + maximum allowed error into the future for article dates, so it is + a convenient and safe extension for the retention interval. + + This is just one implementation strategy for article history, albeit + the most common one. Relaying and serving agents are not required to + use this strategy, only to meet the requirement of not accepting an + article more than once. However, implementors of general-purpose + Netnews relaying and serving agents who do not have extensive + experience with Netnews and the subtle effects of its flood-fill + algorithm are encouraged to use the above algorithm by default. + +3.4. Duties of a Posting Agent A posting agent is the component of a user agent that assists a poster in creating a valid proto-article and forwarding it to an @@ -639,8 +704,33 @@ Posting agents SHOULD ensure that proto-articles they create are valid according to [USEFOR] and any other applicable policies. They - MUST NOT create any Injection-Date or Injection-Info header fields; - these headers will be added by the injecting agent. + MUST NOT create an Injection-Info header field; this headers will be + added by the injecting agent. + + The Injection-Date header field is new in this revision of the + Netnews protocol and is designed to permit the Date header field to + hold the composition date, even if the proto-article is not injected + for some time after its composition. However, note that all + implementations predating this specification ignore the Injection- + Date header field and use the Date header field in its stead for + rejecting articles older than their cutoff (see Section 3.3), and + injecting agents predating this specification do not add an + Injection-Date header. Posting agents MAY add an Injection-Date + header field and SHOULD do so if the Date header field (representing + the composition time of the proto-article) is more than a day in the + past in case the injecting agent predates this specification. Note, + though, that articles with a Date header field substantially in the + past will still be rejected by implementations predating this + + + +Allbery & Lindsey Expires July 5, 2007 [Page 13] + +Internet-Draft Netnews Architecture and Protocols January 2007 + + + specification, regardless of the Injection-Date header field, and may + suffer poor propagation. Contrary to [RFC2822], which implies that the mailbox or mailboxes in the From header field should be that of the poster or posters, a @@ -652,7 +742,7 @@ attempt to post an article which cancels or Supersedes another article of which the poster is not the author or sender. -3.3.1. Proto-articles +3.4.1. Proto-articles A proto-article is an article in the format used by a posting agent for offering to an injecting agent. It may omit certain header @@ -662,54 +752,75 @@ SHOULD NOT be transmitted to any other agent. A proto-article has the same format as a normal article except that - the Injection-Date, Injection-Info, and Xref header fields MUST NOT - be present; the Path header field MUST NOT contain a "POSTED" <diag- - keyword>; and any of the following mandatory header fields MAY be - + the Injection-Info and Xref header fields MUST NOT be present; the + Path header field MUST NOT contain a "POSTED" <diag-keyword>; and any + of the following mandatory header fields MAY be omitted: Message-ID, + Date, and Path. In all other respects, a proto-article MUST be a + valid Netnews article. In particular, the header fields which may be + omitted MUST NOT be present with invalid content. + If a posting agent intends to offer the same proto-article to + multiple injecting agents, the header fields Message-ID and Date MUST + be present and identical in all copies of the proto-article, and the + header field Injection-Date SHOULD be present and identical in all + copies of the proto-article. See Section 3.4.2. + +3.4.2. Multiple Injection of Articles + + Under some circumstances (posting to multiple disjoint networks, + injecting agents with spotty connectivity, or redundancy, for + example), a posting agent may wish to offer the same article to + multiple injecting agents. In this unusual case, the goal is to not + create multiple independent articles but rather to inject the same + article at multiple points and use the normal duplicate suppression + facility of Netnews (see Section 3.3) ensure that any given agent + only accepts the article once. -Allbery & Lindsey Expires July 5, 2007 [Page 12] - -Internet-Draft Netnews Architecture and Protocols January 2007 + Whenever possible, multiple injection SHOULD be done by offering the - omitted: Message-ID, Date, and Path. In all other respects, a proto- - article MUST be a valid Netnews article. In particular, the header - fields which may be omitted MUST NOT be present with invalid content. - If a posting agent intends to offer the same proto-article to - multiple injecting agents, the header fields Message-ID and Date MUST - be present and identical in all copies of the proto-article. +Allbery & Lindsey Expires July 5, 2007 [Page 14] + +Internet-Draft Netnews Architecture and Protocols January 2007 -3.3.2. Reinjection of Articles - A given article SHOULD be processed by an injecting agent once and - only once. The Injection-Date or Injection-Info header fields are - added by an injecting agent and are not permitted in a proto-article. - Their presence (or the presence of other unstandardized or obsolete - trace headers such as NNTP-Posting-Host, NNTP-Posting-Date, or - X-Trace) indicates that the proto-article is instead an article and - has already been processed by an injecting agent. A posting agent - SHOULD normally reject such articles. - - In the exceptional case that an article needs to be reinjected for - some reason (such as transferring an article from one Netnews to - another where those networks have no relaying agreement), the posting - agent doing the reinjection MUST convert the article back into a - proto-article before passing it to an injecting agent (such as by - renaming the Injection-Info and Injection-Date header fields and - removing any Xref header field) and MUST perform the date checks on - the existing Injection-Date or Date header fields that would - otherwise be done by the injecting agent. - - Reinjecting articles may cause loops, loss of trace information, and - other problems and should only be done with care and when there is no - available alternative. A posting agent that does reinjection is a - limited type of gateway and as such is subject to all of the - requirements of an incoming gateway in addition to the requirements - of a posting agent. + same proto-article to multiple injecting agents. The posting agent + MUST supply the Message-ID, Date, and Injection-Date header fields, + and the proto-article offered to each injecting agent MUST be + identical. + + In some cases, offering the same proto-article to all injecting + agents may not be possible (such as when transferring, after the + fact, articles found on one Netnews network to another, unconnected + one). In this case, the posting agent MUST convert the article back + into a proto-article before passing it to another injecting agent, + but it MUST retain unmodified the Message-ID, Date, and Injection- + Date header fields. It MUST NOT add an Injection-Date header field + if it is missing from the existing article. It MUST remove any Xref + header field and either rename or remove any Injection-Info header + field and other trace fields. + + Multiple injection inherently risks duplicating articles. Multiple + injection after the fact, by converting an article back to a proto- + article and injecting it again, additionally risks loops, loss of + trace information, and other problems and should be done with care + and only when there is no alternative. The requirement to retain + Message-ID, Date, and Injection-Date header fields minimizes the + possibility of a loop and ensures that the newly injected article is + not treated as a new, separate article. + + Multiple injection of an article listing one or more moderated + newsgroups in its Newsgroups header field SHOULD only be done by a + moderator and SHOULD only be done after the proto-article is approved + for all moderated groups to which it is posted and has an Approved + header field. Multiple injection of an unapproved article intended + for moderated newsgroups will normally only result in the moderator + receiving multiple copies, and if the newsgroup status is not + consistent across all injecting agents, may result in duplication of + the article or other problems. -3.3.3. Followups +3.4.3. Followups A followup is an article that contains a response to the contents of an earlier article, its precursor. In addition to its normal duties, @@ -831,30 +942,31 @@ 2. It MUST reject any proto-article that does not have the proper mandatory header fields for a proto-article; that has Injection- - Date, Injection-Info, or Xref header fields; that has a Path - header field containing the "POSTED" <diag-keyword>; or that is + Info or Xref header fields; that has a Path header field + containing the "POSTED" <diag-keyword>; or that is not + syntactically valid as defined by [USEFOR]. It SHOULD reject -Allbery & Lindsey Expires July 5, 2007 [Page 15] +Allbery & Lindsey Expires July 5, 2007 [Page 17] Internet-Draft Netnews Architecture and Protocols January 2007 - not syntactically valid as defined by [USEFOR]. It SHOULD - reject any proto-article which contains a header field - deprecated for Netnews. It MAY reject any proto-article that - contains trace header fields indicating that it was already - injected by an injecting agent that did not add Injection-Info - or Injection-Date. + any proto-article which contains a header field deprecated for + Netnews. It MAY reject any proto-article that contains trace + header fields indicating that it was already injected by an + injecting agent that did not add Injection-Info or Injection- + Date. 3. It SHOULD reject any article whose Date header field is more than 24 hours into the future (and MAY use a margin less than 24 - hours). It SHOULD reject any article whose Date header appears - to be stale (more than 72 hours into the past, for example, or - too old to still be recorded in the database of a relaying agent - the injecting agent will be using) since not all news servers - support Injection-Date. + hours). It SHOULD reject any article whose Date header is too + far into the past (older than the cutoff interval of a relaying + agent the injecting agent is using, for example), since not all + news servers support Injection-Date and only the injecting agent + can provide a useful error message to the posting agent. This + interval SHOULD NOT be any shorter than 72 hours into the past. 4. It SHOULD reject any proto-article whose Newsgroups header field does not contain at least one <newsgroup-name> for a valid @@ -904,13 +1016,19 @@ source of the article and possibly other trace information as described in Section 3.2.8 of [USEFOR]. - 11. The injecting agent MUST then add an Injection-Date header field - containing the current date and time. + 11. If the proto-article already had an Injection-Date header field, + it MUST NOT be modified or replaced. If the proto-article had + both a Message-ID header field and a Date header field, an + Injection-Date header field MUST NOT be added, since the proto- + article may have been multiply injected by a posting agent that + predates this standard. Otherwise, the injecting agent MUST add + an Injection-Date header field containing the current date and + time. 12. Finally, the injecting agent forwards the article to one or more relaying agents, and the injection process is complete. -3.4.1. Forwarding Messages to a Moderator +3.5.1. Forwarding Messages to a Moderator An injecting agent MUST forward the proto-article to the moderator of the leftmost moderated group listed in the Newsgroups header field, @@ -964,7 +1084,7 @@ that database. Such methods may be more appropriate for smaller Netnews networks. -3.5. Duties of a Relaying Agent +3.6. 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. To @@ -993,28 +1113,24 @@ 1. It MUST reject any article without a Newsgroups header field or Message-ID header field, or without either an Injection-Date or - Date header field. - - 2. It MUST reject any article that has already been successfully - sent to it, based on the Message-ID header field of the article. - To satisfy this requirement, a relaying agent normally keeps a - database of message identifiers it has already accepted. - - -Allbery & Lindsey Expires July 5, 2007 [Page 18] +Allbery & Lindsey Expires July 5, 2007 [Page 20] Internet-Draft Netnews Architecture and Protocols January 2007 - 3. It MUST examine the Injection-Date header field or, if absent, - the Date header field, and reject the article if that date - predates the earliest articles of which it keeps record or if - that date is more than 24 hours into the future. It MAY reject - articles with dates in the future with a smaller margin than 24 - hours. + Date header field. + + 2. It MUST examine the Injection-Date header field or, if absent, + the Date header field, and reject the article if that date is + more than 24 hours into the future. It MAY reject articles with + dates in the future with a smaller margin than 24 hours. + + 3. It MUST reject any article that has already been successfully + sent to it or that is dated older than its cutoff date, as + described in Section 3.3. 4. It SHOULD reject any article that does not include all the mandatory header fields. It MAY reject any article that contains @@ -1052,19 +1168,20 @@ modify the body of articles in any way. If an article is not acceptable as-is, the article MUST be rejected rather than modified. -3.6. Duties of a Serving Agent - A serving agent accepts articles from a relaying agent or injecting - agent, stores it, and makes it available to reading agents. Articles - are normally indexed by newsgroup and <article-locator> (Section -Allbery & Lindsey Expires July 5, 2007 [Page 19] +Allbery & Lindsey Expires July 5, 2007 [Page 21] Internet-Draft Netnews Architecture and Protocols January 2007 +3.7. Duties of a Serving Agent + + A serving agent accepts articles from a relaying agent or injecting + agent, stores it, and makes it available to reading agents. Articles + are normally indexed by newsgroup and <article-locator> (Section 3.2.14 of [USEFOR]), usually in the form of a decimal number. If the serving agent stores articles by newsgroup, control messages @@ -1088,20 +1205,17 @@ fields that do not have valid contents. 2. It MUST examine the Injection-Date header field or, if absent, - the Date header field, and reject the article if that date - predates the earliest articles of which it keeps record or if - that date is more than 24 hours into the future. It MAY reject - articles with dates in the future with a smaller margin than 24 - hours. + the Date header field, and reject the article if that date is + more than 24 hours into the future. It MAY reject articles with + dates in the future with a smaller margin than 24 hours. 3. It MUST reject any article that has already been successfully - sent to it, based on the Message-ID header field of the article. - To satisfy this requirement, a relaying agent normally keeps a - database of message identifiers it has already accepted. + sent to it or that is dated older than its cutoff date, as + described in Section 3.3. 4. It SHOULD reject any article that matches an already-received and honored cancel message or Supersedes header field following the - same rules as a relaying agent (Section 3.5). + same rules as a relaying agent (Section 3.6). 5. It MUST reject any article without an Approved header field posted to any newsgroup listed as moderated. @@ -1212,7 +1327,7 @@ understood by the moderator (such as delays in the moderation process) in which case they MAY substitute the current date. Any Injection-Date, Injection-Info, or Xref header fields already - present (though there should be none) MUST be removed. + present MUST be removed. 5. Any Path header field MUST either be removed or truncated to only those entries following its "POSTED" <diag-keyword>, if any. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M4f4iJ049268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 21:41:04 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3M4f480049267; Sat, 21 Apr 2007 21:41:04 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M4f351049248 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 21:41:03 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 57F014CAE4 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 21:41:03 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 3947A4C78D for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 21:41:03 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 344BEE79F2; Sat, 21 Apr 2007 21:41:03 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1416 Injection-Date - Summary of options In-Reply-To: <46253AB0.1923@xyzzy.claranet.de> (Frank Ellermann's message of "Tue, 17 Apr 2007 23:22:56 +0200") Organization: The Eyrie References: <JF7Fto.G8J@clerew.man.ac.uk> <JGnGvq.274@clerew.man.ac.uk> <87lkgqlvb0.fsf@windlord.stanford.edu> <46253AB0.1923@xyzzy.claranet.de> Date: Sat, 21 Apr 2007 21:41:03 -0700 Message-ID: <87wt05kom8.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Frank Ellermann <nobody@xyzzy.claranet.de> writes: > Russ Allbery wrote: >> I think it's reasonable to let the article possibly end up duplicated >> in the bizarre case where the poster is multiply injecting and some >> sites have the group marked moderated and some marked unmoderated. > If that case is considered as "bizarre" please say so in the draft. > Maybe not literally, but the tendency should be clear for readers. Multiple injection of an article listing one or more moderated newsgroups in its Newsgroups header field SHOULD only be done by a moderator and SHOULD only be done after the proto-article is approved for all moderated groups to which it is posted and has an Approved header field. Multiple injection of an unapproved article intended for moderated newsgroups will normally only result in the moderator receiving multiple copies, and if the newsgroup status is not consistent across all injecting agents, may result in duplication of the article or other problems. Look good? -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M4dRB0049077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 21:39:27 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3M4dRBx049076; Sat, 21 Apr 2007 21:39:27 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M4d5G9049005 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 21:39:26 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2DF294CAE4 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 21:39:05 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id ECD104CAD0 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 21:39:04 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id D2A8BE79F2; Sat, 21 Apr 2007 21:39:04 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1416 Injection-Date - Summary of options In-Reply-To: <87lkgqlvb0.fsf@windlord.stanford.edu> (Russ Allbery's message of "Tue, 17 Apr 2007 11:17:39 -0700") Organization: The Eyrie References: <JF7Fto.G8J@clerew.man.ac.uk> <JGnGvq.274@clerew.man.ac.uk> <87lkgqlvb0.fsf@windlord.stanford.edu> Date: Sat, 21 Apr 2007 21:39:04 -0700 Message-ID: <871widm39z.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Russ Allbery <rra@stanford.edu> writes: > Charles Lindsey <chl@clerew.man.ac.uk> writes: >> So I think, in this case, the moderator MUST now discard any >> Injection-Date already provided, and then proceed to inject the >> Approved article in the normal manner, at which point he MAY then add >> an Injection-Date, and MUST add one if he is injecting at multiple >> sites. > Yup, that sounds right to me. Good catch. Turns out we already had this: 4. Moderators are encouraged to retain the Message-ID header field if it is valid, and also retain the Date header field unless it appears to be stale (72 hours or more in the past) for reasons understood by the moderator (such as delays in the moderation process) in which case they MAY substitute the current date. Any Injection-Date, Injection-Info, or Xref header fields already present (though there should be none) MUST be removed. I'm dropping the "(though there should be none)" when proposing wording for this change, since it's now more likely. >> There is a separate but related question of whether, for the benefit of >> legacy injecting and relaying agents, he might need to do something >> about a Date header that had been rendered unusually stale because of >> hiw own delay. Usepro-06 made some special provision for this, and I >> think Usepro-07 does also. Normally, of course, Date should be left >> strictly alone as being a matter to be determined by the Poster, but >> one can hardly blame the Poster for subsequent delays caused by the >> moderator. > Yup. And the current provision is also quoted above. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M2j8UB028951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 19:45:08 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3M2j8L1028950; Sat, 21 Apr 2007 19:45:08 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.20.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M2il4q028906 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 19:45:07 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 752A24C6FB for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 19:44:47 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 278DB4C611 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 19:44:47 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 20DE8E7A14; Sat, 21 Apr 2007 19:44:47 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1416 Injection-Date - Summary of options In-Reply-To: <JF7Fto.G8J@clerew.man.ac.uk> (Charles Lindsey's message of "Tue, 20 Mar 2007 13:51:24 GMT") Organization: The Eyrie References: <JF7Fto.G8J@clerew.man.ac.uk> Date: Sat, 21 Apr 2007 19:44:46 -0700 Message-ID: <87fy6tm8kh.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > I think we have now said everything that is to be said on this, so I > have produced a summary of where I think we have got to. Thank you very much for writing this up. It's been a long time since the last message, so I'm going to quote extensively to save people from having to refer back to the mailing list archives. > The following rules are mostly agreed (and indeed some are already in > the present USEPRO). They are all included to give a complete > picture. Note that these are indications of what is supposed to happen, > and not wordings ready for use in the document. > The chief issue is to choose between Rules IC and IR, for which the > several "Good/Bad News" paragraphs need to be studied. Neither Rule is > perfect. It is a question of whether a little pain should be endured for > the benefit of an ultimate gain. In either case, the Sky will not Fall > In - the worst is that an occasional article might be seen twice at some > server. > Posting agents: > --------------- > P1. MAY omit various headers from proto-articles (specifically Message-ID, > Date, Path). > P2. But should (with a small 's') not omit Date (because we are following > the RFC 2822 idea that Date reflects time of composition). > NOTE P2: This practice is already widespread, and growing, but it works > against the man whose injections are significantly delayed after > composition time; hence P5 below. > P3. MUST include Message-ID and Date if article is to be injected at > multiple injecting agents (and the same at each injecting agent, of course). > P4. MAY include Injection-Date indicating time of actual injection (as > opposed to composition). > P5. SHOULD/should include Injection-Date if injection time is significantly > later than composition time. > Good News P5: A certain cure for the man with delayed injection problems; > Bad News P5: Posting agents tend not to get upgraded with such > new-fangled ideas until long after servers have adopted them. But at > least this man has a strong incentive to upgrade (once he is aware of the > possibility). > P6. When injecting at multiple injecting agents, MUST include Injection-Date > which MUST then indicate time of earliest injection at any such agent. I agree with all of those statements. > Injecting Agents: > ----------------- > I1. MUST insert Date and Message-ID when absent and insert/extend PATH. Agreed. > I2. MUST/SHOULD remove/rename Injection-Info (plus NNTP-Posting-*, > X-Trace, etc.) and SHOULD provide fresh Injection-Info. MAY reject > (reinjected) articles already containing those headers. I believe that an injecting agent MUST reject an article that already has an Injection-Info header and MAY reject an article that contains other trace headers that it happens to recognize. Removing headers or renaming headers provided by a posting agent I believe is a SHOULD NOT. So some disagreement here. > I3. MUST/SHOULD insert Injection-Date when Injection-Date is absent AND > (either Date OR Message-ID is absent). > NOTE I3: But see IC and IR below for further details. > I4. MUST NOT insert (or alter or delete) Injection-Date if it is already > present. > NOTE I4: That is to prevent re-acceptance problems arising from > unanticipated (and unpreventable) "leaks" between small private > networks and major networks such as Usenet. But see E1 for how a > gateway might do such tricks. Agreed on these. > We disagree on the following two possibilities: > IC. Injecting agents MUST insert Injection-Date when it is absent > (unless it is apparent that this is a reinjection). > Good News IC: This provides immediate beneffit to the posting agent > which has delayed injection, even if P5 is not implemented. > Bad News IC: Until multi-injecting sites can be assumed to have > implemented P6 this can cause re-acceptance of articles at later > relaying agents if one of the multi-injected versions suffers > substantial delay en route. So the existing behaviour is changed to > that extent. > IR. Injecting agents MUST NOT insert Injection-Date if both (Date AND > Message-ID are already present). > Good News IR: Inverse of the Bad News IC. > Bad News IR: Posting agents with delayed injection see no benefit > unless/until they implement P5. I think that's a fair summary of the options. > Relaying and Serving Agents: > ---------------------------- > R1. MUST discard incoming articles whose Injection-Date (or Date if > Injection-Date is absent) predates the earliest articles of which it > keeps record (or if more than 24 hours into the future, etc.). > That "earliest articles of which it keeps record" might be reworded (see > my reply to Frank on March 1st). The essential question is "if this > article had arrived X days ago, would I still be recording that fact?" > (which allows for different retentions for different groups, etc). And > maybe it records the time of arrival, or the original Date header, or > whatever (about which I don't think we care). Right. I'm going to propose a new section that discusses how the history file works and which should make all of this much clearer and more straightforward. There are a couple of standard ways of handling history file entries, and we should probably just spell them out. > Gateways: > --------- > And especially Gateways from one Netnews system A to another one B, in > particular from small private one-node networks into Usenet: > G1. MUST retain all headers as received (including in particular Date > and Injection-Date), unless some EXCEPTION applies, as listed below. > G2. MUST hand article to an injecting agent, or else perform all the > duties on an injecting agent (except perhaps insertion of > Injection-Date) themselves and then relay. I would just say that they hand the article to an injecting agent, since the second option there is just a special case of the first where the injecting agent they use is built in to the gateway. However, I think the best solution to this is, rather than tackling the gateways section, to write a separate section about multiple injection to replace the section about reinjection. I'm going to take a crack at that and see if I can come up with something that's fairly clear. > EXCEPTIONs: > ----------- > These are the tricky bits > E1. An existing Injection-Date MAY be removed, but ONLY IF > a) There is no possibility that another Gateway (direct or indirect) > between those networks exists (which includes all manner of "leaks" by > other nodes in A over which the gatewayer has no control). > b) The article had not been previously gatewayed from B into A (i.e. it > had been originally posted by a user of A). > NOTE: That covers the man who carries his private server around on a > laptop, and other users of suck/rpost, but if covers very little else. > NOTE: It is safer to allow gateways (which hopefully understand the > circumstances of the particular article) to do any tinkering with > Injection-Date than for injecting agents to do it; Hence Rule I4. Yup, this seems right. > E2. Other evidence of injection within network A (e.g. Injection-Info, > NNTP-Posting-*, etc) MAY be removed, but ONLY IF > a) The gatewaying is to use an injecting agent which would not otherwise > allow reinjection. > NOTE: That screams of "cheating", "horrible hacking", etc. So be it. > Perhaps it is better not mentioned. I don't believe injecting agents should ever allow reinjection, so I would remove the conditional. Otherwise, I agree. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M2XdSt027960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2007 19:33:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3M2XdbQ027959; Sat, 21 Apr 2007 19:33:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp3.stanford.edu (smtp3.Stanford.EDU [171.67.20.26]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3M2XIeC027926 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 19:33:38 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CC7864C6A8 for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 19:33:16 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 9379B4C0EF for <ietf-usefor@imc.org>; Sat, 21 Apr 2007 19:33:15 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 8AE6CE7A14; Sat, 21 Apr 2007 19:33:15 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: #1414: USEPRO 3.2.1: delimiter for multiple Path identities In-Reply-To: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> (Harald Tveit Alvestrand's message of "Wed, 21 Mar 2007 11:29:33 +0100") Organization: The Eyrie References: <C339D8FF55D9FD5B86C0CCAF@[10.0.0.174]> Date: Sat, 21 Apr 2007 19:33:15 -0700 Message-ID: <87k5w5m93o.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Harald Tveit Alvestrand <harald@alvestrand.no> writes: > #1414: USEPRO 3.2.1: delimiter for multiple Path identities > No discussion > #1415: USEPRO 3.2.1: Number of path entries per site > Discussion, but no proposed text. Easy one first. Here is my proposed text for #1414, which also addresses part of Charles's concerns in #1415. There hasn't been any subsequent discussion of my original response to #1414, so I'm going to go with my preferred option of MUST/SHOULD for "!" vs. "!!". --- usepro.xml 2007-02-19 22:20:06.000000000 -0800 +++ usepro-1414.xml 2007-04-21 19:31:58.000000000 -0700 @@ -373,16 +373,21 @@ specification will add only single "!" characters between <path-identity> strings.</t> - <t>The agent MUST then prepend its own <path-identity> to - the Path header field content.</t> - - <t>The agent MAY then prepend additional <path-identity>s - for itself to the Path header field content, following each - <path-identity> so added with either "!!" or "!". This - is permitted for agents that have multiple - <path-identity>s (such as during a transition from one to - another). Each of these <path-identity>s MUST meet the - requirements set out in <xref target="path" />.</t> + <t>The agent MAY then prepend to the Path header field + content "!" or "!!" followed by an additional + <path-identity> for itself other than its primary one. + Using "!!" is RECOMMENDED. This step may be repeated any + number of times. This is permitted for agents that have + multiple <path-identity>s (such as during a transition + from one to another). Each of these <path-identity>s + MUST meet the requirements set out in + <xref target="path" />.</t> + + <t>Finally, the agent MUST prepend its primary + <path-identity> to the Path header field content. The + primary <path-identity> is the <path-identity> it + normally advertises to its peers for their use in generating + <path-diagnostic>s as described above.</t> </list> </t> Here's the new text rendered: 4. The agent MAY then prepend to the Path header field content "!" or "!!" followed by an additional <path-identity> for itself other than its primary one. Using "!!" is RECOMMENDED. This step may be repeated any number of times. This is permitted for agents that have multiple <path-identity>s (such as during a transition from one to another). Each of these <path-identity>s MUST meet the requirements set out in Section 3.2. 5. Finally, the agent MUST prepend its primary <path-identity> to the Path header field content. The primary <path-identity> is the <path-identity> it normally advertises to its peers for their use in generating <path-diagnostic>s as described above. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KH9iXr028528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 10:09:44 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KH9ihF028527; Fri, 20 Apr 2007 10:09:44 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KH9NNP028489 for <ietf-usefor@imc.org>; Fri, 20 Apr 2007 10:09:43 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5D9244CAB0 for <ietf-usefor@imc.org>; Fri, 20 Apr 2007 10:09:21 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id CDD1D4CB8C for <ietf-usefor@imc.org>; Fri, 20 Apr 2007 10:09:09 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id C296AE7C48; Fri, 20 Apr 2007 10:09:09 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity In-Reply-To: <JGssKE.Jxy@clerew.man.ac.uk> (Charles Lindsey's message of "Fri, 20 Apr 2007 13:09:50 GMT") Organization: The Eyrie References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> <JGssKE.Jxy@clerew.man.ac.uk> Date: Fri, 20 Apr 2007 10:09:09 -0700 Message-ID: <87ejmfkm6i.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > On the contrary, Russ has agreed, more or less, with the list of > existing practices thst we need to accomodate, but clearly the present > wording does not allow all of them (in particular, it seems not to allow > MX records in any shape or form). Sure it does. Point 2 allows any DNS record or none at all. > Moreover, Russ also agrees that mention needs to be made that will > exclude bogus TLDs. > I suggest we give Russ tiem to come back on some of these points. I think the current wording is fine and already excludes bogus TLDs. No change required is my preferred resolution. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KGCOk1021003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 09:12:24 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3KGCOFo021002; Fri, 20 Apr 2007 09:12:24 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3KGC2b6020953 for <ietf-usefor@imc.org>; Fri, 20 Apr 2007 09:12:23 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew&man^ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4628e651.a251.267 for ietf-usefor@imc.org; Fri, 20 Apr 2007 17:12:01 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3KGC1eE007155 for <ietf-usefor@imc.org>; Fri, 20 Apr 2007 17:12:01 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3KGC0E8007151 for ietf-usefor@imc.org; Fri, 20 Apr 2007 17:12:00 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24595 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JGssKE.Jxy@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <4625EADE.2010906@alvestrand.no> Date: Fri, 20 Apr 2007 13:09:50 GMT Lines: 27 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <4625EADE.2010906@alvestrand.no> Harald Alvestrand <harald@alvestrand.no> writes: >I'm closing this item as "no change needed". >Apart from Charles, there seems to be nobody asking for a change, and >several people have said that they are OK with the current wording. On the contrary, Russ has agreed, more or less, with the list of existing practices thst we need to accomodate, but clearly the present wording does not allow all of them (in particular, it seems not to allow MX records in any shape or form). Moreover, Russ also agrees that mention needs to be made that will exclude bogus TLDs. I suggest we give Russ tiem to come back on some of these points. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3I9snoi061674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 02:54:49 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3I9snsl061673; Wed, 18 Apr 2007 02:54:49 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3I9sl8w061667 for <ietf-usefor@imc.org>; Wed, 18 Apr 2007 02:54:48 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 414422597F0; Wed, 18 Apr 2007 11:54:47 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14456-03; Wed, 18 Apr 2007 11:54:39 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F08872597E2; Wed, 18 Apr 2007 11:54:38 +0200 (CEST) Message-ID: <4625EADE.2010906@alvestrand.no> Date: Wed, 18 Apr 2007 11:54:38 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Harald Tveit Alvestrand <harald@alvestrand.no> Cc: Usefor Mailing List <ietf-usefor@imc.org> Subject: RESOLUTION: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> In-Reply-To: <08DBF8F69193F92ACDF00313@[192.168.1.108]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> I'm closing this item as "no change needed". Apart from Charles, there seems to be nobody asking for a change, and several people have said that they are OK with the current wording. Harald Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HLNxBX031586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 14:23:59 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HLNxpu031585; Tue, 17 Apr 2007 14:23:59 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HLNaVn031503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 14:23:58 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hdv9A-0002gc-7I for ietf-usefor@imc.org; Tue, 17 Apr 2007 23:23:32 +0200 Received: from d255054.dialin.hansenet.de ([80.171.255.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 23:23:32 +0200 Received: from nobody by d255054.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 23:23:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: #1416 Injection-Date - Summary of options Date: Tue, 17 Apr 2007 23:22:56 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 18 Message-ID: <46253AB0.1923@xyzzy.claranet.de> References: <JF7Fto.G8J@clerew.man.ac.uk> <JGnGvq.274@clerew.man.ac.uk> <87lkgqlvb0.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255054.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Russ Allbery wrote: > It's clear to me from the discussion that we need a couple new sections > to the document that provide clearer guidance and descriptions of how > the history mechanism works. That's good news from my POV as somebody who wants to know "how stuff works" without cheating like "get hold of a s-o-1036 copy". > I think it's reasonable to let the article possibly end up duplicated > in the bizarre case where the poster is multiply injecting and some > sites have the group marked moderated and some marked unmoderated. If that case is considered as "bizarre" please say so in the draft. Maybe not literally, but the tendency should be clear for readers. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HII0h3091096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 11:18:00 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HII07M091095; Tue, 17 Apr 2007 11:18:00 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.20.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIHdVc091006 for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 11:18:00 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7B9924BE53 for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 11:17:39 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 4C2934CB6C for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 11:17:39 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3F9F4E7F60; Tue, 17 Apr 2007 11:17:39 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1416 Injection-Date - Summary of options In-Reply-To: <JGnGvq.274@clerew.man.ac.uk> (Charles Lindsey's message of "Tue, 17 Apr 2007 16:09:26 GMT") Organization: The Eyrie References: <JF7Fto.G8J@clerew.man.ac.uk> <JGnGvq.274@clerew.man.ac.uk> Date: Tue, 17 Apr 2007 11:17:39 -0700 Message-ID: <87lkgqlvb0.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey <chl@clerew.man.ac.uk> writes: > I understand that Ruus has been tied up on other matters since then, but > that he hopes to return to active participation shortly. Yes, sorry. That's still my plan, and responding to that message is near the top of my priorities when I can find a bit of time again. It's clear to me from the discussion that we need a couple new sections to the document that provide clearer guidance and descriptions of how the history mechanism works. > So I think, in this case, the moderator MUST now discard any > Injection-Date already provided, and then proceed to inject the Approved > article in the normal manner, at which point he MAY then add an > Injection-Date, and MUST add one if he is injecting at multiple sites. Yup, that sounds right to me. Good catch. I think it's reasonable to let the article possibly end up duplicated in the bizarre case where the poster is multiply injecting and some sites have the group marked moderated and some marked unmoderated. Articles are occasionally duplicated in similar cirumstances today. > That will give the best chance of the article propagating normally, even > if the moderator delayed before Approving it. > There is a separate but related question of whether, for the benefit of > legacy injecting and relaying agents, he might need to do something about > a Date header that had been rendered unusually stale because of hiw own > delay. Usepro-06 made some special provision for this, and I think > Usepro-07 does also. Normally, of course, Date should be left strictly > alone as being a matter to be determined by the Poster, but one can hardly > blame the Poster for subsequent delays caused by the moderator. Yup. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGCSBE064167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 09:12:28 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HGCS3F064165; Tue, 17 Apr 2007 09:12:28 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGC5qo064101 for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 09:12:24 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3^clerew#man#ac$uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4624f1d5.7947.27 for ietf-usefor@imc.org; Tue, 17 Apr 2007 17:12:05 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3HGC1Db003090 for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 17:12:01 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3HGC1rf003087 for ietf-usefor@imc.org; Tue, 17 Apr 2007 17:12:01 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24591 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1416 Injection-Date - Summary of options Message-ID: <JGnGvq.274@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <JF7Fto.G8J@clerew.man.ac.uk> Date: Tue, 17 Apr 2007 16:09:26 GMT Lines: 92 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <JF7Fto.G8J@clerew.man.ac.uk> "Charles Lindsey" <chl@clerew.man.ac.uk> writes: >I think we have now said everything that is to be said on this, so I have >produced a summary of where I think we have got to. >It lists rules for what various agents are supposed to do with >Injection-Date in various situations. Most of these are, I think, agreed >(and they differ quite a bit from our starting point in the two versions >of USEPRO and in assumptions made at the start of this thread, so that at >least indicates some progress). I had hoped for some response to this, especially from Russ, particularly as to whether the points I claimed to be "agreed" were in fact agreed. That would then enable us to proceed to the main issue of disagreement: >There still remains the two conflicting possibilities (labelled IC and IR >in this summary) that we have to choose between, though I think we >understand the consequences of each better than we did. I understand that Ruus has been tied up on other matters since then, but that he hopes to return to active participation shortly. In the meantime, however, I have encountered one feature that we need to look at further. In addition to delays caused by a poster who prepares his article offline and then delays for some days before injecting it, there is also the case where the poster injects his article promptly but, because it is posted to a moderated group, the moderator may then delay for several days before approving it. >Posting agents: >--------------- ..... >P4. MAY include Injection-Date indicating time of actual injection (as >opposed to composition). ........... >P6. When injecting at multiple injecting agents, MUST include Injection-Date >which MUST then indicate time of earliest injection at any such agent. But of course all those multiple injections will now end up being sent to the same moderator, and the Injection-Date provided by the posting agent (which usually would not be aware whether a particular group was moderated or not) is largely meaningless. I am assuming, of course, that if the 'moderator' is actually a team of moderators with some bot to distribute articles amongst them, they will have set up arrangements to ensure that a given article only gets approved once. >Injecting Agents: >----------------- ...... >I4. MUST NOT insert (or alter or delete) Injection-Date if it is already >present. So I think, in this case, the moderator MUST now discard any Injection-Date already provided, and then proceed to inject the Approved article in the normal manner, at which point he MAY then add an Injection-Date, and MUST add one if he is injecting at multiple sites. That will give the best chance of the article propagating normally, even if the moderator delayed before Approving it. There is a separate but related question of whether, for the benefit of legacy injecting and relaying agents, he might need to do something about a Date header that had been rendered unusually stale because of hiw own delay. Usepro-06 made some special provision for this, and I think Usepro-07 does also. Normally, of course, Date should be left strictly alone as being a matter to be determined by the Poster, but one can hardly blame the Poster for subsequent delays caused by the moderator. Apart from this one case, I think all the other rules listed in my original message are unaffected. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGCP3o064155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 09:12:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HGCP3U064154; Tue, 17 Apr 2007 09:12:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGC3Ho064090 for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 09:12:24 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3^clerew$man*ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4624f1d2.e15a.120 for ietf-usefor@imc.org; Tue, 17 Apr 2007 17:12:02 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3HGC1ox003082 for <ietf-usefor@imc.org>; Tue, 17 Apr 2007 17:12:01 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3HGC0MY003079 for ietf-usefor@imc.org; Tue, 17 Apr 2007 17:12:00 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24590 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JGn37C.B5v@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> <461DE233.7080708@alvestrand.no> <JGG2F4.I8B@clerew.man.ac.uk> <87irbzh8ne.fsf@windlord.stanford.edu> Date: Tue, 17 Apr 2007 11:14:00 GMT Lines: 75 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <87irbzh8ne.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes: >Sorry to reply to this issue when I know that it's more important that I >reply to other open issues, but I'm doing the bit of work I had a moment >to do. I'm hoping to find time to do the more extensive work needed on >other fronts fairly soon, since I'm almost done with post-etch Debian >work. >My continued objection to being more explicit in various directions about >the path hosts (either the proposal to be more specific about what FQDN >means or to be more restrictive or explicit about how to set up DNS >records) is three-fold: > * It doesn't match existing practice. In existing practice, it is common > for the Path header to be the FQDN of the news server (which is why > that's explicitly stated to be the preferred option in the current > draft), but failing that, there are a wide variety of practices. Yes, though we might want tp prioritize them in some way (as indeed the present wording does to a small extent). > * Being more specific requires diving into DNS RRs to a degree that > quickly makes me uncomfortable.... All the proposed wording I've seen > so far doesn't deal directly with the question of CNAMEs. I tend to assume that you just follow CNAMEs and then deal with whatever they lead you to. Some past USEPRO drafts have said that explicitly, and it could be put back in if wanted. > * ...I don't believe that it is frequently necessary to try to construct > contact addresses from Path headers to reach intermediate sites, or > that when it is necessary it's particularly difficult under existing > practice (which doesn't require anything, really). I think it needs to be done often enough that the facility needs to be there. I agree that people familiar with the way things work can usually figure out how to make contact with a given domain-name (and if you are not familiar enough to do that, then you probably ought not to be trying in the first place). RFC 2142 tried to provide a mechanism (and even has pretensions to being a standard), but the trouble from a News POV is that it was a bit TOO prescriptive of how Paths should look, which is why we decided not to mention it normatively. >I would prefer to stick with the simple language in the current draft, >which represents existing practice except for stating that you can't just >make up any random name you want, and you can't use an invalid TLD. I think the problem with the present draft is that it is too specific about some things, and too vague about others (though I am happy with the clear distinction between FQDNs and <path-nodots> as covered with the wording of #3). The more you say about what IS allowed, the more you imply that possibilities not mentioned are NOT allowed. So either the wording needs to be tightened up (the FQDNs MUST/SHOULD/MAY resolve, in defined ways, to various desirable entities - hosts, servers, administrators, responsible persons, whatever); or else it needs to be loosened (it must be possible, by some means not specified in detail, to derive pointers to various desirable entities - hosts, servers, administrators, responsible persons, whatever). I think we are agreed that what we do NOT want is some jumbled collection of stuff that just happens for fit the syntax of a domain-name (like those 15 bogus tlds, for example). -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EAtJge051240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 03:55:19 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EAtJEq051238; Sat, 14 Apr 2007 03:55:19 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EAsu9p051194 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Sat, 14 Apr 2007 03:55:18 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hcfu5-0002cO-5x for ietf-usefor@imc.org; Sat, 14 Apr 2007 12:54:49 +0200 Received: from d252172.dialin.hansenet.de ([80.171.252.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sat, 14 Apr 2007 12:54:49 +0200 Received: from nobody by d252172.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Sat, 14 Apr 2007 12:54:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Date: Sat, 14 Apr 2007 12:54:15 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 17 Message-ID: <4620B2D6.7D@xyzzy.claranet.de> References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> <461DE233.7080708@alvestrand.no> <461E41AA.78BA@xyzzy.claranet.de> <JGG3J2.JKA@clerew.man.ac.uk> 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: d252172.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Charles Lindsey wrote: > What is an RP record? "Responsible Person", RFC 1183 (2.2). I'm puzzled by another article in this thread about newsAexample.B.example, where an A.example server uses for historic reasons a path identity newsAexample.B.example If it's not 100% clear (99.99% would be far too less) that A.example MUST immediately cease and desist to abuse names below B.example as soon as B.example wishes that, and I mean immediately, not tommorrow, then I second to add MUSTard to the USEPRO or any other draft stating this as normative fact. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3E4ddgM020591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Apr 2007 21:39:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3E4ddEG020589; Fri, 13 Apr 2007 21:39:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3E4dIKC020515 for <ietf-usefor@imc.org>; Fri, 13 Apr 2007 21:39:39 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0ABFB4CD76 for <ietf-usefor@imc.org>; Fri, 13 Apr 2007 21:39:18 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id CC6B14CC64 for <ietf-usefor@imc.org>; Fri, 13 Apr 2007 21:39:17 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id C30DBE79A6; Fri, 13 Apr 2007 21:39:17 -0700 (PDT) From: Russ Allbery <rra@stanford.edu> To: ietf-usefor@imc.org Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity In-Reply-To: <JGG2F4.I8B@clerew.man.ac.uk> (Charles Lindsey's message of "Fri, 13 Apr 2007 16:13:52 GMT") Organization: The Eyrie References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> <461DE233.7080708@alvestrand.no> <JGG2F4.I8B@clerew.man.ac.uk> Date: Fri, 13 Apr 2007 21:39:17 -0700 Message-ID: <87irbzh8ne.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Sorry to reply to this issue when I know that it's more important that I reply to other open issues, but I'm doing the bit of work I had a moment to do. I'm hoping to find time to do the more extensive work needed on other fronts fairly soon, since I'm almost done with post-etch Debian work. My continued objection to being more explicit in various directions about the path hosts (either the proposal to be more specific about what FQDN means or to be more restrictive or explicit about how to set up DNS records) is three-fold: * It doesn't match existing practice. In existing practice, it is common for the Path header to be the FQDN of the news server (which is why that's explicitly stated to be the preferred option in the current draft), but failing that, there are a wide variety of practices. I think Charles's analysis supports that as well. Discounting the bogus TLDs (which would not be acceptable under the new draft and I think rightfully so), over 11% of the <path-identity>s analyzed do not resolve. I think that makes it fairly clear that requiring the Path identity to be a resolvable DNS entry is not existing practice. * Being more specific requires diving into DNS RRs to a degree that quickly makes me uncomfortable. We get into A records vs. AAAA records vs. whatever someone comes up with later, discussion of the content of SOA records (I'd be hard-pressed to name any other protocol that cares about the contents of an SOA record outside of DNS itself), questions over whether MX records are okay (thereby potentially leading into questions about SRV records), etc. All the proposed wording I've seen so far doesn't deal directly with the question of CNAMEs. I think this is both complex and picky to specify and far outside the scope of the target audience of this specification, particularly given the third objection... * ...which is that, as pointed out by others, I'm hard-pressed to see how this matters enough to spend complexity and detailed specification on. I don't believe that it is frequently necessary to try to construct contact addresses from Path headers to reach intermediate sites, or that when it is necessary it's particularly difficult under existing practice (which doesn't require anything, really). Mapping a news server to an organization is generally more than sufficient, and we're indicating a preference for putting the FQDN of the news server in the Path header. I would prefer to stick with the simple language in the current draft, which represents existing practice except for stating that you can't just make up any random name you want, and you can't use an invalid TLD. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3E4FdrV018101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Apr 2007 21:15:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3E4Fdon018100; Fri, 13 Apr 2007 21:15:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3E4FCnB018072 for <ietf-usefor@imc.org>; Fri, 13 Apr 2007 21:15:32 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew#man#ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4620554e.7717.c2 for ietf-usefor@imc.org; Sat, 14 Apr 2007 05:15:10 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3E4FA8u017527 for <ietf-usefor@imc.org>; Sat, 14 Apr 2007 05:15:10 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3E4FA2E017524 for ietf-usefor@imc.org; Sat, 14 Apr 2007 05:15:10 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24586 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JGG2su.Is5@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> <461DE233.7080708@alvestrand.no> <461E26B9.5050908@mibsoftware.com> Date: Fri, 13 Apr 2007 16:22:06 GMT Lines: 45 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <461E26B9.5050908@mibsoftware.com> "Forrest J. Cavalier III" <mibsoft@mibsoftware.com> writes: >>> 2. A fully-qualified domain name (FQDN) within a zone affiliated (by >>> some SOA record) with the administrators of the agent (who could >>> then guarantee its uniqueness). For example, "server.example.org", >>> even if it had no DNS record of its own, would be covered by the >>> SOA record for "example.org". >> >> I don't see an improvement. If A runs a news server, and for some reason >> has an unlisted name in the B.com domain, by agreement with the B.com >> administrators, there is absolutely no reason why our standards should >> specify that he can't, even though the SOA records for B.com mention >> nothing about A. >> >Charles, we already understand your points. Did you really think rewording >would help? No, it is evident you do not understand them. >If you want a real life case to show your wording is not an improvement, >consider what happens in a corporate merger. The administrators of A could now >be responsible for keeping news.B.com running, but have no control over the DNS, >nor should they have to force all the peers to change to recognize a >renamed news.B.com. In that case (I am assuming A.com is the new name of the company, but it is too much hassle to tell all their peers to recognize news.A.com), then the proper course of action is for A to retain ownership of the domain B.com (with at least an SOA record in place, even if nothing else). Otherwise, some other body could now register the name B.com, and would then expect to be able to use news.B.com for any purpose they saw fit. My wording would disallow that. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3E4FXU9018095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Apr 2007 21:15:33 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3E4FXgb018094; Fri, 13 Apr 2007 21:15:33 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3E4FClP018071 for <ietf-usefor@imc.org>; Fri, 13 Apr 2007 21:15:32 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3&clerew*man&ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4620554e.13eb2.97 for ietf-usefor@imc.org; Sat, 14 Apr 2007 05:15:10 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3E4FAkb017519 for <ietf-usefor@imc.org>; Sat, 14 Apr 2007 05:15:10 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3E4F9LT017513 for ietf-usefor@imc.org; Sat, 14 Apr 2007 05:15:09 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24585 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JGG2F4.I8B@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> <461DE233.7080708@alvestrand.no> Date: Fri, 13 Apr 2007 16:13:52 GMT Lines: 100 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <461DE233.7080708@alvestrand.no> Harald Alvestrand <harald@alvestrand.no> writes: >As far as I can see, there is no support for your contention that we >need to do extra work to make a path-identity mailable. >That means no support for extra text for recognizing the MX case either. The conclusion of Issue "1093 was: The USEPRO document will not say MUST or SHOULD about any of the addresses "abuse@identity", "usefor@identity" or "news@identity". That is a long way from saying "The USEPRO Document will actively prevent, or hinder, the use of addresses such as "news@identity" etc." If you list, as allowed <path-identity>s, only those domain names which resolve to the IP address of a host, or do not resolve to anything but might be "affiliated" to some higher domain (i.e. the present cases #1 and #2), then you have outlawed the possibility of using a domain name that resolves to just an MX, and which might then have been used to try to send email to news@identity. I have just examined some 1571 articles in which I found 565 distinct <path-identity>s. Of these: 73 were <path-nodot>s (though that includes some <tail-entry>s) 492 were distinct domain-names (after following all CNAME pointers) Of these 492 domain-names 258 resolved to an A record only 23 resolved to an MX record only 135 resolved to both an A and an MX 4 resolved just to an NS (not very useful) 57 failed to resolve, but looked like an SOA record could be found (I didn't check) 15 had apparently bogus TLDs So it seems that MX records are in fairly widespread current use within <path-identity>s and hence it would not be proper to exclude them, which is what the present wording does. I am not asking for "extra work to make a path-identity mailable" - I am just asking for existing practice to be recognized. >I am certainly against it. > >>> 2. A fully-qualified domain name (FQDN) within a domain affiliated >>> with the administrators of the agent and guaranteed to be unique >>> by the administrators of that domain. For example, the >>> uniqueness of server.example.org could be guaranteed by the >>> administrator of example.org even if there is no DNS record for >>> server.example.org itself. >>> >> >> Well, you know I am not happy about that. But would it not be clearer (and >> more accurate) to say that the FQDN must be within a zone whose SOA record >> clearly identifies, or belongs to, the administrators of that domain (who >> are then responsible for ensuring its uniqueness). I.e., if you start with >> the FQDN and chop off components from the left, then you must assuredly >> arrive eventually at an FQDN with an SOA record (and presumably also some >> NS records and quite likely others records as well). For example: >> >> 2. A fully-qualified domain name (FQDN) within a zone affiliated (by >> some SOA record) with the administrators of the agent (who could >> then guarantee its uniqueness). For example, "server.example.org", >> even if it had no DNS record of its own, would be covered by the >> SOA record for "example.org". >I don't see an improvement. If A runs a news server, and for some reason >has an unlisted name in the B.com domain, by agreement with the B.com >administrators, there is absolutely no reason why our standards should >specify that he can't, even though the SOA records for B.com mention >nothing about A. But my wording does not "specify that he can't"; it merely requires that the adminitrators of B.com take some responsibility for allowing A to use their namespace. >It's reasonable to ask that if you ask the administrators of B.com about >the name "AsNewsServer.B.com", they recognize the name as something >they've allowed to be used. (I'm not sure "affiliated" means exactly >that, but it can be stretched to that meaning, I think). But I don't see >a reason to ask them to put that in the SOA record. Nobody is asking them to put anything different in the SOA record (in fact, there is no mechanism whereby that could be done). In fact, my wording does exactly what you suggest, but it also makes it absolutely clear that those 15 bogus TLDs are out of order. And s/affiliated/associated/ might be clearer in cases such as the one you mentioned. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3E4FXFU018097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Apr 2007 21:15:33 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3E4FXF7018096; Fri, 13 Apr 2007 21:15:33 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3E4FCrR018073 for <ietf-usefor@imc.org>; Fri, 13 Apr 2007 21:15:32 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3#clerew$man#ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4620554f.136c3.98 for ietf-usefor@imc.org; Sat, 14 Apr 2007 05:15:11 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3E4FBgW017535 for <ietf-usefor@imc.org>; Sat, 14 Apr 2007 05:15:11 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3E4FBxx017532 for ietf-usefor@imc.org; Sat, 14 Apr 2007 05:15:11 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24587 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JGG3J2.JKA@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> <461DE233.7080708@alvestrand.no> <461E41AA.78BA@xyzzy.claranet.de> Date: Fri, 13 Apr 2007 16:37:50 GMT Lines: 51 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <461E41AA.78BA@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes: >Harald Alvestrand wrote: >>> A fully-qualified domain name (FQDN) within a zone affiliated (by >>> some SOA record) with the administrators of the agent (who could >>> then guarantee its uniqueness). For example, "server.example.org", >>> even if it had no DNS record of its own, would be covered by the >>> SOA record for "example.org". >> I don't see an improvement. If A runs a news server, and for some >> reason has an unlisted name in the B.com domain, by agreement with >> the B.com administrators, there is absolutely no reason why our >> standards should specify that he can't, even though the SOA records >> for B.com mention nothing about A. >Maybe that's not what Charles is talking about, and he simply wants >"unique within the relevant zone". Or "below the relevant SoA", if >that's clearer. Exactly. In particular, I want some assured method whereby, if a domain name is used in a <path-identity>, you can use the DNS to identify someone with responsibility for it. An SOA record is probably the last resort (usually, by chopping off components from the left, you will probably find something more convenient before you get that far). > As an example, I can't use news.xyzzy.claranet.de >just because I think it's cute. In theory there could be a real >user "news.xyzzy" different from user "xyzzy", and in practice the >A and MX for news.xyzzy.claranet.de have nothing to do with me, it's >a wildcard. In theory yes, but I think you would be entitled to take a very dim view if Claranet tried to create an A record for news.xyzzy.claranet.de without some request from you beforehand. >And it's an example why Charles' A, AAAA, or MX proposal would not >always do what he hopes. It would also miss RP records. What is an RP record? -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CESoYO007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:28:50 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CESoZR007681; Thu, 12 Apr 2007 07:28:50 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CESRrM007530 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-usefor@imc.org>; Thu, 12 Apr 2007 07:28:49 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hc0HL-0004Qp-VG for ietf-usefor@imc.org; Thu, 12 Apr 2007 16:28:04 +0200 Received: from d253245.dialin.hansenet.de ([80.171.253.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Thu, 12 Apr 2007 16:28:03 +0200 Received: from nobody by d253245.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-usefor@imc.org>; Thu, 12 Apr 2007 16:28:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann <nobody@xyzzy.claranet.de> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Date: Thu, 12 Apr 2007 16:26:50 +0200 Organization: <URL:http://purl.net/xyzzy> Lines: 27 Message-ID: <461E41AA.78BA@xyzzy.claranet.de> References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> <461DE233.7080708@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253245.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Harald Alvestrand wrote: >> A fully-qualified domain name (FQDN) within a zone affiliated (by >> some SOA record) with the administrators of the agent (who could >> then guarantee its uniqueness). For example, "server.example.org", >> even if it had no DNS record of its own, would be covered by the >> SOA record for "example.org". > I don't see an improvement. If A runs a news server, and for some > reason has an unlisted name in the B.com domain, by agreement with > the B.com administrators, there is absolutely no reason why our > standards should specify that he can't, even though the SOA records > for B.com mention nothing about A. Maybe that's not what Charles is talking about, and he simply wants "unique within the relevant zone". Or "below the relevant SoA", if that's clearer. As an example, I can't use news.xyzzy.claranet.de just because I think it's cute. In theory there could be a real user "news.xyzzy" different from user "xyzzy", and in practice the A and MX for news.xyzzy.claranet.de have nothing to do with me, it's a wildcard. And it's an example why Charles' A, AAAA, or MX proposal would not always do what he hopes. It would also miss RP records. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CCVuO5096842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 05:31:56 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CCVuu3096841; Thu, 12 Apr 2007 05:31:56 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3CCVYBr096812 for <ietf-usefor@imc.org>; Thu, 12 Apr 2007 05:31:55 -0700 (MST) (envelope-from mibsoft@mibsoftware.com) Received: (qmail 61130 invoked from network); 12 Apr 2007 12:31:33 -0000 Received: from 208.111.203.72 (HELO ?192.168.2.11?) (208.111.203.72) by relay03.pair.com with SMTP; 12 Apr 2007 12:31:33 -0000 X-pair-Authenticated: 208.111.203.72 Message-ID: <461E26B9.5050908@mibsoftware.com> Date: Thu, 12 Apr 2007 08:31:53 -0400 From: "Forrest J. Cavalier III" <mibsoft@mibsoftware.com> User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor@imc.org Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> <461DE233.7080708@alvestrand.no> In-Reply-To: <461DE233.7080708@alvestrand.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> >> 2. A fully-qualified domain name (FQDN) within a zone affiliated (by >> some SOA record) with the administrators of the agent (who could >> then guarantee its uniqueness). For example, "server.example.org", >> even if it had no DNS record of its own, would be covered by the >> SOA record for "example.org". > > I don't see an improvement. If A runs a news server, and for some reason > has an unlisted name in the B.com domain, by agreement with the B.com > administrators, there is absolutely no reason why our standards should > specify that he can't, even though the SOA records for B.com mention > nothing about A. > Charles, we already understand your points. Did you really think rewording would help? If you want a real life case to show your wording is not an improvement, consider what happens in a corporate merger. The administrators of A could now be responsible for keeping news.B.com running, but have no control over the DNS, nor should they have to force all the peers to change to recognize a renamed news.B.com. (If you still can't see the problem, know that in the real word there is a difference between "administrators of the agent" and "administrators of that domain.") And, (not that it matters) "who could then guarantee its uniqueness" is a particularly bad wording, Charles. It doesn't mean what you intended. "could" is a statement of possibility, not a requirement in a standard. But don't bother correcting it. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C7depD071653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 00:39:40 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3C7denc071652; Thu, 12 Apr 2007 00:39:40 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C7dbpW071645 for <ietf-usefor@imc.org>; Thu, 12 Apr 2007 00:39:37 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE63A259719; Thu, 12 Apr 2007 09:39:36 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27139-06; Thu, 12 Apr 2007 09:39:31 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F2EB2596F5; Thu, 12 Apr 2007 09:39:31 +0200 (CEST) Message-ID: <461DE233.7080708@alvestrand.no> Date: Thu, 12 Apr 2007 09:39:31 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Charles Lindsey <chl@clerew.man.ac.uk> Cc: ietf-usefor@imc.org Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JGCGC5.9Js@clerew.man.ac.uk> In-Reply-To: <JGCGC5.9Js@clerew.man.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> As far as I can see, there is no support for your contention that we need to do extra work to make a path-identity mailable. That means no support for extra text for recognizing the MX case either. I am certainly against it. >> 2. A fully-qualified domain name (FQDN) within a domain affiliated >> with the administrators of the agent and guaranteed to be unique >> by the administrators of that domain. For example, the >> uniqueness of server.example.org could be guaranteed by the >> administrator of example.org even if there is no DNS record for >> server.example.org itself. >> > > Well, you know I am not happy about that. But would it not be clearer (and > more accurate) to say that the FQDN must be within a zone whose SOA record > clearly identifies, or belongs to, the administrators of that domain (who > are then responsible for ensuring its uniqueness). I.e., if you start with > the FQDN and chop off components from the left, then you must assuredly > arrive eventually at an FQDN with an SOA record (and presumably also some > NS records and quite likely others records as well). For example: > > 2. A fully-qualified domain name (FQDN) within a zone affiliated (by > some SOA record) with the administrators of the agent (who could > then guarantee its uniqueness). For example, "server.example.org", > even if it had no DNS record of its own, would be covered by the > SOA record for "example.org". I don't see an improvement. If A runs a news server, and for some reason has an unlisted name in the B.com domain, by agreement with the B.com administrators, there is absolutely no reason why our standards should specify that he can't, even though the SOA records for B.com mention nothing about A. It's reasonable to ask that if you ask the administrators of B.com about the name "AsNewsServer.B.com", they recognize the name as something they've allowed to be used. (I'm not sure "affiliated" means exactly that, but it can be stretched to that meaning, I think). But I don't see a reason to ask them to put that in the SOA record. Harald Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C4GCdc055955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2007 21:16:12 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3C4GC68055954; Wed, 11 Apr 2007 21:16:12 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C4Fmok055898 for <ietf-usefor@imc.org>; Wed, 11 Apr 2007 21:16:11 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3#clerew$man&ac$uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 461db273.174f0.225 for ietf-usefor@imc.org; Thu, 12 Apr 2007 05:15:47 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l3C4Fk81022260 for <ietf-usefor@imc.org>; Thu, 12 Apr 2007 05:15:46 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l3C4FjSo022257 for ietf-usefor@imc.org; Thu, 12 Apr 2007 05:15:45 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24581 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JGCGC5.9Js@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> Date: Wed, 11 Apr 2007 17:24:05 GMT Lines: 84 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <08DBF8F69193F92ACDF00313@[192.168.1.108]> Harald Tveit Alvestrand <harald@alvestrand.no> writes: >After having read 5 mails from Frank on the issue, I still am not sure >whether Frank supports adding it as a tracked issue or not. >But we might as well get on with it. >The issue concerns the following text in USEPRO-07: I have had some further thoughts on this. > The <path-identity> used by an agent may be chosen via one of the > following methods (in decreasing order of preference): Maybe s/may/SHOULD/ > 1. The fully-qualified domain name (FQDN) of the system on which the > agent is running. That seems to be only half the story. AIUI, normal current practice is to provide either a. An FQDN with an A or AAAA record that identifies the system like you say, or b. An FQDN with an MX record enabling email contact, but not identifying the system, or even c. An FQDN with both an A (or AAAA) -and- and MX (best of both worlds). I don't think we want to express any preference between these, but currently we don't seem to recognize case b at all. May I therefore suggest: 1. A fully-qualified domain name (FQDN) resolving to either (or both) of . an A or AAAA record identifying the system on which the agent is running; . an MX record enabling email contact with the administrators of that agent (e.g. using one of the role names suggested in [RFC 2142]). {where "suggested" is about the weakest or various possible terms that might be used there, and the reference to RFC 2142 is clearly just informational} > 2. A fully-qualified domain name (FQDN) within a domain affiliated > with the administrators of the agent and guaranteed to be unique > by the administrators of that domain. For example, the > uniqueness of server.example.org could be guaranteed by the > administrator of example.org even if there is no DNS record for > server.example.org itself. Well, you know I am not happy about that. But would it not be clearer (and more accurate) to say that the FQDN must be within a zone whose SOA record clearly identifies, or belongs to, the administrators of that domain (who are then responsible for ensuring its uniqueness). I.e., if you start with the FQDN and chop off components from the left, then you must assuredly arrive eventually at an FQDN with an SOA record (and presumably also some NS records and quite likely others records as well). For example: 2. A fully-qualified domain name (FQDN) within a zone affiliated (by some SOA record) with the administrators of the agent (who could then guarantee its uniqueness). For example, "server.example.org", even if it had no DNS record of its own, would be covered by the SOA record for "example.org". > 3. Some other (arbitrary) name in the form <path-nodot> believed to > be unique and registered at least with all the other news servers > to which that relaying agent or injecting agent sends articles. > This option SHOULD NOT be used unless the earlier options are > unavailable or unless the name is of longstanding usage. And the wording of case #3 is fine as it stands. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l35GCSUa064420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 09:12:28 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l35GCSsj064419; Thu, 5 Apr 2007 09:12:28 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l35GC5sZ064401 for <ietf-usefor@imc.org>; Thu, 5 Apr 2007 09:12:27 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew#man$ac^uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46151fd1.17932.255 for ietf-usefor@imc.org; Thu, 5 Apr 2007 17:12:01 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l35GC1HE017537 for <ietf-usefor@imc.org>; Thu, 5 Apr 2007 17:12:01 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l35GC0qC017532 for ietf-usefor@imc.org; Thu, 5 Apr 2007 17:12:00 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24579 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JG0w2w.ED@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JFyyq1.253@clerew.man.ac.uk> <YfIFxxBc45EGFAgQ@highwayman.com> Date: Thu, 5 Apr 2007 11:32:56 GMT Lines: 36 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <YfIFxxBc45EGFAgQ@highwayman.com> Richard Clayton <richard@highwayman.com> writes: >I reread 2142, and see that it expects either #1 or the top level FQDN >for the organisation (which #2 covers) I don't think #2 covers 2142, because if it is neither an MX nor an A record, then there is no way to send email to abuse/news/postmaster/whatever @ it. My main objection to #2 is that I regard it as a sloppy practice which I don't want to legitimize (thus a guy who wants to do it has to bear the stigma of breaking a SHOULD NOT - that does not mean the sky will fall in). >only the desperate look at the path ... everyone else looks at the >injection info to find out who to talk to Sure. You only want to mail someone in the middle of the Path is you want to draw his attention to some technical problem at his site >bottom line: I don't see a need for the SHOULD NOT, and I'm not deeply >in favour of giving 2142 a plug. I would only give it the mildest of plugs. For sure it would be informative and not normative. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l358GYDf011035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 01:16:34 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l358GYHw011034; Thu, 5 Apr 2007 01:16:34 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from deimos.babel.de (deimos.babel.de [145.253.109.90]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l358GCN2011013 for <ietf-usefor@imc.org>; Thu, 5 Apr 2007 01:16:33 -0700 (MST) (envelope-from rbabel@babylon.pfm-mainz.de) In-Reply-To: <46138FC4.7030904@alvestrand.no> From: rbabel@babylon.pfm-mainz.de (Ralph Babel from the peanut gallery) To: ietf-usefor@imc.org Subject: Re: Count of senders to this mailing list Message-Id: <20070405081437.ECB7F56B866@message-id.pfm-mainz.de> Date: Thu, 5 Apr 2007 10:14:37 +0200 (CEST) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> Harald Alvestrand wrote: > It seems it's quiet here... Usefor ain't dead; it just smells funny. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34G1ojx070974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 09:01:50 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l34G1oJf070973; Wed, 4 Apr 2007 09:01:50 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34G1ScP070942 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 09:01:49 -0700 (MST) (envelope-from schlitt@world.std.com) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l34FmPuk024701; Wed, 4 Apr 2007 11:48:27 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id l34FmPdZ1479598; Wed, 4 Apr 2007 11:48:25 -0400 (EDT) Received: from localhost (schlitt@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) with ESMTP id l34FmMPQ1443140; Wed, 4 Apr 2007 11:48:22 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: schlitt owned process doing -bs Date: Wed, 4 Apr 2007 11:48:22 -0400 From: Dan Schlitt <schlitt@world.std.com> X-X-Sender: schlitt@shell01.TheWorld.com To: Harald Alvestrand <harald@alvestrand.no> cc: Usefor Mailing List <ietf-usefor@imc.org> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity In-Reply-To: <461343EF.8030800@alvestrand.no> Message-ID: <Pine.SGI.4.56.0704041146400.1480457@shell01.TheWorld.com> References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <461343EF.8030800@alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> I agree with Harald. In my experience running a news server only the uniqueness of the names on the path was useful. /dan -- Dan Schlitt schlitt@world.std.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34CloVT055624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 05:47:50 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l34ClodB055623; Wed, 4 Apr 2007 05:47:50 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from anchor-post-35.mail.demon.net (anchor-post-35.mail.demon.net [194.217.242.85]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34ClSmH055593 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 05:47:49 -0700 (MST) (envelope-from richard@highwayman.com) Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1HZ4tZ-0007ob-Gj for ietf-usefor@imc.org; Wed, 04 Apr 2007 12:47:25 +0000 Message-ID: <YfIFxxBc45EGFAgQ@highwayman.com> Date: Wed, 4 Apr 2007 13:46:20 +0100 To: ietf-usefor@imc.org From: Richard Clayton <richard@highwayman.com> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> <JFyyq1.253@clerew.man.ac.uk> In-Reply-To: <JFyyq1.253@clerew.man.ac.uk> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.03 M <HA4$+XqL77PuKOKLrOR+dOMxqa> Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <JFyyq1.253@clerew.man.ac.uk>, Charles Lindsey <chl@clerew.man.ac.uk> writes >> The <path-identity> used by an agent may be chosen via one of the >> following methods (in decreasing order of preference): > >> 1. The fully-qualified domain name (FQDN) of the system on which the >> agent is running. > >> 2. A fully-qualified domain name (FQDN) within a domain affiliated >> with the administrators of the agent and guaranteed to be unique >> by the administrators of that domain. For example, the >> uniqueness of server.example.org could be guaranteed by the >> administrator of example.org even if there is no DNS record for >> server.example.org itself. > >> 3. Some other (arbitrary) name in the form <path-nodot> believed to >> be unique and registered at least with all the other news servers >> to which that relaying agent or injecting agent sends articles. >> This option SHOULD NOT be used unless the earlier options are >> unavailable or unless the name is of longstanding usage. > >>As far as I can tell, Charles is proposing that the second option should >>have a "SHOULD NOT be used" attached to it, just like the third. >>As far as I can tell, Frank does not see a benefit to such a change. >>No other people have contributed to this thread. I reread 2142, and see that it expects either #1 or the top level FQDN for the organisation (which #2 covers) >More or less. I think I would rather combine #1 and #2 by saying that it >SHOULD be a fully-qualified domain name (FQDN) resolvable, to >MX/A/AAAA/CNAME, in the DNS, which amounts to much the same thing. only the desperate look at the path ... everyone else looks at the injection info to find out who to talk to X-Complaints-To: abuse@giganews.com because what people complain about is the injection of an article not the fact that it has propagated. Although there seems to be some feeling that people regularly want to write to news servers in the middle of propagation paths in order to discuss the mangling of articles (or some other wickedness), that doesn't sound like the real world to me. Those who chase down such obscure things are probably capable of driving search engines, corresponding with other Usenet administrators, and finding out who to talk to by out-of-band techniques [which probably eschew role addresses because getting things done means getting another specific sysadmin to own the problem for you] As Harald say, it's only uniqueness that matters to the protocol, and being non-unique only damages you and your clone -- except in corner cases where servers are downstream of a single major server... >I accept that we are not going to make any normative statement regarding >mail addresses to reach sites, but I would still like to see a NOTE >pointing out the existence of RFC 2142, which implementors than then decide >for themselves whether to follow. Something like: > > NOTE: According to [RFC 2142], the forms "usenet@<path-identity>" and > "news@<path-identity>" are common addresses for a news server > administrator. X-Trace and X-Complaints-To arrived in INN pretty much the same time as 2142 came out... which will be why 2142 documented the only method widely available at that time... bottom line: I don't see a need for the SHOULD NOT, and I'm not deeply in favour of giving 2142 a plug. - -- richard Richard Clayton They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBRhOeHJoAxkTY1oPiEQK5aACgz/p5RO6RmToIedXkLbVp5tLfc5UAoIY5 jsrNAMpJ8zX+jrgndngbLRLq =Ci9G -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34C6F9e052868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 05:06:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l34C6FMB052867; Wed, 4 Apr 2007 05:06:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l34C5sXE052850 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 05:06:14 -0700 (MST) (envelope-from mibsoft@mibsoftware.com) Received: (qmail 61550 invoked from network); 4 Apr 2007 12:05:53 -0000 Received: from 199.224.97.235 (HELO ?192.168.2.11?) (199.224.97.235) by relay00.pair.com with SMTP; 4 Apr 2007 12:05:53 -0000 X-pair-Authenticated: 199.224.97.235 Message-ID: <461394AC.6080105@mibsoftware.com> Date: Wed, 04 Apr 2007 08:06:04 -0400 From: "Forrest J. Cavalier III" <mibsoft@mibsoftware.com> User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Usefor Mailing List <ietf-usefor@imc.org> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> In-Reply-To: <08DBF8F69193F92ACDF00313@[192.168.1.108]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> I support no change required. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34BjdCA051388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 04:45:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l34BjdHh051387; Wed, 4 Apr 2007 04:45:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34BjIcO051354 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 04:45:38 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7CC3A2597B8 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 13:45:17 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06341-08 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 13:45:09 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D73C02597B7 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 13:45:08 +0200 (CEST) Message-ID: <46138FC4.7030904@alvestrand.no> Date: Wed, 04 Apr 2007 13:45:08 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Usenet <ietf-usefor@imc.org> Subject: Count of senders to this mailing list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> I did a count of the senders to this mailing list today, over the last 14 days. It seems it's quiet here... msgs since 21-Mar-2007 1 9 40.91 "Charles Lindsey" <chl@clerew.man.ac.uk> 2 8 77.27 Harald Tveit Alvestrand <harald@alvestrand.no> 3 3 90.91 Frank Ellermann <nobody@xyzzy.claranet.de> 4 2 100.00 Harald Alvestrand <harald@alvestrand.no> Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34BCQfE048673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 04:12:26 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l34BCQxS048672; Wed, 4 Apr 2007 04:12:26 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l34BC5Nf048613 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 04:12:25 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3*clerew$man*ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46138803.108e9.266 for ietf-usefor@imc.org; Wed, 4 Apr 2007 12:12:03 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l34BC2t6005152 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 12:12:02 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l34BC2l7005148 for ietf-usefor@imc.org; Wed, 4 Apr 2007 12:12:02 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24573 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <JFyyq1.253@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> Date: Wed, 4 Apr 2007 10:34:49 GMT Lines: 61 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <08DBF8F69193F92ACDF00313@[192.168.1.108]> Harald Tveit Alvestrand <harald@alvestrand.no> writes: >After having read 5 mails from Frank on the issue, I still am not sure >whether Frank supports adding it as a tracked issue or not. >But we might as well get on with it. >The issue concerns the following text in USEPRO-07: > The <path-identity> used by an agent may be chosen via one of the > following methods (in decreasing order of preference): > 1. The fully-qualified domain name (FQDN) of the system on which the > agent is running. > 2. A fully-qualified domain name (FQDN) within a domain affiliated > with the administrators of the agent and guaranteed to be unique > by the administrators of that domain. For example, the > uniqueness of server.example.org could be guaranteed by the > administrator of example.org even if there is no DNS record for > server.example.org itself. > 3. Some other (arbitrary) name in the form <path-nodot> believed to > be unique and registered at least with all the other news servers > to which that relaying agent or injecting agent sends articles. > This option SHOULD NOT be used unless the earlier options are > unavailable or unless the name is of longstanding usage. >As far as I can tell, Charles is proposing that the second option should >have a "SHOULD NOT be used" attached to it, just like the third. >As far as I can tell, Frank does not see a benefit to such a change. >No other people have contributed to this thread. More or less. I think I would rather combine #1 and #2 by saying that it SHOULD be a fully-qualified domain name (FQDN) resolvable, to MX/A/AAAA/CNAME, in the DNS, which amounts to much the same thing. That still leaves a chink for someone who convinces himself that his case is extra special to violate that SHOULD. >The discussion of mail addresses to reach sites remains #1093, and is not >part of this issue#. I accept that we are not going to make any normative statement regarding mail addresses to reach sites, but I would still like to see a NOTE pointing out the existence of RFC 2142, which implementors than then decide for themselves whether to follow. Something like: NOTE: According to [RFC 2142], the forms "usenet@<path-identity>" and "news@<path-identity>" are common addresses for a news server administrator. -- 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 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l346LhJq027249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 23:21:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l346Lg6W027248; Tue, 3 Apr 2007 23:21:42 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l346LfBL027242 for <ietf-usefor@imc.org>; Tue, 3 Apr 2007 23:21:42 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FCCD2597B4; Wed, 4 Apr 2007 08:21:41 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30786-03; Wed, 4 Apr 2007 08:21:35 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 548D22597B3; Wed, 4 Apr 2007 08:21:35 +0200 (CEST) Message-ID: <461343EF.8030800@alvestrand.no> Date: Wed, 04 Apr 2007 08:21:35 +0200 From: Harald Alvestrand <harald@alvestrand.no> User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Harald Tveit Alvestrand <harald@alvestrand.no> Cc: Usefor Mailing List <ietf-usefor@imc.org> Subject: Re: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity References: <08DBF8F69193F92ACDF00313@[192.168.1.108]> In-Reply-To: <08DBF8F69193F92ACDF00313@[192.168.1.108]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> My technical opinion (chair hat OFF): The requirement on a path-identity is uniqueness only. Option 2 guarantees uniqueness as well as option 1 does. Resolvability gives no extra value for the uniqueness requirement. I support "no change required" as the resolution of this issue. Harald Harald Tveit Alvestrand wrote: > > After having read 5 mails from Frank on the issue, I still am not sure > whether Frank supports adding it as a tracked issue or not. > But we might as well get on with it. > > The issue concerns the following text in USEPRO-07: > > The <path-identity> used by an agent may be chosen via one of the > following methods (in decreasing order of preference): > > 1. The fully-qualified domain name (FQDN) of the system on which the > agent is running. > > 2. A fully-qualified domain name (FQDN) within a domain affiliated > with the administrators of the agent and guaranteed to be unique > by the administrators of that domain. For example, the > uniqueness of server.example.org could be guaranteed by the > administrator of example.org even if there is no DNS record for > server.example.org itself. > > 3. Some other (arbitrary) name in the form <path-nodot> believed to > be unique and registered at least with all the other news servers > to which that relaying agent or injecting agent sends articles. > This option SHOULD NOT be used unless the earlier options are > unavailable or unless the name is of longstanding usage. > > As far as I can tell, Charles is proposing that the second option > should have a "SHOULD NOT be used" attached to it, just like the third. > As far as I can tell, Frank does not see a benefit to such a change. > No other people have contributed to this thread. > > The discussion of mail addresses to reach sites remains #1093, and is > not part of this issue#. > > Harald (in role as issue tracker) > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l344VHC2021474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 21:31:17 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l344VHRs021473; Tue, 3 Apr 2007 21:31:17 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l344VGWC021467 for <ietf-usefor@imc.org>; Tue, 3 Apr 2007 21:31:17 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1FA492597B1 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 06:31:16 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27877-06 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 06:31:11 +0200 (CEST) Received: from [192.168.1.108] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0234D2597B0 for <ietf-usefor@imc.org>; Wed, 4 Apr 2007 06:31:10 +0200 (CEST) Date: Wed, 04 Apr 2007 06:31:00 +0200 From: Harald Tveit Alvestrand <harald@alvestrand.no> To: Usefor Mailing List <ietf-usefor@imc.org> Subject: #1482: USEPRO 3.2: Possibility to use non-resolvable domain name as path-identity Message-ID: <08DBF8F69193F92ACDF00313@[192.168.1.108]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> After having read 5 mails from Frank on the issue, I still am not sure whether Frank supports adding it as a tracked issue or not. But we might as well get on with it. The issue concerns the following text in USEPRO-07: The <path-identity> used by an agent may be chosen via one of the following methods (in decreasing order of preference): 1. The fully-qualified domain name (FQDN) of the system on which the agent is running. 2. A fully-qualified domain name (FQDN) within a domain affiliated with the administrators of the agent and guaranteed to be unique by the administrators of that domain. For example, the uniqueness of server.example.org could be guaranteed by the administrator of example.org even if there is no DNS record for server.example.org itself. 3. Some other (arbitrary) name in the form <path-nodot> believed to be unique and registered at least with all the other news servers to which that relaying agent or injecting agent sends articles. This option SHOULD NOT be used unless the earlier options are unavailable or unless the name is of longstanding usage. As far as I can tell, Charles is proposing that the second option should have a "SHOULD NOT be used" attached to it, just like the third. As far as I can tell, Frank does not see a benefit to such a change. No other people have contributed to this thread. The discussion of mail addresses to reach sites remains #1093, and is not part of this issue#. Harald (in role as issue tracker) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l32GCPV8082836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2007 09:12:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l32GCPpg082835; Mon, 2 Apr 2007 09:12:25 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l32GC30M082824 for <ietf-usefor@imc.org>; Mon, 2 Apr 2007 09:12:24 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew#man$ac&uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46112b52.93f2.39 for ietf-usefor@imc.org; Mon, 2 Apr 2007 17:12:02 +0100 (envelope-sender <news@clerew.man.ac.uk>) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l32GC1O0025607 for <ietf-usefor@imc.org>; Mon, 2 Apr 2007 17:12:01 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l32GC1Ra025604 for ietf-usefor@imc.org; Mon, 2 Apr 2007 17:12:01 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:24571 Path: clerew!chl From: "Charles Lindsey" <chl@clerew.man.ac.uk> Subject: Re: ISSUE: Possibility to use non-resolvable domain name as path-identity Message-ID: <JFvGzx.BFr@clerew.man.ac.uk> X-Newsreader: NN version 6.5.2 (NOV) References: <JDGK5C.9xJ@clerew.man.ac.uk> <9E8434B41B5C79F191D7574F@[10.0.0.174]> <JF9D0r.4BF@clerew.man.ac.uk> <EBA3768D856B40B90155D690@B50854F0A9192E8EC6CDA126> <4604542B.433A@xyzzy.claranet.de> <46077763.6010201@alvestrand.no> <JFKqAF.2xB@clerew.man.ac.uk> <460A9E35.A6B@xyzzy.claranet.de> <JFqDFp.7p@clerew.man.ac.uk> <460E807D.14F3@xyzzy.claranet.de> Date: Mon, 2 Apr 2007 13:19:09 GMT Lines: 40 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/> List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe> List-ID: <ietf-usefor.imc.org> In <460E807D.14F3@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes: >Charles Lindsey wrote: >> And all I am asking is that it SHOULD resolve. >For which query types (apart from soa and ns) ? A type 99 record >"v=spf1 -all" won't help for the purposes of news (in fact it would >be very near to pointless without a corresponding SMTP server, MTAs >can reject MAIL FROM:<whatever@news17.news-servers.example.com> if >there's no IP and no MX, without wasting time for SPF checks). Even NS would be interesting, if there is nothing else. >SRV or similar records could be interesting, if the "news-servers" >at example.com wish to enumerate their hosts news17, etc. That's >only a future possibility mentioned in the "URI" I-D so far, and >it's unrelated to any "SHOULD resolve (some query types TBD)". >> Then if it doesn't, it immediately draws attention to itself as a >> cause for suspicion. >I don't recall a single case where I tried `nslookup -q=any` for a >path identity, and I looked into the peering database a few times >while trying to figure out path header fields. Admittedly I'm more >interested in mail abuse today. Actually, I quite often use ANY (with 'dig' rather than 'nslookuop') when I am not quite sure what I am looking for. -- 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
- Count of senders to this mailing list, April 30 Harald Alvestrand