Re: #1416 Injection-Date: proposed diff

[Russ Allbery <[e-mail]>]

"Charles Lindsey" <[e-mail]> writes:
> Russ Allbery <[e-mail]> writes:

>> So he still knows he's reinjecting (or not) and therefore his software
>> still handles Injection-Date properly unless his software has been
>> broken all along for comp.* as well.

> No, he thinks he is just relaying an article to comp.misc.

Not if he's using POST he doesn't, and if he's not using POST, he's not
reinjecting.  (Barring configurations that use IHAVE for injection in
intentional violation of a SHOULD NOT in RFC3977, at which point they're
on their own in getting the details right because that's why the standard
says you shouldn't do that.  And at that point, the server accepting the
IHAVE has to take responsibility for ensuring the right thing happens
because the client can no longer indicate the difference between relaying
and the injection of an article.)

If he's using POST with an article that he didn't just prepare from
scratch with a posting agent, he's reinjecting.  It's unambiguous as to
whether you're reinjecting or relaying, and I don't see how one could
possibly create a situation where one is accidentally reinjecting without
being aware it's happening (only scenarios where the articles being
reinjected are other than was intended).

-- 
Russ Allbery ([e-mail])             <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 l6VI0Aw3069303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2007 11:00:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6VI0A32069302; Tue, 31 Jul 2007 11:00:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6VI09Ne069295 for <[e-mail]>; Tue, 31 Jul 2007 11:00:09 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 293554C93E for <[e-mail]>; Tue, 31 Jul 2007 11:00:09 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 1D3DC4CA25 for <[e-mail]>; Tue, 31 Jul 2007 11:00:07 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 18A84E78F7; Tue, 31 Jul 2007 11:00:07 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Tue, 31 Jul 2007 11:38:40 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 31 Jul 2007 11:00:06 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <[e-mail]> writes:
> Russ Allbery <[e-mail]> writes:

>> So he still knows he's reinjecting (or not) and therefore his software
>> still handles Injection-Date properly unless his software has been
>> broken all along for comp.* as well.

> No, he thinks he is just relaying an article to comp.misc.

Not if he's using POST he doesn't, and if he's not using POST, he's not
reinjecting.  (Barring configurations that use IHAVE for injection in
intentional violation of a SHOULD NOT in RFC3977, at which point they're
on their own in getting the details right because that's why the standard
says you shouldn't do that.  And at that point, the server accepting the
IHAVE has to take responsibility for ensuring the right thing happens
because the client can no longer indicate the difference between relaying
and the injection of an article.)

If he's using POST with an article that he didn't just prepare from
scratch with a posting agent, he's reinjecting.  It's unambiguous as to
whether you're reinjecting or relaying, and I don't see how one could
possibly create a situation where one is accidentally reinjecting without
being aware it's happening (only scenarios where the articles being
reinjected are other than was intended).

-- 
Russ Allbery ([e-mail])             <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 l6VGFQfZ059736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2007 09:15:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6VGFQLC059735; Tue, 31 Jul 2007 09:15:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6VGFOus059726 for <[e-mail]>; Tue, 31 Jul 2007 09:15:25 -0700 (MST) (envelope-from [e-mail])
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 46af5f51.1e24.1 for [e-mail]; Tue, 31 Jul 2007 17:12:01 +0100 (envelope-sender <[e-mail]>)
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 l6VGC0l6017763 for <[e-mail]>; Tue, 31 Jul 2007 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l6VGC0cL017760 for [e-mail]; Tue, 31 Jul 2007 17:12:00 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24729
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1416 Injection-Date: proposed diff
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Tue, 31 Jul 2007 11:38:40 GMT
Lines: 46
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>"Charles Lindsey" <[e-mail]> writes:

>> So our amateurish guy implements this by configuring that all bona-fide
>> Usenet groups are to be relayed/injected as the case may be, but
>> carefully omits the local.* groups from his list. And for months and
>> months that works fine, so the guy believe he is configured just fine.

>> Then, one day, someone elsewhere on the local network writes an article
>> crossposted to local.misc and comp.misc - well you can see what happens
>> then, and two versions of the article running around Usenet is one
>> possible outcome.

>So he still knows he's reinjecting (or not) and therefore his software
>still handles Injection-Date properly unless his software has been broken
>all along for comp.* as well.

No, he thinks he is just relaying an article to comp.misc.

Yes, if his software knows that a pre-existing Injection-Date is NEVER to
be removed or altered, then no harm will arise. And since that is a matter
for the software implementor rather than a matter locally configurable,
he is unlikely to make that mistake (unless he starts hacking the source
code).

Moreover, no existing implementation is going to remove that
Injection-Date, because no existing implementation is even aware that
header exists. So I think the rules as you have written cover all the
possibilities fine.

I have just checked my own 'sys' file, and indeed the problem cannot arise
with, for example, the man.* groups I mentioned, some of which I keep on
my machine. But I can also see how a 'sys' file could easily be
misconfigured so that it happened.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 l6UGX8PG025914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2007 09:33:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6UGX8Cw025913; Mon, 30 Jul 2007 09:33:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6UGX7jw025907 for <[e-mail]>; Mon, 30 Jul 2007 09:33:07 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3A4F34C8B7 for <[e-mail]>; Mon, 30 Jul 2007 09:33:07 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 6B7274C898 for <[e-mail]>; Mon, 30 Jul 2007 09:32:56 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 66202E8015; Mon, 30 Jul 2007 09:32:56 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Mon, 30 Jul 2007 11:54:31 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 30 Jul 2007 09:32:56 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <[e-mail]> writes:

> So our amateurish guy implements this by configuring that all bona-fide
> Usenet groups are to be relayed/injected as the case may be, but
> carefully omits the local.* groups from his list. And for months and
> months that works fine, so the guy believe he is configured just fine.

> Then, one day, someone elsewhere on the local network writes an article
> crossposted to local.misc and comp.misc - well you can see what happens
> then, and two versions of the article running around Usenet is one
> possible outcome.

So he still knows he's reinjecting (or not) and therefore his software
still handles Injection-Date properly unless his software has been broken
all along for comp.* as well.

I'm still not seeing your point.  He still always knows when he's
reinjecting and therefore has an opportunity to do the right thing by the
protocol.  I'm not arguing that things never leak; I know that they do.
Only that anyone who is doing reinjection *knows* they're doing
reinjection, even if they're confused over which articles they're
reinjecting.

-- 
Russ Allbery ([e-mail])             <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 l6UGC81s024060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2007 09:12:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6UGC866024058; Mon, 30 Jul 2007 09:12:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6UGC6le024045 for <[e-mail]>; Mon, 30 Jul 2007 09:12:07 -0700 (MST) (envelope-from [e-mail])
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 46ae0dd6.12894.9d for [e-mail]; Mon, 30 Jul 2007 17:12:06 +0100 (envelope-sender <[e-mail]>)
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 l6UGC2vq029138 for <[e-mail]>; Mon, 30 Jul 2007 17:12:02 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l6UGC1DM029135 for [e-mail]; Mon, 30 Jul 2007 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24727
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1416 Injection-Date: proposed diff
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Mon, 30 Jul 2007 11:56:03 GMT
Lines: 26
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>"Charles Lindsey" <[e-mail]> writes:

>> Yes, that is rather the point I was making. Russ has removed the term
>> "reinjection" from the draft and left us with the mouthful "multiple
>> injection after the fact". His wording is technically correct (with MUST
>> in all the right places), but maybe it could be reviewed.

>I'm okay with reintroducing the term.  I mostly took it out as part of
>incorporating Harald's way of viewing the situation, which I found
>clearer, but I may have gone too far that direction.

OK, let me encourage you to have a close look at that section with a view
to clarifying it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 l6UGC7Y2024052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2007 09:12:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6UGC7nt024051; Mon, 30 Jul 2007 09:12:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6UGC6L3024042 for <[e-mail]>; Mon, 30 Jul 2007 09:12:06 -0700 (MST) (envelope-from [e-mail])
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 46ae0dd5.17437.20 for [e-mail]; Mon, 30 Jul 2007 17:12:05 +0100 (envelope-sender <[e-mail]>)
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 l6UGC19x029130 for <[e-mail]>; Mon, 30 Jul 2007 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l6UGC12L029127 for [e-mail]; Mon, 30 Jul 2007 17:12:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24726
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1416 Injection-Date: proposed diff
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Mon, 30 Jul 2007 11:54:31 GMT
Lines: 51
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>"Charles Lindsey" <[e-mail]> writes:

>>> How could you not be aware that multiple injection is taking place?
>>> Some agent involved in the process clearly *does* know this unless the
>>> multiple injection is being done manually by a human, in which case the
>>> *human* knows this.  You're starting with an existing news article
>>> rather than with a blank screen and an editor; that's a pretty obvious
>>> difference.

>> Small local networks with more than one site tend to be run in an
>> amateurish fashion. So the second guy, who caused the extra "leak", may
>> have been badly configured, or ignorant, or both.

>Right, but either it's a normal relaying agent to relaying agent
>connection that leaks, or he knew he was reinjecting.  He may not know how
>to configure it properly.

Suppose the local network has some local.* groups which all participants
are instructed not to let leak to the outside Usenet.

So our amateurish guy implements this by configuring that all bona-fide
Usenet groups are to be relayed/injected as the case may be, but carefully
omits the local.* groups from his list. And for months and months that
works fine, so the guy believe he is configured just fine.

Then, one day, someone elsewhere on the local network writes an article
crossposted to local.misc and comp.misc - well you can see what happens
then, and two versions of the article running around Usenet is one
possible outcome.

{Just as an aside, there are actually two top level hierarchies on Usenet
known as "man.*. One is the University of Manchester, and the other is the
University of Manitoba. Both hierarchies have groups called
man.cs.general, and occasionally we used to see articles from the "wrong"
hierarchy for just that reason. I had some discussion with the Newsmaster
at Manitoba, and we agreed there was nothing much to be done about it, and
that such occasional insights into the "other" culture might even be
beneficial.}

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 l6U1qcsg043522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2007 18:52:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6U1qcwL043521; Sun, 29 Jul 2007 18:52:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6U1qZ1x043509 for <[e-mail]>; Sun, 29 Jul 2007 18:52:37 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 73C1E4BEEE for <[e-mail]>; Sun, 29 Jul 2007 18:52:33 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 3CF594BEAC for <[e-mail]>; Sun, 29 Jul 2007 18:52:33 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 39029E7CA6; Sun, 29 Jul 2007 18:52:33 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu, 26 Jul 2007 12:09:14 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 29 Jul 2007 18:52:33 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <[e-mail]> writes:
> Russ Allbery <[e-mail]> writes:

>> The language is written as it is because it's written from the
>> perspective of establishing a unique identity for the article and that
>> can't be done without the Message-ID header anyway.  Thinking of an
>> article with Injection-Date and not Message-ID is rather weird to me,
>> but I can't think of any specific *problems* it would cause.  It's
>> similar to an article with Date but no Message-ID today.

> Which is actually quite common. The injection agent creates the
> Message-ID (which is can probably do more reliably than poorly
> configured user agents, which have been known to create message-ids with
> "@localhost" in them).

Yeah, and the agent may want to allow for an injecting agent that doesn't
create Injection-Date.  Okay, that makes sense.

> Yes, I agree that Injection-Date without Date would be totally bizarre,
> but if it does no harm then there is no point in wording to forbid it,
> which means people just start wondering why you did so. So it is better
> to say

>    "Posting agents MAY, as part of the injection process
>    (i.e. immediately before passing that proto-article to an injection
>    agent), add an Injection-Date header field to that proto-article
>    (though it would be unusual to do so if Date and Message-ID fields
>    were not also being provided)."

> Generally speaking (especially if we say with option IR) we should be
> encouraging posting agents to take advantage of this new "MAY" feature,
> and unnecessary "small print" will just put them off.

That sounds fine to me.  I now have:

        <t>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 a Date header field
        (representing the composition time of the proto-article) is
        present in the proto-article and is more than a day in the past at
        the time of injection.  They MUST do so if the proto-article is
        being submitted to more than one injecting agent; see <xref
        target="multi-injection" />.</t>

I don't think we need to say that it's unusual, but I can add that if need
be.

>> How could you not be aware that multiple injection is taking place?
>> Some agent involved in the process clearly *does* know this unless the
>> multiple injection is being done manually by a human, in which case the
>> *human* knows this.  You're starting with an existing news article
>> rather than with a blank screen and an editor; that's a pretty obvious
>> difference.

> Small local networks with more than one site tend to be run in an
> amateurish fashion. So the second guy, who caused the extra "leak", may
> have been badly configured, or ignorant, or both.

Right, but either it's a normal relaying agent to relaying agent
connection that leaks, or he knew he was reinjecting.  He may not know how
to configure it properly.

> One of the benefits of encouraging the first guy to include an
> Injection-Date and forbidding anyone anywhere ever to remove it is that
> such leaks will do less harm.

This I do agree with.

> So the wording you have written in entirely correct, but I am not sure
> it is enforceable.

The person who takes an existing news message and reposts it is the person
who needs to take the necessary precautions, because they're the person
doing something outside of the regular Usenet protocol.  However, I do
agree that it makes sense to make the whole system more robust against
people who do that without knowing what they're doing.

>> Which makes it a proto-article.  I phrase it that way because I want to
>> be very clear that any constraints expressed in the Proto-articles
>> section apply to the resulting article.

> Yes, but are there any particular constraints you have in mind here,
> bearing in mind that your wording has already overridden the usual
> proto-article constraints of all (well nearly all) of the headers which
> are mentioned in the Proto-articles section?

I don't override them, just restate them (I think).  No, I don't have any
others in mind.

-- 
Russ Allbery ([e-mail])             <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 l6RGKQbK072068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jul 2007 09:20:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6RGKQ5A072067; Fri, 27 Jul 2007 09:20:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6RGKPGl072061 for <[e-mail]>; Fri, 27 Jul 2007 09:20:25 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D73AB4C0B1 for <[e-mail]>; Fri, 27 Jul 2007 09:20:22 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id C80164BF64 for <[e-mail]>; Fri, 27 Jul 2007 09:20:22 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id A8698E7A53; Fri, 27 Jul 2007 09:20:22 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Fri, 27 Jul 2007 13:34:46 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 27 Jul 2007 09:20:22 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <[e-mail]> writes:

> Yes, that is rather the point I was making. Russ has removed the term
> "reinjection" from the draft and left us with the mouthful "multiple
> injection after the fact". His wording is technically correct (with MUST
> in all the right places), but maybe it could be reviewed.

I'm okay with reintroducing the term.  I mostly took it out as part of
incorporating Harald's way of viewing the situation, which I found
clearer, but I may have gone too far that direction.

-- 
Russ Allbery ([e-mail])             <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 l6RGC7Gm071240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jul 2007 09:12:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6RGC75m071239; Fri, 27 Jul 2007 09:12:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6RGC5T3071226 for <[e-mail]>; Fri, 27 Jul 2007 09:12:06 -0700 (MST) (envelope-from [e-mail])
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 46aa1954.15967.46f for [e-mail]; Fri, 27 Jul 2007 17:12:04 +0100 (envelope-sender <[e-mail]>)
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 l6RGC17u019860 for <[e-mail]>; Fri, 27 Jul 2007 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l6RGC1Dm019857 for [e-mail]; Fri, 27 Jul 2007 17:12:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24723
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1416 Injection-Date: proposed diff
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 27 Jul 2007 13:34:46 GMT
Lines: 53
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> "Forrest J. Cavalier III" <[e-mail]> writes:

>Charles Lindsey wrote:
>>>>>+          <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 as offered
>>>>
>>>>                                                        ^^^^^^^
>>>>                                                        articles
>>>>
>>>>>+          to each injecting agent MUST be identical.</t>
>> 

>In the first it reads "SHOULD" be offering the same proto article.
>The second sentence says "proto-article as offered MUST be identical."

Yes, as Russ has said, that SHOULD is to discourage some more preculiar
ways of doing multiple injection.

For example, all my own articles are first injected to my own private news
server. Then they are relayed (using IHAVE) to a site that has agreed to
peer with me (but which is shambolically managed). Then, after a short
interval to allow it to propagate, I inject it again to a site with which
I do not have a peering arrangement using POST (well, I actually use IHAVE
because that site implements the INN option of allowing IHAVE to be used
for injection, but it is still an injection).

So I would technically be breaking that first SHOULD, and at some stage I
will have to consider whether to continue doing that, and what to do with
any Injection-Date header that I create.

There are also various other weird and wonderful ways that SHOULD might be
ignored - some of them quite sensible and some of them not.

>I personally, say MUST.  If you can't offer the same proto-article,
>then you are reposting, not multi-injecting.

Yes, that is rather the point I was making. Russ has removed the term
"reinjection" from the draft and left us with the mouthful "multiple
injection after the fact". His wording is technically correct (with MUST
in all the right places), but maybe it could be reviewed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 l6QGmUUi061811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 09:48:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6QGmUdZ061810; Thu, 26 Jul 2007 09:48:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6QGmSoR061803 for <[e-mail]>; Thu, 26 Jul 2007 09:48:29 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B2FC74C6E6 for <[e-mail]>; Thu, 26 Jul 2007 09:48:28 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id A20E84C28B for <[e-mail]>; Thu, 26 Jul 2007 09:48:28 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9B66BE7949; Thu, 26 Jul 2007 09:48:28 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Forrest J. Cavalier, III's message of "Thu, 26 Jul 2007 12:35:19 -0400")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 26 Jul 2007 09:48:28 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Forrest J. Cavalier III" <[e-mail]> writes:

> I think it should be reworded to avoid the clumsiness.

> In the first it reads "SHOULD" be offering the same proto article.
> The second sentence says "proto-article as offered MUST be identical."

> So which is it?  SHOULD or MUST?

It's talking about two different things.  The structure of the section
goes like:  You SHOULD use simultaneous injection of the same article
rather than transforming an already-injected article back to a
proto-article and injecting it again.  If you do use simultaneous
injection, here's how you MUST do it.  If you instead do the latter,
here's how you MUST do it.

Alternative wording suggestions welcome.

-- 
Russ Allbery ([e-mail])             <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 l6QGZLTc060492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 09:35:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6QGZLYJ060491; Thu, 26 Jul 2007 09:35:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l6QGZIlm060475 for <[e-mail]>; Thu, 26 Jul 2007 09:35:21 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 51113 invoked from network); 26 Jul 2007 16:35:17 -0000
Received: from 64.111.151.13 (HELO ?192.168.2.11?) (64.111.151.13) by relay02.pair.com with SMTP; 26 Jul 2007 16:35:17 -0000
X-pair-Authenticated: 64.111.151.13
Message-ID: <[e-mail]>
Date: Thu, 26 Jul 2007 12:35:19 -0400
From: "Forrest J. Cavalier III" <[e-mail]>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
References: <[e-mail]> 	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Charles Lindsey wrote:
>>>>+          <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 as offered
>>>
>>>                                                        ^^^^^^^
>>>                                                        articles
>>>
>>>>+          to each injecting agent MUST be identical.</t>
> 
> 
>>Intentionally not plural because they're identical and hence there is only
>>one proto-article.
> 
> 
> But two "offerings".
> 
> Hmmm! It just seems an odd piece of English to say "a single-object ...
> MUST be identical".

I think it should be reworded to avoid the clumsiness.

In the first it reads "SHOULD" be offering the same proto article.
The second sentence says "proto-article as offered MUST be identical."

So which is it?  SHOULD or MUST?

I personally, say MUST.  If you can't offer the same proto-article,
then you are reposting, not multi-injecting.




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 l6QGQBIn059249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 09:26:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6QGQBI0059248; Thu, 26 Jul 2007 09:26:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6QGQAJs059240 for <[e-mail]>; Thu, 26 Jul 2007 09:26:10 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 97FD94C7A2 for <[e-mail]>; Thu, 26 Jul 2007 09:26:09 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 87E114C76E for <[e-mail]>; Thu, 26 Jul 2007 09:26:09 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 83243E7949; Thu, 26 Jul 2007 09:26:09 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu, 26 Jul 2007 12:12:16 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 26 Jul 2007 09:26:09 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <[e-mail]> writes:

> Yes, the main point of my message was to set out the differences between
> options IR and IC, and the arguments in favour of each.

> If we can agree that I have stated the issues correctly, then Harald can
> proceed to a head count.

Other than the minor notes that I posted, it seemed correct to me.

-- 
Russ Allbery ([e-mail])             <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 l6QGC5R6058226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 09:12:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6QGC5KB058222; Thu, 26 Jul 2007 09:12:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6QGC37v058213 for <[e-mail]>; Thu, 26 Jul 2007 09:12:04 -0700 (MST) (envelope-from [e-mail])
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 46a8c7d2.ca52.35d for [e-mail]; Thu, 26 Jul 2007 17:12:02 +0100 (envelope-sender <[e-mail]>)
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 l6QGC1YJ006086 for <[e-mail]>; Thu, 26 Jul 2007 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l6QGC1GE006083 for [e-mail]; Thu, 26 Jul 2007 17:12:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24719
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1416 Injection-Date: proposed diff
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Thu, 26 Jul 2007 12:12:16 GMT
Lines: 22
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>Snipping the rest of this discussion since I think we're just repeating
>the same arguments in different words.  The other nits I'll get in the
>next post.

Yes, the main point of my message was to set out the differences between
options IR and IC, and the arguments in favour of each.

If we can agree that I have stated the issues correctly, then Harald can
proceed to a head count.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 l6QGC5HL058228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2007 09:12:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6QGC5Cn058227; Thu, 26 Jul 2007 09:12:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6QGC3S9058212 for <[e-mail]>; Thu, 26 Jul 2007 09:12:04 -0700 (MST) (envelope-from [e-mail])
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 46a8c7d1.4801.113 for [e-mail]; Thu, 26 Jul 2007 17:12:01 +0100 (envelope-sender <[e-mail]>)
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 l6QGC1OU006078 for <[e-mail]>; Thu, 26 Jul 2007 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l6QGC2b9006075 for [e-mail]; Thu, 26 Jul 2007 17:12:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24718
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1416 Injection-Date: proposed diff
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Thu, 26 Jul 2007 12:09:14 GMT
Lines: 194
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>"Charles Lindsey" <[e-mail]> writes:

>> In Duties of a Posting Agent:

>>>+        <t>If the proto-article already contains both Message-ID and Date
>>>+        header fields, posting agents MAY add an Injection-Date header
>>                                            ^
>>                        , as part of the injection process,
>>>+        field to that proto-article immediately before passing that
>>>+        proto-article to an injection agent.

>> That is where I don't see why they MAY add it only if both Message-ID and
>> Date are present (see "???" above). What harm arises, even in IR, if they
>> are allowed to add it anyway?

>The language is written as it is because it's written from the perspective
>of establishing a unique identity for the article and that can't be done
>without the Message-ID header anyway.  Thinking of an article with
>Injection-Date and not Message-ID is rather weird to me, but I can't think
>of any specific *problems* it would cause.  It's similar to an article
>with Date but no Message-ID today.

Which is actually quite common. The injection agent creates the Message-ID
(which is can probably do more reliably than poorly configured user
agents, which have been known to create message-ids with "@localhost" in
them).

>Adding Injection-Date when there's no Date header is just bizarre and
>strange, since it means that one is not trying to use the "time of
>composition" semantics of Date and it baffles me why they wouldn't just
>let the injecting agent add the headers.  Here I similarly can't put my
>finger on any harm, but even more so than the Message-ID case, it's a
>remarkably strange thing to do and I can't figure out why anyone would
>want to do that or what meaningful semantics it would express.

Yes, I agree that Injection-Date without Date would be totally bizarre,
but if it does no harm then there is no point in wording to forbid it,
which means people just start wondering why you did so. So it is better to
say

   "Posting agents MAY, as part of the injection process (i.e. immediately
   before passing that proto-article to an injection agent), add an
   Injection-Date header field to that proto-article (though it would be
   unusual to do so if Date and Message-ID fields were not also being
   provided)."

Generally speaking (especially if we say with option IR) we should be
encouraging posting agents to take advantage of this new "MAY" feature,
and unnecessary "small print" will just put them off.

Of course we all agree that it MUST be done in the case of multiple
injection.


>> In Multiple Injection of Articles:

>>>+          <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 as offered
>>                                                         ^^^^^^^
>>                                                         articles
>>>+          to each injecting agent MUST be identical.</t>

>Intentionally not plural because they're identical and hence there is only
>one proto-article.

But two "offerings".

Hmmm! It just seems an odd piece of English to say "a single-object ...
MUST be identical".



>>>+          <t>In some cases, offering the same proto-article to all
>>>+          injecting agents may not be possible (such as when gatewaying,
>>>+          after the fact, articles found on one Netnews network to
>>>+          another, supposedly 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.

>> Technically, that is what we used to call "reinjection". Now it is called
>> "Gatewaying after the fact", which is a bit of a mouthfull. Neither term
>> really indicates that the person/entity doing it may be completely unaware
>> that either multiple- or re-injection is taking place.

>How could you not be aware that multiple injection is taking place?  Some
>agent involved in the process clearly *does* know this unless the multiple
>injection is being done manually by a human, in which case the *human*
>knows this.  You're starting with an existing news article rather than
>with a blank screen and an editor; that's a pretty obvious difference.

Small local networks with more than one site tend to be run in an
amateurish fashion. So the second guy, who caused the extra "leak", may
have been badly configured, or ignorant, or both. One of the benefits of
encouraging the first guy to include an Injection-Date and forbidding
anyone anywhere ever to remove it is that such leaks will do less harm.

So the wording you have written in entirely correct, but I am not sure it
is enforceable.


>> Also, I am not sure that "converting it back into a proto-article" is
>> quite what is happening.  What is important is that any Message-ID, Date
>> and Injection-Date MUST stay, and any Xref and Injection-Info MUST go.

>Which makes it a proto-article.  I phrase it that way because I want to be
>very clear that any constraints expressed in the Proto-articles section
>apply to the resulting article.

Yes, but are there any particular constraints you have in mind here,
bearing in mind that your wording has already overridden the usual
proto-article constraints of all (well nearly all) of the headers which
are mentioned in the Proto-articles section?




>>>@@ -484,48 +571,73 @@
>>>           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" &lt;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"
>>>+          &lt;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>

>> I would prefer a "SHOULD NOT contain a "POSTED" &lt;diag-keyword>". No
>> interoperability arises if a "POSTED" appears twice in a Path, though it
>> may well be a cause for suspicion, and even for over-zealous agents to
>> reject it.

>I think SHOULD NOT is the worst thing we could say here; I think it should
>either be MUST NOT so that parsers can rely on one and only one POSTED
>diag, or we should remain quiet on it entirely and allow multiple POSTED
>diags and expect people to do the right thing.  SHOULD NOT leaves the
>matter ambiguous for everyone and seems like a breeding point for later
>arguments.

OK, I am happy with a weaker wording than "SHOULD", all the way down to no
wording at all.

>I'm leaning towards the latter, since otherwise we have to tell people to
>throw out trace information that could help catch loops.

>> Generally, I prefer to preserve all evidence from earlier Paths, for the
>> netkops to interpret as they will (whether or not this results in multiple
>> POSTEDs).

>Yup.

Then maybe a NOTE somewhere to the effect that multiple POSTEDs may
sometimes be seen and that they cause no harm but may serve as an
indication of some unusual behaviour or malpractice.


>Instead, I added this to the end sentence of that paragraph and now have:

>          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 accepts the article only once, even if
>          supposedly disjoint networks have unexpected links.</t>

OK.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 l6Q4OOrn096919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 21:24:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6Q4ONFJ096914; Wed, 25 Jul 2007 21:24:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.245.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6Q4OGJC096869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jul 2007 21:24:17 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-146.messagelabs.com!1185423855!4829282!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [144.160.20.53]
Received: (qmail 20049 invoked from network); 26 Jul 2007 04:24:15 -0000
Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-10.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 26 Jul 2007 04:24:15 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6Q4OFj6008227; Thu, 26 Jul 2007 00:24:15 -0400
Received: from mlph070.sfdc.sbc.com (mlph070.sfdc.sbc.com [144.155.224.139]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6Q4O7lr007737; Thu, 26 Jul 2007 00:24:13 -0400
Received: from sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6Q4O7q9023792; Thu, 26 Jul 2007 00:24:07 -0400
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6Q4O1IR023766; Thu, 26 Jul 2007 00:24:02 -0400
Received: from [135.210.96.137] (unknown[135.210.96.137](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070726042243gw10010gs8e> (Authid: tony); Thu, 26 Jul 2007 04:24:01 +0000
Message-ID: <[e-mail]>
Date: Thu, 26 Jul 2007 00:22:28 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: ietf-822 mailing list <[e-mail]>
CC: SMTP Interest Group <[e-mail]>, LEMONADE WG <[e-mail]>, IMAP extensions mailing list <[e-mail]>, EAI WG <[e-mail]>, POP3 extensions mailing list <[e-mail]>, USEFOR WG <[e-mail]>, SIMPLE WG <[e-mail]>
Subject: Mailing List Last Call for 2822 update internet-draft
X-Enigmail-Version: 0.95.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

There have been some comments on draft-resnick-2822upd-* but they have
dwindled down to none.

This is a "formal" Mailing List Last Call on
draft-resnick-2822upd-02.txt. The last call will last for two weeks
time, ending on August 10, 2007.

The document will be discussed on the 822 mailing list,
<[e-mail]>. Please send your comments there.

For a copy of the current draft, you can find it at

	http://www.ietf.org/internet-drafts/draft-resnick-2822upd-02.txt
or
	http://tools.ietf.org/html/draft-resnick-2822upd

Depending on the outcome of the Mailing List Last Call, the next step
will be to submit the document (or its revision) to the IESG for
IETF-wide Last Call.

Thanks!

	Tony Hansen
	[e-mail]



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 l6Q0AvBx084103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 17:10:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6Q0Avo7084102; Wed, 25 Jul 2007 17:10:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6Q0Aubp084095 for <[e-mail]>; Wed, 25 Jul 2007 17:10:57 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5BD864C588 for <[e-mail]>; Wed, 25 Jul 2007 17:10:56 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 48B084C47E for <[e-mail]>; Wed, 25 Jul 2007 17:10:56 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 407CAE80E9; Wed, 25 Jul 2007 17:10:56 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Harald Tveit Alvestrand's message of "Wed, 25 Jul 2007 19:07:12 -0500")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 25 Jul 2007 17:10:56 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Tveit Alvestrand <[e-mail]> writes:
> --On 25. juli 2007 15:32 -0700 Russ Allbery <[e-mail]> wrote:

>> How could you not be aware that multiple injection is taking place?  Some
>> agent involved in the process clearly *does* know this unless the multiple
>> injection is being done manually by a human, in which case the *human*
>> knows this.  You're starting with an existing news article rather than
>> with a blank screen and an editor; that's a pretty obvious difference.

> In the "gatewaying" case, the guy that does the second injection knows
> that multiple injection is taking place. The guy (process, human or
> exotic) doing the first injection may or may not know.

Oh.  Yes.  That I agree with.  That's why there shouldn't be any special
requirements placed on the first injector for this case.

-- 
Russ Allbery ([e-mail])             <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 l6Q08aIK083959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 17:08:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6Q08a1q083958; Wed, 25 Jul 2007 17:08:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6Q08ZZT083952 for <[e-mail]>; Wed, 25 Jul 2007 17:08:36 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9420259729; Thu, 26 Jul 2007 02:08:34 +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 17604-06; Thu, 26 Jul 2007 02:08:29 +0200 (CEST)
Received: from [172.28.172.61] (dhcp-149d.ietf69.org [130.129.20.157]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1631C25971E; Thu, 26 Jul 2007 02:08:28 +0200 (CEST)
Date: Wed, 25 Jul 2007 19:07:12 -0500
From: Harald Tveit Alvestrand <[e-mail]>
To: Russ Allbery <[e-mail]>, [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--On 25. juli 2007 15:32 -0700 Russ Allbery <[e-mail]> wrote:

>> Technically, that is what we used to call "reinjection". Now it is called
>> "Gatewaying after the fact", which is a bit of a mouthfull. Neither term
>> really indicates that the person/entity doing it may be completely
>> unaware that either multiple- or re-injection is taking place.
>
> How could you not be aware that multiple injection is taking place?  Some
> agent involved in the process clearly *does* know this unless the multiple
> injection is being done manually by a human, in which case the *human*
> knows this.  You're starting with an existing news article rather than
> with a blank screen and an editor; that's a pretty obvious difference.

In the "gatewaying" case, the guy that does the second injection knows that 
multiple injection is taking place. The guy (process, human or exotic) 
doing the first injection may or may not know.

                    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 l6PMWFj2074307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 15:32:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6PMWFoL074306; Wed, 25 Jul 2007 15:32:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6PMWEIk074298 for <[e-mail]>; Wed, 25 Jul 2007 15:32:15 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 888F44C18B for <[e-mail]>; Wed, 25 Jul 2007 15:32:14 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 05AA34C215 for <[e-mail]>; Wed, 25 Jul 2007 15:32:14 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 01DEEE7A6A; Wed, 25 Jul 2007 15:32:13 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Wed, 18 Jul 2007 15:04:18 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]>
Date: Wed, 25 Jul 2007 15:32:13 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <[e-mail]> writes:

> In Duties of a Posting Agent:

>>+        <t>If the proto-article already contains both Message-ID and Date
>>+        header fields, posting agents MAY add an Injection-Date header
>                                            ^
>                        , as part of the injection process,
>>+        field to that proto-article immediately before passing that
>>+        proto-article to an injection agent.

> That is where I don't see why they MAY add it only if both Message-ID and
> Date are present (see "???" above). What harm arises, even in IR, if they
> are allowed to add it anyway?

The language is written as it is because it's written from the perspective
of establishing a unique identity for the article and that can't be done
without the Message-ID header anyway.  Thinking of an article with
Injection-Date and not Message-ID is rather weird to me, but I can't think
of any specific *problems* it would cause.  It's similar to an article
with Date but no Message-ID today.

Adding Injection-Date when there's no Date header is just bizarre and
strange, since it means that one is not trying to use the "time of
composition" semantics of Date and it baffles me why they wouldn't just
let the injecting agent add the headers.  Here I similarly can't put my
finger on any harm, but even more so than the Message-ID case, it's a
remarkably strange thing to do and I can't figure out why anyone would
want to do that or what meaningful semantics it would express.

I guess I'm not sure the right thing to say here.

>>+        ...... 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 submitted to more than
>                       ^^
>               They MUST do so if
>>+        one injecting agent, see <xref target="multi-injection" />.</t>

> Yes, that last MUST is redundant, but the point is important and
> you have a similar redundancy when discussing proto-articles further on.

Agreed.  Changed in my draft.

> In Multiple Injection of Articles:

>>+          <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 as offered
>                                                         ^^^^^^^
>                                                         articles
>>+          to each injecting agent MUST be identical.</t>

Intentionally not plural because they're identical and hence there is only
one proto-article.

>>+          <t>In some cases, offering the same proto-article to all
>>+          injecting agents may not be possible (such as when gatewaying,
>>+          after the fact, articles found on one Netnews network to
>>+          another, supposedly 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.

> Technically, that is what we used to call "reinjection". Now it is called
> "Gatewaying after the fact", which is a bit of a mouthfull. Neither term
> really indicates that the person/entity doing it may be completely unaware
> that either multiple- or re-injection is taking place.

How could you not be aware that multiple injection is taking place?  Some
agent involved in the process clearly *does* know this unless the multiple
injection is being done manually by a human, in which case the *human*
knows this.  You're starting with an existing news article rather than
with a blank screen and an editor; that's a pretty obvious difference.

Whatever agent that is that knows this is going on is responsible for
doing the right thing in conjunction with the posting agent doing the
work.

> Also, I am not sure that "converting it back into a proto-article" is
> quite what is happening.  What is important is that any Message-ID, Date
> and Injection-Date MUST stay, and any Xref and Injection-Info MUST go.

Which makes it a proto-article.  I phrase it that way because I want to be
very clear that any constraints expressed in the Proto-articles section
apply to the resulting article.

> Also, it is not clear what is to happen to any Path. My preference would
> be to leave it (see discussion of this further down), or otherwise to
> rename it.

I agree that this isn't clear.  I think I'm convinced that we can drop the
restriction on POSTED keywords in Path in proto-articles, but I'd like
other members of the working group to weigh in on that.

>>@@ -452,6 +455,66 @@
>>         </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
>                                                    ^
>                                                   the

Changed.

>>+        multiple peers and each news server may be offered the same
>>+        article from multiple other news servers....
>>+
>>+          <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
>                                                           ^^^
>                                                          might

Changed.

>>+            article it had not yet seen, so it ought not be aggressively
>                                                           ^
>                                                           to
>>+            short....

I think this is an English style difference.  I believe the current text
is correct, and adding "to" seems less correct to me.

The wording is a little awkward, though, but the rephrasings occuring to
me are even more cumbersome.

>>+        <t>These are just two implementation strategies for article
>>+        history, albeit the most common ones.  Relaying and serving agents
>>+        are not required to use these strategies, only to meet the
>>+        requirement of not accepting an article more than once.  However,
>>+        these strategies are safe and widely deployed and implementors are
>>+        encouraged to use one of them, especially if they not have
>                                                            ^
>                                                            do

Changed (I think someone else had already caught that).

>>+        extensive experience with Netnews and the subtle effects of its
>                                                 ^^^
>                                             with the more
>>+        flood-fill algorithm.</t>

I don't see how that's an improvement.  The nouns joined with that
conjunction seem brief enough to me to not warrant repeating the
preposition.

>>@@ -459,9 +522,33 @@
>> 
>>+        applicable policies.  They MUST NOT create any Injection-Info
>>+        header field; this header field will be added by the injecting
>                                           ^^^^^^^
>                                        is only to be
>>+        agent.</t>

As much as I prefer to avoid using lowercase may, "may only" seems way
clearer here to me than either "will be" or "is only to be".  Changed
accordingly.

>>+        <t>The Injection-Date header field is new in this revision of the
>>+        Netnews protocol and is designed to allow the Date header field to
>>+        hold the composition date (as recommended in section 3.6.1 of
>>+        <xref target="RFC2822" />), even if the proto-article is not
>                                                                       ^
>                                                                     to be
>>+        injected for some time after its composition....

Changed.

>>@@ -484,48 +571,73 @@
>>           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" &lt;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"
>>+          &lt;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>

> I would prefer a "SHOULD NOT contain a "POSTED" &lt;diag-keyword>". No
> interoperability arises if a "POSTED" appears twice in a Path, though it
> may well be a cause for suspicion, and even for over-zealous agents to
> reject it.

I think SHOULD NOT is the worst thing we could say here; I think it should
either be MUST NOT so that parsers can rely on one and only one POSTED
diag, or we should remain quiet on it entirely and allow multiple POSTED
diags and expect people to do the right thing.  SHOULD NOT leaves the
matter ambiguous for everyone and seems like a breeding point for later
arguments.

I'm leaning towards the latter, since otherwise we have to tell people to
throw out trace information that could help catch loops.

> Generally, I prefer to preserve all evidence from earlier Paths, for the
> netkops to interpret as they will (whether or not this results in multiple
> POSTEDs).

Yup.

>>+        <section anchor="multi-injection"
>>+                 title="Multiple Injection of Articles">
>>+          <t>Under some circumstances (posting to multiple disjoint
>                                                             ^
>                                                         supposedly

Well, no, if the networks weren't disjoint, the posting agent wouldn't
need to offer the same article to multiple injecting agents.  This
parenthetical is talking about the motivations, not the problems.

Instead, I added this to the end sentence of that paragraph and now have:

          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 accepts the article only once, even if
          supposedly disjoint networks have unexpected links.</t>

>>+          <t>Multiple injection of an article listing one or more
>>+          moderated newsgroups in its Newsgroups header field SHOULD only
>                                                                 ^^^^^^^^^^^
>                                                                 SHOULD ONLY
>>+          be done by a moderator and MUST only be done after the
>                                        ^^^^^^^^^
>                                        MUST ONLY

SHOULD ONLY and MUST ONLY are not RFC 2119 keywords, and hence I don't
capitalize the only.

>>+          proto-article is approved for all moderated groups to which it
>                           ^^
>                       has been
>>+          is to be posted and has an Approved header field (see <xref
>>+          target="moderator" />)....

Changed.

>>+            <t>It MUST reject any article that has already been accepted.
>>+            If it implements the mechanism described in <xref
>                                ^^^^^^^^^^^^^
>                           one of the mechanisms
>>+            target="history" />, this means that it MUST reject any
>>+            article whose date falls outside the cutoff interval since it
>>+            won't know whether such articles had been accepted previously
>>+            or not.</t>

Changed in both places.

-- 
Russ Allbery ([e-mail])             <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 l6PM1niu065821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 15:01:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6PM1nfC065818; Wed, 25 Jul 2007 15:01:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6PM1mms065804 for <[e-mail]>; Wed, 25 Jul 2007 15:01:48 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ABDB64BF3E for <[e-mail]>; Wed, 25 Jul 2007 15:01:47 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 6B3D94C656 for <[e-mail]>; Wed, 25 Jul 2007 15:01:47 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6657BE7A72; Wed, 25 Jul 2007 15:01:47 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: proposed diff
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Wed, 18 Jul 2007 15:04:18 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]>
Date: Wed, 25 Jul 2007 15:01:47 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Trying to fix tab damage here.  Please don't use tabs for column alignment
because quoting throws off the alignment and changes the meaning of the
original message.

"Charles Lindsey" <[e-mail]> writes:

> Option IR
> ---------

> Adding Injection-Date by Posting agent, according to headers present in
> proto-article and intention wrt multiple injection:

>                                               MUST    MUSTNOT SHOULD  MAY
> Multiple injection (also requires Msgid & Date)YES
> "Reinjection" (aka "gatewaying after the fact")       YES
> Message-ID and stale Date present                             YES
> Message-ID _and_ Date present                                         YES
> Message-ID or Date or both absent                                     ???

> [Where I believe "???" should be "YES", but text doesn't actually say so]

The text was intended to only permit adding an Injection-Date header if
Message-ID and Date are both present.  The posting agent can either add
all three or omit Injection-Date; anything else would be rather bizarre.

The *ideal* case when no multiple injection is involved is for the posting
agent to not provide any of those headers and let the injecting agent take
care of it, since the headers added by the injecting agent are likely to
be of higher quality.  But that feels like USEAGE material to me.

Does this need to be further clarified in the proposed text?  I guess
nothing explicitly says to not add Injection-Date unless you're also
adding Message-ID and Date, even though the MAY phrasing strongly implies
it.  This is fallout from changing things around so that posting agents
can add it at all.

> Adding Injection-Date by Injecting agent, according to headers present in
> incoming proto-article:

>                                               MUST    MUSTNOT SHOULD  MAY
> Injection-Date already present                        YES
> Message-ID _and_ Date present                         YES
> Message-ID or Date or both absent             YES

Correct.

Snipping the rest of this discussion since I think we're just repeating
the same arguments in different words.  The other nits I'll get in the
next post.

-- 
Russ Allbery ([e-mail])             <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 l6PLcFmE058788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 14:38:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6PLcFsl058787; Wed, 25 Jul 2007 14:38:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6PLcEmU058772 for <[e-mail]>; Wed, 25 Jul 2007 14:38:14 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B3C9F4C87C for <[e-mail]>; Wed, 25 Jul 2007 14:38:13 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 9D86E4C7F3 for <[e-mail]>; Wed, 25 Jul 2007 14:38:13 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 98197E80BE; Wed, 25 Jul 2007 14:38:13 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: History section (Re: #1416 Injection-Date: proposed diff)
In-Reply-To: <[e-mail]> (Harald Alvestrand's message of "Tue, 17 Jul 2007 10:14:59 +0200")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]>
Date: Wed, 25 Jul 2007 14:38:13 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Harald Alvestrand <[e-mail]> writes:

> Speaking as a contributor:
> I like the text of the history section, and think that we should just
> declare it "text accepted".

That would make my life much easier.  I'd like us to just do that as
well.

>>          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>

> Nit: this doesn't seem to take a position on whether it's the same
> posting agent doing the multiple injection or different posting agents;
> I suggest adding ", by one or several posting agents" if this is what we
> think is intended.

That's the intention here.  I've changed my text accordingly.

>> +        encouraged to use one of them, especially if they not have

> nit: "not have" - > "do not have".

Fixed in my draft.

-- 
Russ Allbery ([e-mail])             <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 l6IGC7bq007293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2007 09:12:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6IGC77D007292; Wed, 18 Jul 2007 09:12:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6IGC4AH007284 for <[e-mail]>; Wed, 18 Jul 2007 09:12:06 -0700 (MST) (envelope-from [e-mail])
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 469e3bd3.14d4f.39a for [e-mail]; Wed, 18 Jul 2007 17:12:03 +0100 (envelope-sender <[e-mail]>)
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 l6IGC1Yb018711 for <[e-mail]>; Wed, 18 Jul 2007 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id l6IGC0Ys018708 for [e-mail]; Wed, 18 Jul 2007 17:12:00 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24711
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: #1416 Injection-Date: proposed diff
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Wed, 18 Jul 2007 15:04:18 GMT
Lines: 399
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <[e-mail]> Russ Allbery <[e-mail]> writes:

>It's been a while since we discussed this, so here again is my current
>proposed diff.  If there are parts of this we can agree on independently,
>I can start merging it into the main draft.

Yes, large chunks of this are fine, though I have a few nits (see later).

The main outstanding matter is Issue #1416, which I shall now try to
summarize as I see it.

Essentially, we have to choose between two options, which we have in the
past named "IR" and "IC". The current text reflects IR. The differences
relate to when an Injection-Date header MUST/MUST NOT/Whatever be added by
Posting and Injection agants.

Option IR
---------

Adding Injection-Date by Posting agent, according to headers present in
proto-article and intention wrt multiple injection:

						MUST	MUSTNOT	SHOULD	MAY
Multiple injection (also requires Msgid & Date)	YES
"Reinjection" (aka "gatewaying after the fact")		YES
Message-ID and stale Date present				YES
Message-ID _and_ Date present						YES
Message-ID or Date or both absent					???

[Where I believe "???" should be "YES", but text doesn't actually say so]

Adding Injection-Date by Injecting agent, according to headers present in
incoming proto-article:

						MUST	MUSTNOT	SHOULD	MAY
Injection-Date already present				YES
Message-ID _and_ Date present				YES
Message-ID or Date or both absent		YES

Option IC
---------

Adding Injection-Date by Posting agent, according to headers present in
proto-article and intention wrt multiple injection:

						MUST	MUSTNOT	SHOULD	MAY
Multiple injection (also requires Msgid & Date)	YES
"Reinjection" (aka "gatewaying after the fact")		YES
Message-ID and stale Date present				YES
All other cases (Message-ID or Date or neither)				YES

Adding Injection-Date by Injecting agent, according to headers present in
incoming proto-article:

						MUST	MUSTNOT	SHOULD	MAY
Injection-Date already present				YES
All other cases (Message-ID or Date or neither)	YES


Discussion of IR
----------------

The essential difference is the rule that Injecting agents MUST NOT add
Injection-Date if _both_ Message-ID and Date are already present, and MUST
add it otherwise. This rule is counter-intuitive and confusing.

A consequence of the rule is that it will forever remain the case that
some articles will never acquire an Injection-Date (those where the
Posting agent provides both of Message-ID and Date).

Russ counters this by claiming that, in time, Posting agents will learn to
add the Injection-Date themselves, but this is only a "MAY" as specified,
and I remain unconvinced that implementors will take the hint.

So if we decide to remain with Option IR, I would want to see a much
stronger wording in place of that "MAY" (not necessarily a "SHOULD", but
some indication that it was intended to become standard practice).

Moreover, there is a danger that Posting agent implementors will do it
wrongly, adding the Injection-Date _before_ they are sure they have a
working connection to an Injecting agent. Yes, multiple injectors have to
get this right, but people doing multiple injection can be expected to
have a higher level of "clue".

Discussion of IC
----------------

We distinguish between "OLD" agents which are unaware of our new standard,
and "NEW" agents which implement it as written.

The following scenario, which I understand to be the case Russ is worried
about, illustrates the problem with IC. If anyone knows of a different, or
a simpler, scenario that exhibits the same problem, then please speak up.

Day 0	OLD Posting agent P composes an article (with Date: Day0) and some
	Message-ID. P is in the habit of multi-injecting.
Day 1	P injects the message to (OLD or NEW) Injecting agent A (the ACopy).
Day 2	P injects the message to NEW Injecting agent B (the BCopy); B adds
	Injection-Date: Day2.
meanwhile:
Day 1	The ACopy propagates rapidly and arrives at NEW Serving agent C,
	which stores it and puts it in its history file (which it
	normally retains for 7 days).
Day 2	The BCopy arrives at Relaying agent D, which promptly breaks and goes
	offline for 7 days (or otherwise causes that propagation delay).
Day 8	C removes the ACopy from its history file.
Day 9	D wakes up, embarks on a massive catchup, and releases the BCopy.
Day 9	The BCopy arrives at C, which observes that it is (just) within 7
	days of its Injection-Date, and so accepts and stores it again.

	Which is, of course, a Bad Thing. C's users will say "Didn't I
	already see that article last week?" But it is no worse than that;
	in particular, I cannot see any way that looping could arise.

Observe that this Bad Thing would not have happened if:
	. B had been an OLD agent
	. C had been an OLD agent
	. P had been a NEW agent
	. The delay at D had been 1 day less
	. The delay at D had been 1 day more

So yes, the Bad Thing would not have happened on the current network, and
it will not happen when the whole network is NEW - so it is a transitional
problem whilst OLD and NEW agents are still around. Moreover, you might
think the whole scenario is somewhat artificial (hence the invitation to
propose more realistic scenarios).

So the choice you people have to make is between this possible, but rare,
Bad Thing, and the counter-intuitive properties of option IR.


The following are the paragraphs relating to this issue, and which would
need changing if we move to Opion IC. ALso a few nit-fixes in some of
them.

In Duties of a Posting Agent:

>+        <t>If the proto-article already contains both Message-ID and Date
>+        header fields, posting agents MAY add an Injection-Date header
                                           ^
                       , as part of the injection process,
>+        field to that proto-article immediately before passing that
>+        proto-article to an injection agent.

That is where I don't see why they MAY add it only if both Message-ID and
Date are present (see "???" above). What harm arises, even in IR, if they
are allowed to add it anyway?

>+        ...... 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 submitted to more than
                      ^^
              They MUST do so if
>+        one injecting agent, see <xref target="multi-injection" />.</t>

Yes, that last MUST is redundant, but the point is important and
you have a similar redundancy when discussing proto-articles further on.

In Multiple Injection of Articles:

>+          <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 as offered
                                                        ^^^^^^^
                                                        articles
>+          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 gatewaying,
>+          after the fact, articles found on one Netnews network to
>+          another, supposedly 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.

Technically, that is what we used to call "reinjection". Now it is called
"Gatewaying after the fact", which is a bit of a mouthfull. Neither term
really indicates that the person/entity doing it may be completely unaware
that either multiple- or re-injection is taking place. Also, I am not sure
that "converting it back into a proto-article" is quite what is happening.
What is important is that any Message-ID, Date and Injection-Date MUST
stay, and any Xref and Injection-Info MUST go.

Also, it is not clear what is to happen to any Path. My preference would
be to leave it (see discussion of this further down), or otherwise to
rename it.

In Duties of an Injecting Agent:

>+            <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>

In Duties of a Relaying Agent:

>             <t>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.</t>
>+
>+            <t>It MUST reject any article that has already been accepted.
>+            If it implements the mechanism described in <xref
>+            target="history" />, this means that it MUST reject any
>+            article whose date falls outside the cutoff interval since it
>+            won't know whether such articles had been accepted previously
>+            or not.</t>


Those are the texts relevant to the IR/IC issue. Here now are my remaining
nits - mostly typos or minor wording suggestions, although there is a
smallish issue related to POSTED in the Path header.



>@@ -452,6 +455,66 @@
>         </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
                                                   ^
                                                  the
>+        multiple peers and each news server may be offered the same
>+        article from multiple other news servers....
>+
>+          <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
                                                          ^^^
                                                         might
>+            article it had not yet seen, so it ought not be aggressively
                                                          ^
                                                          to
>+            short....

>+        <t>These are just two implementation strategies for article
>+        history, albeit the most common ones.  Relaying and serving agents
>+        are not required to use these strategies, only to meet the
>+        requirement of not accepting an article more than once.  However,
>+        these strategies are safe and widely deployed and implementors are
>+        encouraged to use one of them, especially if they not have
                                                           ^
                                                           do
>+        extensive experience with Netnews and the subtle effects of its
                                                ^^^
                                            with the more
>+        flood-fill algorithm.</t>

>@@ -459,9 +522,33 @@
> 
>+        applicable policies.  They MUST NOT create any Injection-Info
>+        header field; this header field will be added by the injecting
                                          ^^^^^^^
                                       is only to be
>+        agent.</t>
>+
>+        <t>The Injection-Date header field is new in this revision of the
>+        Netnews protocol and is designed to allow the Date header field to
>+        hold the composition date (as recommended in section 3.6.1 of
>+        <xref target="RFC2822" />), even if the proto-article is not
                                                                      ^
                                                                    to be
>+        injected for some time after its composition....

>@@ -484,48 +571,73 @@
>           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" &lt;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"
>+          &lt;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>

I would prefer a "SHOULD NOT contain a "POSTED" &lt;diag-keyword>". No
interoperability arises if a "POSTED" appears twice in a Path, though it
may well be a cause for suspicion, and even for over-zealous agents to
reject it.

It can arise in the following circumstances:

1. As a result of "reinjecting " (aka "gatewaying after the fact").
2. In some forms of multiple injection, notably when one of the
"injections" is technically a relaying, using IHAVE. Such multiple
injection would indeed violate one of your SHOULDs, but SHOULD violations
are going to happen from time to time (and sometimes for good reason).
3. When some s[pc]ammer has preloaded the Path in order to disguise the
true origin of the article (indeed, this was one of the original purposes
for inventing POSTED). A pretty stupid s[pc]ammer, or course (competent
ones will just post from alt.net :-) ).

Generally, I prefer to preserve all evidence from earlier Paths, for the
netkops to interpret as they will (whether or not this results in multiple
POSTEDs). Alternatively, I might be persuaded that we should recommend
renaming earlier Paths, as we do for pre-existing Injection-Infos.

>           <t>If a posting agent intends to offer the same proto-article to
>+          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>


That is the place I mentioned earlier where you already have a redundant
MUST for Injection-Date. Fine, it helps make things clearer.

>+        <section anchor="multi-injection"
>+                 title="Multiple Injection of Articles">
>+          <t>Under some circumstances (posting to multiple disjoint
                                                            ^
                                                        supposedly
>+          networks, injecting agents with spotty connectivity, or for
>+          redundancy, for example), a posting agent may wish to offer the
>+          same article to multiple injecting agents. ....

>+          <t>Multiple injection of an article listing one or more
>+          moderated newsgroups in its Newsgroups header field SHOULD only
                                                                ^^^^^^^^^^^
                                                                SHOULD ONLY
>+          be done by a moderator and MUST only be done after the
                                       ^^^^^^^^^
                                       MUST ONLY
>+          proto-article is approved for all moderated groups to which it
                          ^^
                      has been
>+          is to be posted and has an Approved header field (see <xref
>+          target="moderator" />)....

>@@ -650,23 +762,27 @@
> 
>             <t>It MUST reject any proto-article that does not have the
>+            Injection-Info or Xref header fields; that has a Path header
>+            field containing the "POSTED" &lt;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 (see, for example, <xref
>+            target="RFC3798" />).  It MAY reject any proto-article that
>+            contains trace header fields (e.g., NNTP-Posting-Host)
>+            indicating that it was already injected by an injecting agent
>+            that did not add Injection-Info or Injection-Date.</t>

I would prefer POSTED to be in the "SHOULD reject"s, for reasons already
stated above.
>+
>+            ...  It SHOULD similarly
>+            reject any article whose Date header field is too far in the
>+            past, since not all news servers support Injection-Date and
>+            only the injecting agent can provide a useful error message to
>+            the posting agent.  In either case, this interval SHOULD NOT
>+            be any shorter than 72 hours into the past.</t>

That SHOULD is better than the MUST that was present in earlier drafts. I
would still be happier with a MAY.
 
>@@ -806,18 +928,18 @@

>+            <t>It MUST reject any article that has already been accepted.
>+            If it implements the mechanism described in <xref
                               ^^^^^^^^^^^^^
                          one of the mechanisms
>+            target="history" />, this means that it MUST reject any
>+            article whose date falls outside the cutoff interval since it
>+            won't know whether such articles had been accepted previously
>+            or not.</t>

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone] Fax: [phone]   Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 l6H8FCiM059523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jul 2007 01:15:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6H8FCjj059522; Tue, 17 Jul 2007 01:15:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6H8FAtB059512 for <[e-mail]>; Tue, 17 Jul 2007 01:15:11 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 780C02596E4; Tue, 17 Jul 2007 10:15:09 +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 20618-04; Tue, 17 Jul 2007 10:14:59 +0200 (CEST)
Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B55012596E2; Tue, 17 Jul 2007 10:14:59 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 17 Jul 2007 10:14:59 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Russ Allbery <[e-mail]>
Cc: [e-mail]
Subject: History section (Re: #1416 Injection-Date: proposed diff)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

I'll take this by section, since I'm not in a position to comment on the 
whole block in one go...

Speaking as a contributor:
I like the text of the history section, and think that we should just 
declare it "text accepted".

Russ Allbery wrote:
> It's been a while since we discussed this, so here again is my current
> proposed diff.  If there are parts of this we can agree on independently,
> I can start merging it into the main draft.
>
> --- usepro.xml	2007-07-01 19:38:06.000000000 -0700
> +++ usepro-1416.xml	2007-07-16 13:43:23.000000000 -0700
> @@ -18,6 +18,8 @@
>      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
>    <!ENTITY rfc3629 PUBLIC '' 
>      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
> +  <!ENTITY rfc3798 PUBLIC '' 
> +    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3798.xml'>
>    <!ENTITY rfc3977 PUBLIC '' 
>      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3977.xml'>
>    <!ENTITY rfc4234 PUBLIC '' 
> @@ -165,8 +167,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>
>   
Nit: this doesn't seem to take a position on whether it's the same 
posting agent doing the multiple injection or different posting agents; 
I suggest adding ", by one or several posting agents" if this is what we 
think is intended.
>  
>          <t>A "gateway" is software which receives news articles and
>          converts them to messages of some other kind (such as <xref
> @@ -452,6 +455,66 @@
>          </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>Alternatively, agents MAY drop history records according to
> +            the date when the article was first seen by that agent rather
> +            than the date of the article.  In this case, the history
> +            retention interval MUST be at least 24 hours longer than the
> +            cutoff interval to allow for articles dated in the future.
> +            This interval matches the allowable error in the date of the
> +            article (see <xref target="injecting" />).</t>
> +          </list>
> +        </t>
> +
> +        <t>These are just two implementation strategies for article
> +        history, albeit the most common ones.  Relaying and serving agents
> +        are not required to use these strategies, only to meet the
> +        requirement of not accepting an article more than once.  However,
> +        these strategies are safe and widely deployed and implementors are
> +        encouraged to use one of them, especially if they not have
>   
nit: "not have" - > "do not have".
> +        extensive experience with Netnews and the subtle effects of its
> +        flood-fill algorithm.</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
>   



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 l6GKjb9i007860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 13:45:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6GKjbPn007859; Mon, 16 Jul 2007 13:45:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6GKjauW007853 for <[e-mail]>; Mon, 16 Jul 2007 13:45:37 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 636794C711 for <[e-mail]>; Mon, 16 Jul 2007 13:45:36 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 10E5B4C2E8 for <[e-mail]>; Mon, 16 Jul 2007 13:45:36 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 06FA8E796E; Mon, 16 Jul 2007 13:45:36 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: #1416 Injection-Date: proposed diff
Organization: The Eyrie
Date: Mon, 16 Jul 2007 13:45:35 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

It's been a while since we discussed this, so here again is my current
proposed diff.  If there are parts of this we can agree on independently,
I can start merging it into the main draft.

--- usepro.xml	2007-07-01 19:38:06.000000000 -0700
+++ usepro-1416.xml	2007-07-16 13:43:23.000000000 -0700
@@ -18,6 +18,8 @@
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
   <!ENTITY rfc3629 PUBLIC '' 
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
+  <!ENTITY rfc3798 PUBLIC '' 
+    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3798.xml'>
   <!ENTITY rfc3977 PUBLIC '' 
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3977.xml'>
   <!ENTITY rfc4234 PUBLIC '' 
@@ -165,8 +167,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
@@ -452,6 +455,66 @@
         </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>Alternatively, agents MAY drop history records according to
+            the date when the article was first seen by that agent rather
+            than the date of the article.  In this case, the history
+            retention interval MUST be at least 24 hours longer than the
+            cutoff interval to allow for articles dated in the future.
+            This interval matches the allowable error in the date of the
+            article (see <xref target="injecting" />).</t>
+          </list>
+        </t>
+
+        <t>These are just two implementation strategies for article
+        history, albeit the most common ones.  Relaying and serving agents
+        are not required to use these strategies, only to meet the
+        requirement of not accepting an article more than once.  However,
+        these strategies are safe and widely deployed and implementors are
+        encouraged to use one of them, especially if they not have
+        extensive experience with Netnews and the subtle effects of its
+        flood-fill algorithm.</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
@@ -459,9 +522,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 any Injection-Info
+        header field; this header field will be added by the injecting
+        agent.</t>
+
+        <t>If the proto-article already 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 submitted 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 allow the Date header field to
+        hold the composition date (as recommended 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 hence may
+        suffer poorer propagation.</t>
 
         <t>Contrary to <xref target="RFC2822" />, which implies that the
         mailbox or mailboxes in the From header field should be that of
@@ -484,48 +571,73 @@
           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" &lt;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"
+          &lt;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 for
+          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 accepts the
+          article only 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 as 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 gatewaying,
+          after the fact, articles found on one Netnews network to
+          another, supposedly 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.
+            <list style="empty">
+              <t>NOTE: 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,
+              unintended repeat injection into the same network, and other
+              problems.  It 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>
+            </list>
+          </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 to be posted and has an Approved header field (see <xref
+          target="moderator" />).  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">
@@ -650,23 +762,27 @@
 
             <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"
-            &lt;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>
+            Injection-Info or Xref header fields; that has a Path header
+            field containing the "POSTED" &lt;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 (see, for example, <xref
+            target="RFC3798" />).  It MAY reject any proto-article that
+            contains trace header fields (e.g., NNTP-Posting-Host)
+            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 Injection-Date or 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 Injection-Date header field is too far in the
+            past (older than the cutoff interval of a relaying agent the
+            injecting agent is using, for example).  It SHOULD similarly
+            reject any article whose Date header field is too far in the
+            past, since not all news servers support Injection-Date and
+            only the injecting agent can provide a useful error message to
+            the posting agent.  In either case, 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 &lt;newsgroup-name> for a
@@ -710,8 +826,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
@@ -806,18 +928,18 @@
             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 accepted.
+            If it implements the mechanism described in <xref
+            target="history" />, this means that it MUST reject any
+            article whose date falls outside the cutoff interval since it
+            won't know whether such articles had been accepted previously
+            or not.</t>
 
             <t>It SHOULD reject any article that does not include all the
             mandatory header fields.  It MAY reject any article that
@@ -891,16 +1013,16 @@
 
             <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>
-
-            <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>
+            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 accepted.
+            If it implements the mechanism described in <xref
+            target="history" />, this means that it MUST reject any
+            article whose date falls outside the cutoff interval since it
+            won't know whether such articles had been accepted previously
+            or not.</t>
 
             <t>It SHOULD reject any article that matches an
             already-received and honored cancel message or Supersedes
@@ -1008,8 +1130,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"
@@ -2042,6 +2163,7 @@
       &rfc1036;
       &rfc2045;
       &rfc2606;
+      &rfc3798;
       &rfc3977;
       <reference anchor="USEAGE">
         <front>

-- 
Russ Allbery ([e-mail])             <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 l6GKfw24007463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 13:41:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6GKfwAJ007462; Mon, 16 Jul 2007 13:41:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6GKfviZ007454 for <[e-mail]>; Mon, 16 Jul 2007 13:41:58 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 72B444C8F0 for <[e-mail]>; Mon, 16 Jul 2007 13:41:57 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 629D64C969 for <[e-mail]>; Mon, 16 Jul 2007 13:41:57 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 5D1FDE78F8; Mon, 16 Jul 2007 13:41:57 -0700 (PDT)
From: Russ Allbery <[e-mail]>
To: [e-mail]
Subject: Re: #1416 Injection-Date: current wording proposal (corrected)
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu, 24 May 2007 08:25:23 GMT")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <F3E75088ECDF5254BDE1A152@B50854F0A9192E8EC6CDA126> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 16 Jul 2007 13:41:57 -0700
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

"Charles Lindsey" <[e-mail]> writes:
> Russ Allbery <[e-mail]> writes:

>>I now have:

>>            <t>It MUST reject any article that has already been accepted.
>>            If it implements the mechanism described in <xref
>>            target="history" />, this means that it MUST reject any
>>            article whose date falls outside a cutoff interval since it
>                                               ^
>                                              the
>>            won't know whether such articles had been accepted or not.</t>
>                                                                ^
>                                                          earlier/previously

Change made in my version.

-- 
Russ Allbery ([e-mail])             <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 l6GKSEYP006152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 13:28:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l6GKSEMo006151; Mon, 16 Jul 2007 13:28:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l6GKSDc5006143 for <[e-mail]>; Mon, 16 Jul 2007 13:28:13 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F39372596F9 for <[e-mail]>; Mon, 16 Jul 2007 22:28:12 +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 30021-04 for <[e-mail]>; Mon, 16 Jul 2007 22:28:07 +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 62EED2596F7 for <[e-mail]>; Mon, 16 Jul 2007 22:28:07 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Mon, 16 Jul 2007 22:28:07 +0200
From: Harald Alvestrand <[e-mail]>
User-Agent: Thunderbird 1.5.0.7 (X11/20060921)
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: I-D ACTION:draft-ietf-usefor-usepro-08.txt]
Content-Type: multipart/mixed; boundary="------------090503090101070906090609"
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

This is a multi-part message in MIME format.
--------------090503090101070906090609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This draft has been published.

Barring further debate, I'm closing all issues where text was proposed 
in -08.
I'll send out an updated issues list later.

             Harald

--------------090503090101070906090609
Content-Type: message/rfc822;
 name="I-D ACTION:draft-ietf-usefor-usepro-08.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-ietf-usefor-usepro-08.txt"

Return-Path: <[e-mail]>
Received: from murder ([unix socket])
	 by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA;
	 Wed, 04 Jul 2007 01:15:47 +0200
X-Sieve: CMU Sieve 2.2
Received: from localhost (eikenes.alvestrand.no [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 088CC2596EF
	for <[e-mail]>; Wed,  4 Jul 2007 01:15: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 07672-07 for <[e-mail]>;
 Wed,  4 Jul 2007 01:15:39 +0200 (CEST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.6.7
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227])
	by eikenes.alvestrand.no (Postfix) with ESMTP id 92F052596F0
	for <[e-mail]>; Wed,  4 Jul 2007 01:15:38 +0200 (CEST)
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 l63NF55Q042179
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jul 2007 16:15:05 -0700 (MST)
	(envelope-from [e-mail])
Received: (from majordom@localhost)
	by balder-227.proper.com (8.13.5/8.13.5/Submit) id l63NF5VG042178;
	Tue, 3 Jul 2007 16:15:05 -0700 (MST)
	(envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138])
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l63NF2tU042168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <[e-mail]>; Tue, 3 Jul 2007 16:15:05 -0700 (MST)
	(envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10])
	by ns3.neustar.com (Postfix) with ESMTP id 3B1611762D;
	Tue,  3 Jul 2007 23:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1I5raH-0000yL-No; Tue, 03 Jul 2007 19:15:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-usefor-usepro-08.txt 
Message-Id: <[e-mail]>
Date: Tue, 03 Jul 2007 19:15:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>
X-Virus-Scanned: by amavisd-new at alvestrand.no


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: Netnews Architecture and Protocols
	Author(s)	: R. Allbery, C. Lindsey
	Filename	: draft-ietf-usefor-usepro-08.txt
	Pages		: 49
	Date		: 2007-7-3
	
This document defines the architecture of Netnews systems and
   specifies the correct manipulation and interpretation of Netnews
   articles by software which originates, distributes, stores, and
   displays them.  It also specifies the requirements that must be met
   by any protocol used to transport and serve Netnews articles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-usefor-usepro-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usepro-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usepro-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-usefor-usepro-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



--------------090503090101070906090609--



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 l63NF55Q042179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jul 2007 16:15:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l63NF5VG042178; Tue, 3 Jul 2007 16:15:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l63NF2tU042168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 3 Jul 2007 16:15:05 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3B1611762D; Tue,  3 Jul 2007 23:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5raH-0000yL-No; Tue, 03 Jul 2007 19:15:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-usefor-usepro-08.txt 
Message-Id: <[e-mail]>
Date: Tue, 03 Jul 2007 19:15:01 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: Netnews Architecture and Protocols
	Author(s)	: R. Allbery, C. Lindsey
	Filename	: draft-ietf-usefor-usepro-08.txt
	Pages		: 49
	Date		: 2007-7-3
	
This document defines the architecture of Netnews systems and
   specifies the correct manipulation and interpretation of Netnews
   articles by software which originates, distributes, stores, and
   displays them.  It also specifies the requirements that must be met
   by any protocol used to transport and serve Netnews articles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usepro-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-usefor-usepro-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usepro-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usepro-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-usefor-usepro-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--



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 l622cIUJ088167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jul 2007 19:38:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l622cImf088166; Sun, 1 Jul 2007 19:38:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l622cGZZ088158 for <[e-mail]>; Sun, 1 Jul 2007 19:38:18 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A7BB34C2D3 for <[e-mail]>; Sun,  1 Jul 2007 19:38:15 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 999F34C197 for <[e-mail]>; Sun,  1 Jul 2007 19:38:15 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 8453DE793F; Sun,  1 Jul 2007 19:38:15 -0700 (PDT)
To: [e-mail]
From: [e-mail]
Subject: Commit in docs/usefor (usepro.xml)
User-Agent: svnlog/1.14
Message-Id: <[e-mail]>
Date: Sun,  1 Jul 2007 19:38:15 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

    Date: Sunday, July 1, 2007 @ 19:38:14
  Author: eagle
Revision: 3041

Update date of the draft.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2007-07-02 02:36:42 UTC (rev 3040)
+++ docs/usefor/usepro.xml	2007-07-02 02:38:14 UTC (rev 3041)
@@ -62,7 +62,7 @@
       </address>
     </author>
 
-    <date month="January" year="2007" />
+    <date month="July" year="2007" />
 
     <area>Applications</area>
     <workgroup>Usenet Format Working Group</workgroup>



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 l622Zk0l088067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jul 2007 19:35:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l622ZkoR088066; Sun, 1 Jul 2007 19:35:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 l622ZjsJ088055 for <[e-mail]>; Sun, 1 Jul 2007 19:35:46 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4360E4C062 for <[e-mail]>; Sun,  1 Jul 2007 19:35:37 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 344DF4C061 for <[e-mail]>; Sun,  1 Jul 2007 19:35:37 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 11F86E793F; Sun,  1 Jul 2007 19:35:37 -0700 (PDT)
To: [e-mail]
From: [e-mail]
Subject: Commit in docs/usefor (usepro.xml)
User-Agent: svnlog/1.14
Message-Id: <[e-mail]>
Date: Sun,  1 Jul 2007 19:35:37 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

    Date: Sunday, July 1, 2007 @ 19:35:34
  Author: eagle
Revision: 3038

Update I-D file name.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2007-07-01 19:27:55 UTC (rev 3037)
+++ docs/usefor/usepro.xml	2007-07-02 02:35:34 UTC (rev 3038)
@@ -26,7 +26,7 @@
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml'>
 ]>
 
-<rfc ipr="full3978" docName="draft-ietf-usefor-usepro-07" obsoletes="1036"
+<rfc ipr="full3978" docName="draft-ietf-usefor-usepro-08" obsoletes="1036"
      category="std">
   <front>
     <title>Netnews Architecture and Protocols</title>