Subject: Great Finds

From: <[email-masked]>
Date: Sat, 28 Feb 2009 17:51:00 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.buylowly.com, click on "My Account",
click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.

Or unsubscribe at
http://buylowly.com/faq.php

Privacy Statement |
Terms & Conditions |
Contact

KEYWORD Ltd.

Tower Bridge Business Complex. Unit 0, B930. 495 Clements Road. London. SE40 6DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1GCCU68018540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 05:12:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GCCUfN018539; Mon, 16 Feb 2009 05:12:30 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-4.gradwell.net (v-smtp-auth-relay-4.gradwell.net [79.135.125.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1GCCI7d018510 for ; Mon, 16 Feb 2009 05:12:29 -0700 (MST) (envelope-from [email-masked])
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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 49995821.2947.562 for [email-masked]; Mon, 16 Feb 2009 12:12:17 +0000 (envelope-sender )
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 n1GCC3Hn007866 for ; Mon, 16 Feb 2009 12:12:03 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id n1GCC2d5007863 for [email-masked]; Mon, 16 Feb 2009 12:12:02 GMT
To: [email-masked]
Xref: clerew local.usefor:24997
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: ISSUE 1583 status
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 16 Feb 2009 10:57:20 GMT
Lines: 29
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Harald Alvestrand writes:

>Charles Lindsey wrote:
>> A touch too strong for my liking. Perhaps "... and report for human
>> evaluation any subsequent checkgroups control message for the same
>> hierarchy or sub-hierarchy with a smaller <chksernr> value or with no
>> <chksernr> value.".
>>
>> But even that seems to suggest that valid chechgroups should be accepted
>> on "auto-pilot", which is probably not a good idea.
>>
>> But I am not pressing this too strongly if others are happy.
>>
>So far, Russ and I are happy, and the rest of the list are silent, so
>you're a minority. Let's finish this one.

As I said, I do not press this issue strongly, so let it be. I see Ruus
has now comitted it to his working text.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] 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.14.2/8.14.2) with ESMTP id n1E9mST4018578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Feb 2009 02:48:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1E9mSNt018577; Sat, 14 Feb 2009 02:48:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from denver.dinauz.org (dinauz.org [91.121.67.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1E9mGRx018569 for ; Sat, 14 Feb 2009 02:48:27 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 52D69604 for ; Sat, 14 Feb 2009 10:48:15 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at dinauz.org
Received: from denver.dinauz.org ([127.0.0.1]) by localhost (dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMu8I-zmbQqd for ; Sat, 14 Feb 2009 10:48:15 +0100 (CET)
Received: from Iulius (AAubervilliers-151-1-10-54.w83-114.abo.wanadoo.fr [83.114.9.54]) by denver.dinauz.org (Postfix) with ESMTPSA id 0DDBE3C0 for ; Sat, 14 Feb 2009 10:48:15 +0100 (CET)
Message-ID: <467D5E20BBD14A5B97449A29C5D1C311@Iulius>
From: =?iso-8859-1?Q?Julien_=C9LIE?=
To:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Re: ISSUE 1583 status
Date: Sat, 14 Feb 2009 10:47:59 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Russ,

> How does this patch look to everyone?

It sounds great to me. Clear and precise. Thanks!

--
Julien ÉLIE

« La vraie paresse, c'est de se lever ŕ 6 heures du matin pour
avoir plus longtemps ŕ ne rien faire. » (Tristan Bernard)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1DMhsd7099157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2009 15:43:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1DMhsgx099156; Fri, 13 Feb 2009 15:43:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp5.stanford.edu (smtp5.Stanford.EDU [171.67.219.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1DMhrCI099150 for ; Fri, 13 Feb 2009 15:43:53 -0700 (MST) (envelope-from [email-masked])
Received: from smtp5.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EEB8C3B69F3 for ; Fri, 13 Feb 2009 14:43:52 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp5.stanford.edu (Postfix) with ESMTP id CD3D43B69C7 for ; Fri, 13 Feb 2009 14:43:52 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id AB7D3E8648; Fri, 13 Feb 2009 14:43:52 -0800 (PST)
To:
Subject: Re: ISSUE 1583 status
In-Reply-To: ("Julien =?iso-8859-1?Q?=C9LIE=22's?= message of "Fri\, 13 Feb 2009 18\:31\:38 +0100")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: Russ Allbery
Organization: The Eyrie
Date: Fri, 13 Feb 2009 14:43:52 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Julien =C9LIE writes:

> Shouldn't we add that serials should be compared as a string and not as
> a number owing to their not being limited in size? A note to future
> implementors would be useful. I also wonder whether we should not
> change (or add?) the current example
>
> - Control: checkgroups de !de.alt #248
> + Control: checkgroups de !de.alt #2009021301
>
> to show a preferred way to use serial numbers. It would be convenient
> for checkgroups senders not not worry much about the previous number
> used.

How does this patch look to everyone?

Index: usepro.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- usepro.xml (revision 5725)
+++ usepro.xml (working copy)
@@ -1962,19 +1962,28 @@
or sub-hierarchy with a smaller <chksernr> value or with no
<chksernr> value.
=20
+ There is no upper limit on the length of <chksernr>
+ other than the limitation on the length of header fields.
+ Implementations may therefore want to do comparisons by
+ zero-padding the shorter of two <chksernr> values on the
+ left and then doing a string comparison rather than assuming
+ <chksernr> can be manipulated as a number.
+

For example, the following Control header
field
=20

- Control: checkgroups de !de.alt #248
+ Control: checkgroups de !de.alt #2009021301

=20
indicates the body of the message will list every
newsgroup in the de.* hierarchy, excepting the de.alt.*
sub-hierarchy, and should not be honored if a checkgroups
- control message with a serial number greater than 248 was
- previously honored.
+ control message with a serial number greater than 2009021301
+ was previously honored. The serial number in this example
+ was formed from the date in YYYYMMDD format followed by a
+ two-digit sequence number within that date.

=20
The body of the message is an entity of type

--=20
Russ Allbery ([email-masked])

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1DKqMgP095219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2009 13:52:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1DKqMb1095218; Fri, 13 Feb 2009 13:52:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp5.stanford.edu (smtp5.Stanford.EDU [171.67.219.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1DKqBDw095211 for ; Fri, 13 Feb 2009 13:52:21 -0700 (MST) (envelope-from [email-masked])
Received: from smtp5.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3B0B93B6777 for ; Fri, 13 Feb 2009 12:52:11 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp5.stanford.edu (Postfix) with ESMTP id 1D1833B67E3 for ; Fri, 13 Feb 2009 12:52:10 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id E2E9B583E7; Fri, 13 Feb 2009 12:52:10 -0800 (PST)
To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
User-Agent: svnlog/1.14
Message-Id: <[email-masked]>
Date: Fri, 13 Feb 2009 12:52:10 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Date: Friday, February 13, 2009 @ 12:52:09
Author: eagle
Revision: 5725

Apply fix for 1583: specify behavior when a serial number was included
and then is left off a subsequent checkgroups and require that, once
serial numbers begin to be used, they continue to be used.

Modified:
docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml 2009-02-13 19:19:53 UTC (rev 5724)
+++ docs/usefor/usepro.xml 2009-02-13 20:52:09 UTC (rev 5725)
@@ -1953,12 +1953,14 @@

The <chksernr> argument may be any positive integer. If
present, it MUST increase with every change to the newsgroup
- list and MUST NOT ever decrease. If provided, news servers
- SHOULD remember the <chksernr> value of the previous
- checkgroups control message honored for a particular hierarchy
- or sub-hierarchy and decline to honor any subsequent checkgroups
- control message for the same hierarchy or sub-hierarchy with a
- smaller <chksernr> value.
+ list, MUST NOT ever decrease, and MUST be included in all
+ subsequent checkgroups control messages with the same scope.
+ If provided, news servers SHOULD remember the <chksernr>
+ value of the previous checkgroups control message honored for a
+ particular hierarchy or sub-hierarchy and decline to honor any
+ subsequent checkgroups control message for the same hierarchy
+ or sub-hierarchy with a smaller <chksernr> value or with no
+ <chksernr> value.

For example, the following Control header

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1DHW66u087638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2009 10:32:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1DHW6x9087637; Fri, 13 Feb 2009 10:32:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from denver.dinauz.org (dinauz.org [91.121.67.5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1DHVtAw087623 for ; Fri, 13 Feb 2009 10:32:06 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by denver.dinauz.org (Postfix) with ESMTP id 750E62169 for ; Fri, 13 Feb 2009 18:31:53 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at dinauz.org
Received: from denver.dinauz.org ([127.0.0.1]) by localhost (dinauz.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldgyze2RPKJk for ; Fri, 13 Feb 2009 18:31:53 +0100 (CET)
Received: from Iulius (AAubervilliers-151-1-10-54.w83-114.abo.wanadoo.fr [83.114.9.54]) by denver.dinauz.org (Postfix) with ESMTPSA id E8A4B1FCC for ; Fri, 13 Feb 2009 18:31:52 +0100 (CET)
Message-ID:
From: =?iso-8859-1?Q?Julien_=C9LIE?=
To:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Re: ISSUE 1583 status
Date: Fri, 13 Feb 2009 18:31:38 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Harald,

> So far, Russ and I are happy, and the rest of the list are silent, so you're a minority. Let's finish this one.

I also agree with that change (always including serial numbers once a
checkgroups has used them).
Shouldn't we add that serials should be compared as a string and not
as a number owing to their not being limited in size? A note to future
implementors would be useful.
I also wonder whether we should not change (or add?) the current example

- Control: checkgroups de !de.alt #248
+ Control: checkgroups de !de.alt #2009021301

to show a preferred way to use serial numbers. It would be convenient
for checkgroups senders not not worry much about the previous number used.

--
Julien ÉLIE

« J'aime le travail, je passerais des heures ŕ le regarder. »

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1DGj67c085057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2009 09:45:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1DGj6n0085056; Fri, 13 Feb 2009 09:45:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1DGj4Gr085050 for ; Fri, 13 Feb 2009 09:45:04 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDEFD39E394; Fri, 13 Feb 2009 17:45:03 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
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 IoAm4-7hrjfl; Fri, 13 Feb 2009 17:45:03 +0100 (CET)
Received: from [192.168.1.198] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 45E4739E2C0; Fri, 13 Feb 2009 17:45:03 +0100 (CET)
Message-ID: <[email-masked]>
Date: Fri, 13 Feb 2009 17:45:02 +0100
From: Harald Alvestrand
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Charles Lindsey
CC: [email-masked]
Subject: Re: ISSUE 1583 status
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Charles Lindsey wrote:
> In <[email-masked]> Russ Allbery writes:
>
>
>> The <chksernr> argument may be any positive integer. If
>> present, it MUST increase with every change to the newsgroup
>> - list and MUST NOT ever decrease. If provided, news servers
>> - SHOULD remember the <chksernr> value of the previous
>> - checkgroups control message honored for a particular hierarchy
>> - or sub-hierarchy and decline to honor any subsequent checkgroups
>> - control message for the same hierarchy or sub-hierarchy with a
>> - smaller <chksernr> value.
>> + list, MUST NOT ever decrease, and MUST be included in all
>> + subsequent checkgroups control messages with the same scope.
>> + If provided, news servers SHOULD remember the <chksernr>
>> + value of the previous checkgroups control message honored for a
>> + particular hierarchy or sub-hierarchy and decline to honor any
>> + subsequent checkgroups control message for the same hierarchy
>> + or sub-hierarchy with a smaller <chksernr> value or with no
>> + <chksernr> value.
>>
>
> A touch too strong for my liking. Perhaps "... and report for human
> evaluation any subsequent checkgroups control message for the same
> hierarchy or sub-hierarchy with a smaller <chksernr> value or with no
> <chksernr> value.".
>
> But even that seems to suggest that valid chechgroups should be accepted
> on "auto-pilot", which is probably not a good idea.
>
> But I am not pressing this too strongly if others are happy.
>
So far, Russ and I are happy, and the rest of the list are silent, so
you're a minority. Let's finish this one.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n14CCYF1077705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2009 05:12:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n14CCYXv077704; Wed, 4 Feb 2009 05:12:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-4.gradwell.net (v-smtp-auth-relay-4.gradwell.net [79.135.125.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n14CCND3077674 for ; Wed, 4 Feb 2009 05:12:34 -0700 (MST) (envelope-from [email-masked])
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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 49898621.1b7c.1f4 for [email-masked]; Wed, 4 Feb 2009 12:12:17 +0000 (envelope-sender )
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 n14CC8wv021035 for ; Wed, 4 Feb 2009 12:12:09 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id n14CC8xZ021032 for [email-masked]; Wed, 4 Feb 2009 12:12:08 GMT
To: [email-masked]
Xref: clerew local.usefor:24990
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: [1586] Multiple POSTED in Path: header
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <[email-masked]>
Date: Wed, 4 Feb 2009 10:47:39 GMT
Lines: 44
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Harald Alvestrand writes:

>Charles Lindsey wrote:
>>
>> NOTE: Whereas the presence of two "POSTED" s will often
>> indicate a malicious attempt to disguise the true origin of an article,
>> it could also arise following some ususual gatewaying or injecting
>> scenario (taking advantage of the "MAY contain" above), in which case
>> it could be useful for detecting unintended loops or mismanaged
>> gateways. The whole intent of these > humans in assessing unusual situations, and it would be unwise for
>> subsequent agents automatically to assume one possibility or the other.
>>

>I disagree with this idea, and think we should keep the SHOULD NOT.

>Not throwing away information can be accomplished by tricks like
>Old-Path:. As the proposed note effectively says, saying that multiple
>POSTs are generally acceptable is an invitation to the script kiddies to
>play with it.

If the script kiddies try it, they will get caught out because two POSTEDs
will then be present and any suspicion of trollery will be confirmed.

But in the case of some carefully crafted Gatewaying scheme, or, worse, in
the case of some broken Gatewaying scheme that ought to be spotted,
destroying the evidence will do harm. And I doubt people will want to
bother with Old-Post hacks.

There are plenty of Netkops around who will gleefully denounce the trolls,
and plenty of experienced newsadmins who will notice indications of broken
Gatewaying (especially if consistently repeated) and quietly warn those
causing it.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] 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.14.2/8.14.2) with ESMTP id n14CCLPY077665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2009 05:12:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n14CCLEL077664; Wed, 4 Feb 2009 05:12:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-2.gradwell.net (v-smtp-auth-relay-2.gradwell.net [79.135.125.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n14CCIip077634 for ; Wed, 4 Feb 2009 05:12:20 -0700 (MST) (envelope-from [email-masked])
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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 49898623.b55.2c7 for [email-masked]; Wed, 4 Feb 2009 12:12:19 +0000 (envelope-sender )
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 n14CC9UV021043 for ; Wed, 4 Feb 2009 12:12:09 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id n14CC9sC021040 for [email-masked]; Wed, 4 Feb 2009 12:12:09 GMT
To: [email-masked]
Xref: clerew local.usefor:24991
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: ISSUE 1583 status
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 4 Feb 2009 11:02:56 GMT
Lines: 40
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Russ Allbery writes:

>
> The <chksernr> argument may be any positive integer. If
> present, it MUST increase with every change to the newsgroup
>- list and MUST NOT ever decrease. If provided, news servers
>- SHOULD remember the <chksernr> value of the previous
>- checkgroups control message honored for a particular hierarchy
>- or sub-hierarchy and decline to honor any subsequent checkgroups
>- control message for the same hierarchy or sub-hierarchy with a
>- smaller <chksernr> value.
>+ list, MUST NOT ever decrease, and MUST be included in all
>+ subsequent checkgroups control messages with the same scope.
>+ If provided, news servers SHOULD remember the <chksernr>
>+ value of the previous checkgroups control message honored for a
>+ particular hierarchy or sub-hierarchy and decline to honor any
>+ subsequent checkgroups control message for the same hierarchy
>+ or sub-hierarchy with a smaller <chksernr> value or with no
>+ <chksernr> value.

A touch too strong for my liking. Perhaps "... and report for human
evaluation any subsequent checkgroups control message for the same
hierarchy or sub-hierarchy with a smaller <chksernr> value or with no
<chksernr> value.".

But even that seems to suggest that valid chechgroups should be accepted
on "auto-pilot", which is probably not a good idea.

But I am not pressing this too strongly if others are happy.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] 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.14.2/8.14.2) with ESMTP id n14CCLKc077663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2009 05:12:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n14CCLwZ077662; Wed, 4 Feb 2009 05:12:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-2.gradwell.net (v-smtp-auth-relay-2.gradwell.net [79.135.125.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n14CC9rQ077617 for ; Wed, 4 Feb 2009 05:12:20 -0700 (MST) (envelope-from [email-masked])
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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4989861a.7e92.33a for [email-masked]; Wed, 4 Feb 2009 12:12:10 +0000 (envelope-sender )
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 n14CC8DJ021027 for ; Wed, 4 Feb 2009 12:12:08 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id n14CC2Ir021018 for [email-masked]; Wed, 4 Feb 2009 12:12:02 GMT
To: [email-masked]
Xref: clerew local.usefor:24989
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: [1586] Multiple POSTED in Path: header
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <[email-masked]> <[email-masked]>
Date: Wed, 4 Feb 2009 10:38:14 GMT
Lines: 42
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Russ Allbery writes:

>"Charles Lindsey" writes:

>If you include Xref in an NNTP POST to an INN server, the article will be
>rejected. That's why I made it a MUST; the protocol does actually break
>in practice if you don't strip Xref. (Whether it *should* is a separate
>question, of course, but there's a huge installed base that behaves that
>way.)

You surprise me. I had always assumed that Xref was only meaningful for a
particular server and the clients that used it, and that if ever it
received an already-present Xref (from whatever source) it would simply
discard it and substitute its own. But if it is as you say, then I suppose
that MUST has to remain (otherwise, SHOULD would have sufficed).

>>> 1. Treat the Path header as special and permit (or even encourage)
>>> retaining it while not permitting retention of the other trace headers,
>>> on the grounds that it has an intrinsic ordering and therefore isn't as
>>> prone to confusion as having multiple trace headers that aren't
>>> ordered.

>> Yes, I think I like that.

>If we want to move forward with this, I think I could use some help
>analyzing what needs to change in the document to make it consistent again
>with this new approach.

Sure. If we agree on the effects we want to achieve, then I am due for a
careful read through the whole document to see what final inconsistencies
might be lurking there,

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] 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.14.2/8.14.2) with ESMTP id n142k8T4053143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 19:46:09 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n142k85x053142; Tue, 3 Feb 2009 19:46:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n142jw9m053134 for ; Tue, 3 Feb 2009 19:46:08 -0700 (MST) (envelope-from [email-masked])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C5BEB51CD06 for ; Tue, 3 Feb 2009 18:45:57 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp2.stanford.edu (Postfix) with ESMTP id 9FC0451C7AD for ; Tue, 3 Feb 2009 18:45:57 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 4F217E80B4; Tue, 3 Feb 2009 18:45:57 -0800 (PST)
To: [email-masked]
Subject: Re: ISSUE 1583 status
In-Reply-To: <[email-masked]> (Harald Alvestrand's message of "Tue\, 03 Feb 2009 13\:21\:18 +0100")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
From: Russ Allbery
Organization: The Eyrie
Date: Tue, 03 Feb 2009 18:45:57 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Harald Alvestrand writes:
> Russ Allbery wrote:

>> Here's proposed wording, which uses SHOULD rather than MUST for the
>> honoring side to leave wiggle room for things like a lost serial
>> number.
>>
>> --- usepro.xml (revision 5620)
>> +++ usepro.xml (working copy)
>> @@ -1953,12 +1953,14 @@
>> The <chksernr> argument may be any positive integer.
>> If
>> present, it MUST increase with every change to the newsgroup
>> - list and MUST NOT ever decrease. If provided, news servers
>> - SHOULD remember the <chksernr> value of the previous
>> - checkgroups control message honored for a particular hierarchy
>> - or sub-hierarchy and decline to honor any subsequent checkgroups
>> - control message for the same hierarchy or sub-hierarchy with a
>> - smaller <chksernr> value.
>> + list, MUST NOT ever decrease, and MUST be included in all
>> + subsequent checkgroups control messages with the same scope.
>> + If provided, news servers SHOULD remember the <chksernr>
>> + value of the previous checkgroups control message honored for a
>> + particular hierarchy or sub-hierarchy and decline to honor any
>> + subsequent checkgroups control message for the same hierarchy
>> + or sub-hierarchy with a smaller <chksernr> value or with no
>> + <chksernr> value.
>>
>> For example, the following Control header

> I'm not very worried about this issue, but this seems fine with me.
> (couldn't find the change to the text surrounding the SHOULD, but I
> think the SHOULD leaves wiggle room enough for the case where weird
> stuff has happened.)

Does anyone have any objections? If not, I'll go ahead and commit this.

--
Russ Allbery ([email-masked])

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13CRrMF011730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 05:27:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13CRrpT011729; Tue, 3 Feb 2009 05:27:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13CRq8l011723 for ; Tue, 3 Feb 2009 05:27:53 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3ECBD39E3F1; Tue, 3 Feb 2009 13:27:52 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
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 c6o4ucdV8A0Y; Tue, 3 Feb 2009 13:27:51 +0100 (CET)
Received: from hta-warp.trd.corp.google.com (unknown [195.18.164.170]) by eikenes.alvestrand.no (Postfix) with ESMTPS id D3E9739E26D; Tue, 3 Feb 2009 13:27:51 +0100 (CET)
Message-ID: <[email-masked]>
Date: Tue, 03 Feb 2009 13:27:51 +0100
From: Harald Alvestrand
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Charles Lindsey
CC: [email-masked]
Subject: Re: [1586] Multiple POSTED in Path: header
References:
In-Reply-To:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Charles Lindsey wrote:
> 3.4.1 of the present draft contains:
>
> A proto-article has the same format as a normal article except that
> the Injection-Info and Xref header fields MUST NOT be present; the
> Path header field SHOULD NOT contain a "POSTED" ; 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.
>
> That "SHOULD NOT" was formerly "MUST NOT", so it is an improvement.
>
> But I propose changing it to:
>
> .. the Path header field MAY contain a "POSTED" ; ...
>
> and adding a NOTE such as the following:
>
> NOTE: Whereas the presence of two "POSTED" s will often
> indicate a malicious attempt to disguise the true origin of an article,
> it could also arise following some ususual gatewaying or injecting
> scenario (taking advantage of the "MAY contain" above), in which case
> it could be useful for detecting unintended loops or mismanaged
> gateways. The whole intent of these humans in assessing unusual situations, and it would be unwise for
> subsequent agents automatically to assume one possibility or the other.
>
> Essentially, I am arguing for not throwing away any information which might
> be of subsequent diagnostic use, possibly at the expense of making people
> think a bit before accusing posters of trollery. It is up to the "netkops"
> to deal with these issues, and our draft should not try to prejudge their
> efforts.
>

I disagree with this idea, and think we should keep the SHOULD NOT.

Not throwing away information can be accomplished by tricks like
Old-Path:. As the proposed note effectively says, saying that multiple
POSTs are generally acceptable is an invitation to the script kiddies to
play with it.

Harald

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13CLWQL011389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 05:21:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13CLW6r011388; Tue, 3 Feb 2009 05:21:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13CLKWr011377 for ; Tue, 3 Feb 2009 05:21:31 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A05D239E3F1; Tue, 3 Feb 2009 13:21:19 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
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 nTHuXYX5nC3q; Tue, 3 Feb 2009 13:21:19 +0100 (CET)
Received: from hta-warp.trd.corp.google.com (unknown [195.18.164.170]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3D65139E26D; Tue, 3 Feb 2009 13:21:19 +0100 (CET)
Message-ID: <[email-masked]>
Date: Tue, 03 Feb 2009 13:21:18 +0100
From: Harald Alvestrand
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Russ Allbery
CC: [email-masked]
Subject: Re: ISSUE 1583 status
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Russ Allbery wrote:
> Here's proposed wording, which uses SHOULD rather than MUST for the
> honoring side to leave wiggle room for things like a lost serial number.
>
> --- usepro.xml (revision 5620)
> +++ usepro.xml (working copy)
> @@ -1953,12 +1953,14 @@
>
> The <chksernr> argument may be any positive integer. If
> present, it MUST increase with every change to the newsgroup
> - list and MUST NOT ever decrease. If provided, news servers
> - SHOULD remember the <chksernr> value of the previous
> - checkgroups control message honored for a particular hierarchy
> - or sub-hierarchy and decline to honor any subsequent checkgroups
> - control message for the same hierarchy or sub-hierarchy with a
> - smaller <chksernr> value.
> + list, MUST NOT ever decrease, and MUST be included in all
> + subsequent checkgroups control messages with the same scope.
> + If provided, news servers SHOULD remember the <chksernr>
> + value of the previous checkgroups control message honored for a
> + particular hierarchy or sub-hierarchy and decline to honor any
> + subsequent checkgroups control message for the same hierarchy
> + or sub-hierarchy with a smaller <chksernr> value or with no
> + <chksernr> value.
>
>
> For example, the following Control header
>
>
I'm not very worried about this issue, but this seems fine with me.
(couldn't find the change to the text surrounding the SHOULD, but I
think the SHOULD leaves wiggle room enough for the case where weird
stuff has happened.)

Harald

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n132kjmu085186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 19:46:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n132kjZt085185; Mon, 2 Feb 2009 19:46:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n132kY5B085176 for ; Mon, 2 Feb 2009 19:46:44 -0700 (MST) (envelope-from [email-masked])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E5B1451C581 for ; Mon, 2 Feb 2009 18:46:33 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp2.stanford.edu (Postfix) with ESMTP id C019E51C56C for ; Mon, 2 Feb 2009 18:46:33 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 80B34E7BB2; Mon, 2 Feb 2009 18:46:33 -0800 (PST)
To: [email-masked]
Subject: Re: [1586] Multiple POSTED in Path: header
In-Reply-To: (Charles Lindsey's message of "Mon\, 2 Feb 2009 12\:25\:55 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[email-masked]>
From: Russ Allbery
Organization: The Eyrie
Date: Mon, 02 Feb 2009 18:46:33 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

"Charles Lindsey" writes:
> Russ Allbery writes:

>> Since multiple injection is the only means by which multiple POSTED
>> can arise with their intended meaning and purpose, it
>> seems pointless to relax the requirement too far in one area and not in
>> the other.

> Agreed. I think that MUST is a bit too strong as regards the Path
> header. Indeed, it violates 2119 insofar as the protocol does not
> actually break if is it not done - same for Xref for that matter, so it
> is more a matter of what constitutes Good Practice.

If you include Xref in an NNTP POST to an INN server, the article will be
rejected. That's why I made it a MUST; the protocol does actually break
in practice if you don't strip Xref. (Whether it *should* is a separate
question, of course, but there's a huge installed base that behaves that
way.)

I agree that current servers do not reject posts that contain a POSTED
.

>> I think our options here are:
>
>> 1. Treat the Path header as special and permit (or even encourage)
>> retaining it while not permitting retention of the other trace headers,
>> on the grounds that it has an intrinsic ordering and therefore isn't as
>> prone to confusion as having multiple trace headers that aren't
>> ordered.

> Yes, I think I like that.

If we want to move forward with this, I think I could use some help
analyzing what needs to change in the document to make it consistent again
with this new approach.

--
Russ Allbery ([email-masked])

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12IWvaw060862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 11:32:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12IWv1K060861; Mon, 2 Feb 2009 11:32:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-2.gradwell.net (v-smtp-auth-relay-2.gradwell.net [79.135.125.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12IWjw1060848 for ; Mon, 2 Feb 2009 11:32:56 -0700 (MST) (envelope-from [email-masked])
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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 49872961.abb.365 for [email-masked]; Mon, 2 Feb 2009 17:12:01 +0000 (envelope-sender )
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 n12HC2H1000761 for ; Mon, 2 Feb 2009 17:12:02 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id n12HC2GS000758 for [email-masked]; Mon, 2 Feb 2009 17:12:02 GMT
To: [email-masked]
Xref: clerew local.usefor:24983
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: [1586] Multiple POSTED in Path: header
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <[email-masked]>
Date: Mon, 2 Feb 2009 12:25:55 GMT
Lines: 114
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Russ Allbery writes:

>"Charles Lindsey" writes:

>> 3.4.1 of the present draft contains:
>>
>> A proto-article has the same format as a normal article except that the
>> Injection-Info and Xref header fields MUST NOT be present; the Path
>> header field SHOULD NOT contain a "POSTED" ; 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.
>>
>> That "SHOULD NOT" was formerly "MUST NOT", so it is an improvement.
>>
>> But I propose changing it to:
>>
>> .. the Path header field MAY contain a "POSTED" ; ...

>Since that is equivalent to saying nothing about the POSTED
>, were we to decide on this change, I think I would omit the
>sentence entirely and just add the note (with corresponding minor wording
>changes). Or even better, move the NOTE to a subsection of 3.2 that
>explains the meaning of a POSTED keyword and the circumstances under which
>a Path header could be constructed containing several of them.

Sure.

>> and adding a NOTE such as the following:
>>
>> NOTE: Whereas the presence of two "POSTED" s will often
>> indicate a malicious attempt to disguise the true origin of an article,
>> it could also arise following some ususual gatewaying or injecting
>> scenario (taking advantage of the "MAY contain" above), in which case
>> it could be useful for detecting unintended loops or mismanaged
>> gateways. The whole intent of these > humans in assessing unusual situations, and it would be unwise for
>> subsequent agents automatically to assume one possibility or the other.
>>
>> Essentially, I am arguing for not throwing away any information which might
>> be of subsequent diagnostic use, possibly at the expense of making people
>> think a bit before accusing posters of trollery. It is up to the "netkops"
>> to deal with these issues, and our draft should not try to prejudge their
>> efforts.

>The corresponding text in 3.4.2 is:

> In some cases, offering the same proto-article to all injecting
> agents may not be possible (such as when gatewaying, after injection,
> articles found on one Netnews network to another supposedly-
> unconnected one). In this case, the posting agent MUST remove any
> Xref header field and rename or remove any Injection-Info, Path, and
> other trace header field before passing it to another injecting
> agent. (This converts the article back into a proto-article.)

>Since multiple injection is the only means by which multiple POSTED
> can arise with their intended meaning and purpose, it
>seems pointless to relax the requirement too far in one area and not in
>the other.

Agreed. I think that MUST is a bit too strong as regards the Path header.
Indeed, it violates 2119 insofar as the protocol does not actually break
if is it not done - same for Xref for that matter, so it is more a matter
of what constitutes Good Practice. But failing to remove/rename
Injection-Info and other tracers would be a more serious matter, because
it would then be telling an untruth, so the MUST is indeed needed there.

>I think our options here are:

>1. Treat the Path header as special and permit (or even encourage)
> retaining it while not permitting retention of the other trace headers,
> on the grounds that it has an intrinsic ordering and therefore isn't as
> prone to confusion as having multiple trace headers that aren't
> ordered.

Yes, I think I like that.

>2. Leave the existing wording, which requires multiple injection to remove
> or rename the Path header but allows readers to add spurious POSTED
> s by violating a SHOULD. I'm not entirely comfortable
> with it, but I can't think of any specific protocol harm it could
> cause.

>3. Restore the MUST in the proto-article section to match the MUST in
> 3.4.2 and make the document consistent but possibly too strict.

That would be to increase violation of 2119, which is why we demoted it
before.

>4. Relax the MUST generally in 3.4.2, but then we will run into issues
> with Injection-Info, which the posting agent is not permitted to supply
> and which doesn't have an intrinsic ordering the way that the Path
> header does.

That seems to agree with my remark concerning Injection-Info above, so I
think we agree that bit remains a MUST.

>The more I think about it, the more option 1 seems like a workable idea,
>but I think that's reversing some decisions that we made some time back.
>That makes me nervous at this stage of the process.

+1

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] 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.14.2/8.14.2) with ESMTP id n12HEgU5056687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 10:14:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12HEgoJ056686; Mon, 2 Feb 2009 10:14:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12HEVdp056671 for ; Mon, 2 Feb 2009 10:14:41 -0700 (MST) (envelope-from [email-masked])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1B71151C581 for ; Mon, 2 Feb 2009 09:14:31 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp2.stanford.edu (Postfix) with ESMTP id BCEF251C604 for ; Mon, 2 Feb 2009 09:14:30 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6F62CEA133; Mon, 2 Feb 2009 09:14:30 -0800 (PST)
To: [email-masked]
Subject: Re: ISSUE 1583 status
In-Reply-To: (Charles Lindsey's message of "Mon\, 2 Feb 2009 12\:11\:38 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[email-masked]> <[email-masked]>
From: Russ Allbery
Organization: The Eyrie
Date: Mon, 02 Feb 2009 09:14:30 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

"Charles Lindsey" writes:
> Russ Allbery writes:

>> The third issue is about what to do when a serial number is specified
>> for a hierarchy and then a subsequent control message arrives without a
>> serial number. The current document is silent on what to do in this
>> situation. I think it should state what should be done. My sense of
>> the previous discussion was that most people felt that such a
>> checkgroups should be ignored, meaning that once an authorized control
>> message sender starts issuing checkgroups with serial numbers,
>> subsequent checkgroups for that hierarchy must always use serial
>> numbers, which must always be larger than the previous serial number.
>> I'm a little worried about this provision, since after long periods of
>> time and a change of hierarchy administration it can be potentially
>> difficult to uncover the previous serial number. But I don't see a
>> good alternative that preserves the serial number semantics.

> I am slightly worried about being too specific here, for the reason you
> mention. Perhaps some wording to the effect that newsadmins should think
> carefully before accepting such a checkgroups (and in any case, blind
> automatic acceptance of checkgroups has never been a recommended
> practice). I wouldn't want to say anything stronger than that, and would
> be happy to leave it as it stands.

> So by all means suggest a wording if you like, or else let it be.

Here's proposed wording, which uses SHOULD rather than MUST for the
honoring side to leave wiggle room for things like a lost serial number.

--- usepro.xml (revision 5620)
+++ usepro.xml (working copy)
@@ -1953,12 +1953,14 @@

The <chksernr> argument may be any positive integer. If
present, it MUST increase with every change to the newsgroup
- list and MUST NOT ever decrease. If provided, news servers
- SHOULD remember the <chksernr> value of the previous
- checkgroups control message honored for a particular hierarchy
- or sub-hierarchy and decline to honor any subsequent checkgroups
- control message for the same hierarchy or sub-hierarchy with a
- smaller <chksernr> value.
+ list, MUST NOT ever decrease, and MUST be included in all
+ subsequent checkgroups control messages with the same scope.
+ If provided, news servers SHOULD remember the <chksernr>
+ value of the previous checkgroups control message honored for a
+ particular hierarchy or sub-hierarchy and decline to honor any
+ subsequent checkgroups control message for the same hierarchy
+ or sub-hierarchy with a smaller <chksernr> value or with no
+ <chksernr> value.

For example, the following Control header

--
Russ Allbery ([email-masked])

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12CCvsf037214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 05:12:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12CCvTJ037213; Mon, 2 Feb 2009 05:12:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-2.gradwell.net (v-smtp-auth-relay-2.gradwell.net [79.135.125.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12CCkbM037192 for ; Mon, 2 Feb 2009 05:12:57 -0700 (MST) (envelope-from [email-masked])
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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4986e31a.a80.207 for [email-masked]; Mon, 2 Feb 2009 12:12:10 +0000 (envelope-sender )
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 n12CC20r011440 for ; Mon, 2 Feb 2009 12:12:07 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id n12CC1cB011437 for [email-masked]; Mon, 2 Feb 2009 12:12:01 GMT
To: [email-masked]
Xref: clerew local.usefor:24981
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: ISSUE 1583 status (was: Re: January: open issues on USEPRO)
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <[email-masked]> <[email-masked]>
Date: Mon, 2 Feb 2009 12:11:38 GMT
Lines: 41
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Russ Allbery writes:

>There are four issues in this ticket.

But it seems that the third is the only one where we might take any
further action.

>The third issue is about what to do when a serial number is specified for
>a hierarchy and then a subsequent control message arrives without a serial
>number. The current document is silent on what to do in this situation.
>I think it should state what should be done. My sense of the previous
>discussion was that most people felt that such a checkgroups should be
>ignored, meaning that once an authorized control message sender starts
>issuing checkgroups with serial numbers, subsequent checkgroups for that
>hierarchy must always use serial numbers, which must always be larger than
>the previous serial number. I'm a little worried about this provision,
>since after long periods of time and a change of hierarchy administration
>it can be potentially difficult to uncover the previous serial number.
>But I don't see a good alternative that preserves the serial number
>semantics.

I am slightly worried about being too specific here, for the reason you
mention. Perhaps some wording to the effect that newsadmins should think
carefully before accepting such a checkgroups (and in any case, blind
automatic acceptance of checkgroups has never been a recommended
practice). I wouldn't want to say anything stronger than that, and would
be happy to leave it as it stands.

So by all means suggest a wording if you like, or else let it be.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] 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.14.2/8.14.2) with ESMTP id n128Bmlm026002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 01:11:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n128Bmnf026001; Mon, 2 Feb 2009 01:11:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from tertius.net.au (tertius.net.au [203.30.75.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n128BZuo025991 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 2 Feb 2009 01:11:46 -0700 (MST) (envelope-from [email-masked])
Received: from babble.peel.tertius.net.au (c220-237-62-48.smelb2.vic.optusnet.com.au [220.237.62.48]) by tertius.net.au (Postfix) with ESMTP id AE71A8080D0 for ; Mon, 2 Feb 2009 19:11:32 +1100 (EST)
Message-Id: <[email-masked]>
From: Thorfinn
To: Usefor Mailing List
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: ISSUE 1583 status (was: Re: January: open issues on USEPRO)
Date: Mon, 2 Feb 2009 18:09:36 +1100
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Discussion mostly occurred in late September 2008, under the subject
line:
ISSUE: Checkgroups control messages

I can't remember whether we had issue numbers at that point, but for
some reason the original subject line didn't, and nobody fixed it.

I had something to say back then regarding sub-issues 2 and 4 below,
and had nothing to say at that time about 1 and 3.

On 2 Feb 2009, at 12:43, Russ Allbery wrote:

>
> "Charles Lindsey" writes:
>> Harald Alvestrand writes:
>
>>> 1583 USEPRO LC 5.2.3: Checkgroups control messages
>>> Open. There may be multiple issues here.
>>> No discussion with "1583" in the subject.
>
>> I think we agreed that the present checkgroups message has a
>> problem. The
>> draft introduces a new feature which addresses that problem, which
>> will
>> work fine if checkgroups issuers use it, and it checkgroups receivers
>> recognise it.
>
>> But if it isn't used or recognised, then the original problem will
>> remain, and there is nothing much we can do about it. Therefore I
>> think
>> no action is needed - the present wording is the best that can be
>> done.
>
> There are four issues in this ticket.
>
> The first issue is that there's no method in the checkgroups syntax to
> delegate control over a newsgroup whose name matches the
> subhierarchy. I
> think we agreed that, yes, this is the case, and there's nothing we
> can
> really do about it at this stage and while still remaining
> backwards-compatible.

I think someone mentioned something about issuing the delegation in
the parent checkgroups, but I don't recall the details.

> The second issue was about whether there should be a maximum size of
> the
> serial number. I believe we decided that since you can compare serial
> numbers as strings, there wasn't a need to set a limit.

Yes. Specifically, if you skip any leading zeros, then compare string
length, then asciibetically compare if strings are the same length,
you have an ordered integer comparison method, with no need to
actually use an integer representation at any point.

Given the infrequency of checkgroups, the relative inefficiency of
this comparison vs integer comparisons is a total non issue.

> The third issue is about what to do when a serial number is
> specified for
> a hierarchy and then a subsequent control message arrives without a
> serial
> number. The current document is silent on what to do in this
> situation.
> I think it should state what should be done. My sense of the previous
> discussion was that most people felt that such a checkgroups should be
> ignored, meaning that once an authorized control message sender starts
> issuing checkgroups with serial numbers, subsequent checkgroups for
> that
> hierarchy must always use serial numbers, which must always be
> larger than
> the previous serial number. I'm a little worried about this
> provision,
> since after long periods of time and a change of hierarchy
> administration
> it can be potentially difficult to uncover the previous serial number.
> But I don't see a good alternative that preserves the serial number
> semantics.

I don't see any way to do that. I think it's a reasonable assumption
that if you can't find a serial number anywhere, including by posting
in newsgroups and asking newsmasters for what their latest one is,
then it has probably become irrelevant. After all, if nobody at all
knows what their latest checkgroups serial number is, then they can't
be able to compare with it.

This seems like an "unlikely to be a problem" situation to me. I
think we should explicitly say that once you have gone to serial
numbers, there is no way back to having no serial numbers.

> The fourth issue is whether there should be a mechanism to reset the
> serial number. I think we decided that we weren't going to specify
> one.

Yes, I believe we should not specify one - there is no good way to
specify a reset, and combined with the ability to simply continue
incrementing into integer infinity, there is no need for a reset.

The closest thing was my suggestion that we could use the DNS serial
number mechanism of sequence space arithmetic (i.e. a wrap-around -
see DNS RFCs or the original discussion in september for details if
needed), but I believe that that is more problematic than simply
allowing incrementing into infinity.

Ook,

Thorf

--
[email-masked]
The world is coming to an end. Please log off. -- BSD fortune file

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121vfRT014375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 18:57:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n121vfxB014374; Sun, 1 Feb 2009 18:57:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121vUW1014349 for ; Sun, 1 Feb 2009 18:57:40 -0700 (MST) (envelope-from [email-masked])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 77BBE51C672 for ; Sun, 1 Feb 2009 17:57:30 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp2.stanford.edu (Postfix) with ESMTP id 3D7FA51C682 for ; Sun, 1 Feb 2009 17:57:29 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id C7543E90D9; Sun, 1 Feb 2009 17:57:29 -0800 (PST)
To: [email-masked]
Subject: Re: [1586] Multiple POSTED in Path: header
In-Reply-To: (Charles Lindsey's message of "Wed\, 28 Jan 2009 12\:56\:51 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References:
From: Russ Allbery
Organization: The Eyrie
Date: Sun, 01 Feb 2009 17:57:29 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

"Charles Lindsey" writes:

> 3.4.1 of the present draft contains:
>
> A proto-article has the same format as a normal article except that the
> Injection-Info and Xref header fields MUST NOT be present; the Path
> header field SHOULD NOT contain a "POSTED" ; 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.
>
> That "SHOULD NOT" was formerly "MUST NOT", so it is an improvement.
>
> But I propose changing it to:
>
> .. the Path header field MAY contain a "POSTED" ; ...

Since that is equivalent to saying nothing about the POSTED
, were we to decide on this change, I think I would omit the
sentence entirely and just add the note (with corresponding minor wording
changes). Or even better, move the NOTE to a subsection of 3.2 that
explains the meaning of a POSTED keyword and the circumstances under which
a Path header could be constructed containing several of them.

> and adding a NOTE such as the following:
>
> NOTE: Whereas the presence of two "POSTED" s will often
> indicate a malicious attempt to disguise the true origin of an article,
> it could also arise following some ususual gatewaying or injecting
> scenario (taking advantage of the "MAY contain" above), in which case
> it could be useful for detecting unintended loops or mismanaged
> gateways. The whole intent of these humans in assessing unusual situations, and it would be unwise for
> subsequent agents automatically to assume one possibility or the other.
>
> Essentially, I am arguing for not throwing away any information which might
> be of subsequent diagnostic use, possibly at the expense of making people
> think a bit before accusing posters of trollery. It is up to the "netkops"
> to deal with these issues, and our draft should not try to prejudge their
> efforts.

The corresponding text in 3.4.2 is:

In some cases, offering the same proto-article to all injecting
agents may not be possible (such as when gatewaying, after injection,
articles found on one Netnews network to another supposedly-
unconnected one). In this case, the posting agent MUST remove any
Xref header field and rename or remove any Injection-Info, Path, and
other trace header field before passing it to another injecting
agent. (This converts the article back into a proto-article.)

Since multiple injection is the only means by which multiple POSTED
can arise with their intended meaning and purpose, it
seems pointless to relax the requirement too far in one area and not in
the other.

I think our options here are:

1. Treat the Path header as special and permit (or even encourage)
retaining it while not permitting retention of the other trace headers,
on the grounds that it has an intrinsic ordering and therefore isn't as
prone to confusion as having multiple trace headers that aren't
ordered.

2. Leave the existing wording, which requires multiple injection to remove
or rename the Path header but allows readers to add spurious POSTED
s by violating a SHOULD. I'm not entirely comfortable
with it, but I can't think of any specific protocol harm it could
cause.

3. Restore the MUST in the proto-article section to match the MUST in
3.4.2 and make the document consistent but possibly too strict.

4. Relax the MUST generally in 3.4.2, but then we will run into issues
with Injection-Info, which the posting agent is not permitted to supply
and which doesn't have an intrinsic ordering the way that the Path
header does.

The more I think about it, the more option 1 seems like a workable idea,
but I think that's reversing some decisions that we made some time back.
That makes me nervous at this stage of the process.

--
Russ Allbery ([email-masked])

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121hiID013995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 18:43:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n121hiXW013994; Sun, 1 Feb 2009 18:43:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp5.stanford.edu (smtp5.Stanford.EDU [171.67.219.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121hXFZ013984 for ; Sun, 1 Feb 2009 18:43:44 -0700 (MST) (envelope-from [email-masked])
Received: from smtp5.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5D7AE3B6969 for ; Sun, 1 Feb 2009 17:43:33 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp5.stanford.edu (Postfix) with ESMTP id 390713B65CE for ; Sun, 1 Feb 2009 17:43:32 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id DA632E90CA; Sun, 1 Feb 2009 17:43:32 -0800 (PST)
To: [email-masked]
Subject: ISSUE 1583 status (was: Re: January: open issues on USEPRO)
In-Reply-To: (Charles Lindsey's message of "Wed\, 28 Jan 2009 11\:41\:43 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[email-masked]>
From: Russ Allbery
Organization: The Eyrie
Date: Sun, 01 Feb 2009 17:43:32 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

"Charles Lindsey" writes:
> Harald Alvestrand writes:

>> 1583 USEPRO LC 5.2.3: Checkgroups control messages
>> Open. There may be multiple issues here.
>> No discussion with "1583" in the subject.

> I think we agreed that the present checkgroups message has a problem. The
> draft introduces a new feature which addresses that problem, which will
> work fine if checkgroups issuers use it, and it checkgroups receivers
> recognise it.

> But if it isn't used or recognised, then the original problem will
> remain, and there is nothing much we can do about it. Therefore I think
> no action is needed - the present wording is the best that can be done.

There are four issues in this ticket.

The first issue is that there's no method in the checkgroups syntax to
delegate control over a newsgroup whose name matches the subhierarchy. I
think we agreed that, yes, this is the case, and there's nothing we can
really do about it at this stage and while still remaining
backwards-compatible.

The second issue was about whether there should be a maximum size of the
serial number. I believe we decided that since you can compare serial
numbers as strings, there wasn't a need to set a limit.

The third issue is about what to do when a serial number is specified for
a hierarchy and then a subsequent control message arrives without a serial
number. The current document is silent on what to do in this situation.
I think it should state what should be done. My sense of the previous
discussion was that most people felt that such a checkgroups should be
ignored, meaning that once an authorized control message sender starts
issuing checkgroups with serial numbers, subsequent checkgroups for that
hierarchy must always use serial numbers, which must always be larger than
the previous serial number. I'm a little worried about this provision,
since after long periods of time and a change of hierarchy administration
it can be potentially difficult to uncover the previous serial number.
But I don't see a good alternative that preserves the serial number
semantics.

The fourth issue is whether there should be a mechanism to reset the
serial number. I think we decided that we weren't going to specify one.

--
Russ Allbery ([email-masked])