Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard

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

In <[e-mail]> Tony Hansen <[e-mail]> writes:

>I admit it: I'm not a fan of X- headers.

>Why not just register a header in the header registry and be done with
>it, rather than encouraging yet-another set of X-headers, all possibly
>named differently? Why encourage the use of X- headers in a standards
>track document?

Because, in that case, there are 57 other headers that you ought to
standardize.

As I have already pointed out, X-Headers are fine when intended for human
consumption, or for automatic recognition only by the agents that put them
there (as in this case, where different gateways could quite happily use
different X-Headers for this purpose).

And even if you were to standardize all 57 headers that might exist today,
someone would  promptly invent a new X-Header tomorrow.

It ain't broke ...

-- 
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.14.2/8.14.2) with ESMTP id m8UGCEQH097065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8UGCEOk097064; Tue, 30 Sep 2008 09:12:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8UGC249096999 for <[e-mail]>; Tue, 30 Sep 2008 09:12:13 -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 v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48e24fd2.6a5e.9cb for [e-mail]; Tue, 30 Sep 2008 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 m8UGC1Lx002197 for <[e-mail]>; Tue, 30 Sep 2008 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8UGC1cf002194 for [e-mail]; Tue, 30 Sep 2008 17:12:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24935
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <6.2.5 <[e-mail]>
Date: Tue, 30 Sep 2008 11:32:05 GMT
Lines: 32
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]> Tony Hansen <[e-mail]> writes:

>I admit it: I'm not a fan of X- headers.

>Why not just register a header in the header registry and be done with
>it, rather than encouraging yet-another set of X-headers, all possibly
>named differently? Why encourage the use of X- headers in a standards
>track document?

Because, in that case, there are 57 other headers that you ought to
standardize.

As I have already pointed out, X-Headers are fine when intended for human
consumption, or for automatic recognition only by the agents that put them
there (as in this case, where different gateways could quite happily use
different X-Headers for this purpose).

And even if you were to standardize all 57 headers that might exist today,
someone would  promptly invent a new X-Header tomorrow.

It ain't broke ...

-- 
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.14.2/8.14.2) with ESMTP id m8QGCFQT004768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8QGCF5s004767; Fri, 26 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8QGC3Jd004700 for <[e-mail]>; Fri, 26 Sep 2008 09:12:14 -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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.301) id 48dd09d5.4e5e.1b2e for [e-mail]; Fri, 26 Sep 2008 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 m8QGC1tt027680 for <[e-mail]>; Fri, 26 Sep 2008 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8QGC1Ga027677 for [e-mail]; Fri, 26 Sep 2008 17:12:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24933
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Niggles in usepro-draft-11
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: Fri, 26 Sep 2008 14:27:42 GMT
Lines: 41
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]> Thorfinn <[e-mail]> writes:

>On 26 Sep 2008, at 05:06, Russ Allbery wrote:

>> "The same" to me includes the possibility of "none."



>"the same checks" does definitely have a small difference in  
>implication to "whatever checks".  "the same checks" has a slightly  
>stronger implication that there is at least one check.  It's not a  
>hugely stronger implication, no.  And it is just in implication,  
>rather than in explicit meaning.

Yes, that is essentially the point I was trying to make. Or Julien's "if
any" would do as well.

>However, I think that that is not a bad implication to have, and you  
>are certainly correct that "the same" includes the possibility of  
>"none".

Indeed, but if you want to drop more/stronger hints that checks on cancel
messages are a Good Thing, then the text(s) discussing cancel messages is
the place to do it (but we already say as much as we reasonably can
there).

>Certainly implementors of news software (the target audience for this)  
>should already understand that possibility. :-)

Implementors "should" do lots of things :-( .

-- 
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.14.2/8.14.2) with ESMTP id m8QDhCnm094429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 06:43:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8QDhC0d094428; Fri, 26 Sep 2008 06:43:12 -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.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8QDh0ix094419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 26 Sep 2008 06:43:11 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-146.messagelabs.com!1222436578!2533695!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.128.141]
Received: (qmail 18951 invoked from network); 26 Sep 2008 13:42:59 -0000
Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-10.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 26 Sep 2008 13:42:59 -0000
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m8QDgwPB004302 for <[e-mail]>; Fri, 26 Sep 2008 06:42:58 -0700
Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m8QDgrB6004261 for <[e-mail]>; Fri, 26 Sep 2008 06:42:53 -0700
Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m8QDgqoI001476 for <[e-mail]>; Fri, 26 Sep 2008 08:42:52 -0500
Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m8QDgmpj001416 for <[e-mail]>; Fri, 26 Sep 2008 08:42:48 -0500
Received: from [135.210.81.178] (unknown[135.210.81.178](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20080926134247gw1003snile> (Authid: tony); Fri, 26 Sep 2008 13:42:48 +0000
Message-ID: <[e-mail]>
Date: Fri, 26 Sep 2008 09:42:47 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
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>

I admit it: I'm not a fan of X- headers.

Why not just register a header in the header registry and be done with
it, rather than encouraging yet-another set of X-headers, all possibly
named differently? Why encourage the use of X- headers in a standards
track document?

For example, consider using Netnews-Gateway-Control in place of
X-Gateway, or some other such name,

   2.  The news-to-mail gateway adds a Netnews-Gateway-Control header
       field to all messages it generates.

and then add this to the IANA Considerations section:

   Header field name: Netnews-Gateway-Control
   Applicable protocol: mail, netnews
   Status: standard
   Author/Change controller: IETF
   Specification document(s): RFC XXXX (this document)

If you'd rather define a *set* of header names, to allow implementations
to pick their own names, then use this:

   2.  The news-to-mail gateway adds a Netnews-Gateway-Control header
       field (or a header field whose name begins with
       Netnews-Gateway-Control-) to all messages it generates.

and then add this to the IANA Considerations section:

   Header field name: Netnews-Gateway-Control
   Applicable protocol: mail, netnews
   Status: standard
   Author/Change controller: IETF
   Specification document(s): RFC XXXX (this document)

   Header field name: Netnews-Gateway-Control-* (all headers whose name
	begins with "Netnews-Gateway-Control-")
   Applicable protocol: mail, netnews
   Status: standard
   Author/Change controller: IETF
   Specification document(s): RFC XXXX (this document)

My $0.02.

	Tony Hansen
	[e-mail]

SM wrote:
>> I can see your point here, but I'm not sure the lack is particularly
>> important.  I'd really rather not see us make further changes to USEFOR;
>> generally an X-* header is used for this and is adequate in practice.
> 
> Each implementation might use a different header field name.  It's might
> become a problem in future.
> 
>> Well, this is very explicitly an example based on a specific
>> implementation, which happens to use an X-* header.  But I can see where
>> this would be less than ideal.  However, as above, I'm hesitant to invent
>> a new header for this purpose and add the necessary machinery for
>> registering it when there is no standardized existing practice and it's
>> not clear what issues are involved in picking a header field,
>> standardizing its format, and so forth.
> 
> Implementors will likely pick X-Gateway as you mentioned that header
> name in the example.  Once people start using specific headers, it's
> difficult to depreciate them in favor of some standardized format.



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 m8Q64Swf060240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 23:04:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8Q64SEH060239; Thu, 25 Sep 2008 23:04:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8Q64REg060232 for <[e-mail]>; Thu, 25 Sep 2008 23:04:27 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 15863 invoked by uid 503); 26 Sep 2008 06:45:11 -0000
Received: from b6.ovh.net (HELO mail172.ha.ovh.net) (213.186.33.56) by 27.mail-out.ovh.net with SMTP; 26 Sep 2008 06:45:11 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 26 Sep 2008 06:04:21 -0000
Received: from aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.112.31.236) by ns0.ovh.net with SMTP; 26 Sep 2008 06:04:20 -0000
Message-ID: <25A85431C8D5492882F2EFFE008517CF@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Commit in docs/usefor (usepro.xml)
Date: Fri, 26 Sep 2008 08:04:13 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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
X-Ovh-Tracer-Id: 8891231565973552569
X-Ovh-Remote: 83.112.31.236 (aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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>

> +            article it had not yet seen, so it ought not to be
> +            aggressively short.  For Usenet, for example, a cutoff
> +            interval of no less than seven days is conventional.</t>

Is it the convention for almost all news servers?
Note that INN has a 10-day cutoff date.

-- 
Julien ÉLIE

« Desinit in piscem mulier formosa superne. » (Horace)



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 m8Q5vUwV059787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 22:57:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8Q5vUPY059786; Thu, 25 Sep 2008 22:57:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8Q5vIe4059773 for <[e-mail]>; Thu, 25 Sep 2008 22:57:29 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 21505 invoked by uid 503); 26 Sep 2008 06:38:02 -0000
Received: from b6.ovh.net (HELO mail172.ha.ovh.net) (213.186.33.56) by 27.mail-out.ovh.net with SMTP; 26 Sep 2008 06:38:02 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 26 Sep 2008 05:57:12 -0000
Received: from aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.112.31.236) by ns0.ovh.net with SMTP; 26 Sep 2008 05:57:11 -0000
Message-ID: <239A3168A4264A479F407EF50579A07C@Iulius>
From: =?iso-8859-1?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Niggles in usepro-draft-11
Date: Fri, 26 Sep 2008 07:57:04 +0200
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
X-Ovh-Tracer-Id: 8770478801000332729
X-Ovh-Remote: 83.112.31.236 (aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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>

Ho Thorfinn,

>>>>       Accordingly, news servers SHOULD
>>>>       apply to a Supersedes header field the same authentication and
>>>>       authorization checks as they would apply to cancel control
>>>>       messages.
>>
>> Does "the same authentication and authorization checks as they would
>> apply" versus "whatever authentication and authorization checks they  would apply" feel different in meaning to you?
>
> "the same checks" does definitely have a small difference in  implication to "whatever checks".  "the same checks" has a slightly 
> stronger implication that there is at least one check.  It's not a  hugely stronger implication, no.  And it is just in 
> implication,  rather than in explicit meaning.

Why not say "the same authentication and authorization checks, if any,
as they would apply"?

-- 
Julien ÉLIE

« La vie ne vaut rien. Mais rien ne vaut la vie. » (André Malraux) 



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 m8Q0NeoA041314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 17:23:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8Q0NeJV041313; Thu, 25 Sep 2008 17:23:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8Q0NR8Z041299 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 25 Sep 2008 17:23:39 -0700 (MST) (envelope-from [e-mail])
Received: from [10.134.51.32] (sys-fw1.off.connect.com.au [192.94.41.120]) by tertius.net.au (Postfix) with ESMTP id 1D5A78080B1 for <[e-mail]>; Fri, 26 Sep 2008 10:23:23 +1000 (EST)
Message-Id: <[e-mail]>
From: Thorfinn <[e-mail]>
To: Usefor WG <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Niggles in usepro-draft-11
Date: Fri, 26 Sep 2008 10:23:22 +1000
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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 26 Sep 2008, at 05:06, Russ Allbery wrote:

>
> "Charles Lindsey" <[e-mail]> writes:
>
>>> How about this:
>>
>>>     <section anchor="supersedes" title="The Supersedes Header  
>>> Field">
>>>       <t>The presence of a Supersedes header field in an article
>>>       requests that the message identifier given in that header  
>>> field be
>>>       withdrawn in exactly the same manner as if it were the target
>>>       of a cancel control message.  Accordingly, news servers SHOULD
>>>       apply to a Supersedes header field the same authentication and
>>>       authorization checks as they would apply to cancel control
>>>       messages.  If the Supersedes header field is honored, the news
>>>       server SHOULD take the same actions as it would take when  
>>> honoring
>>>       a cancel control message for the given target article.</t>
>>
>>> I think inverting the sentence makes it clearer.
>>
>> Yes, but I would still like to see the word "whatever" in there
>> somewhere, just to make it clear that there might well be no checks  
>> on
>> cancel messages (and hence no action applicable to Supersedes).  
>> That is,
>> in fact, the common current practice, much as we might wish otherwise
>> :-( .
>
> Does "the same authentication and authorization checks as they would
> apply" versus "whatever authentication and authorization checks they  
> would
> apply" feel different in meaning to you?  That shading of meaning is  
> too
> fine for me to detect, and the word "whatever" seems less formal and
> precise, which is why I used the former wording.
>
> "The same" to me includes the possibility of "none."


:-) I have occasionally similar arguments with my wife regarding word  
usage, which is when she generally reminds me that I've been a  
computer programmer for too long, and I usually realise she's right.

"the same checks" does definitely have a small difference in  
implication to "whatever checks".  "the same checks" has a slightly  
stronger implication that there is at least one check.  It's not a  
hugely stronger implication, no.  And it is just in implication,  
rather than in explicit meaning.

However, I think that that is not a bad implication to have, and you  
are certainly correct that "the same" includes the possibility of  
"none".

Certainly implementors of news software (the target audience for this)  
should already understand that possibility. :-)

-- 
<a href="http://tertius.net.au/~thorfinn/">[e-mail]</a>
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 m8PN4eVo037306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 16:04:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PN4eOS037305; Thu, 25 Sep 2008 16:04:40 -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.14.2/8.14.2) with ESMTP id m8PN4S7x037297 for <[e-mail]>; Thu, 25 Sep 2008 16:04:38 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 21A0765B8A2 for <[e-mail]>; Thu, 25 Sep 2008 16:04:28 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id DB08865AD03 for <[e-mail]>; Thu, 25 Sep 2008 16:04:27 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 77BEEE7924; Thu, 25 Sep 2008 16:04:27 -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: Thu, 25 Sep 2008 16:04:27 -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: Thursday, September 25, 2008 @ 16:04:26
  Author: eagle
Revision: 5067

Don't mention a specific X-* header in the gatewaying example.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-25 23:03:51 UTC (rev 5066)
+++ docs/usefor/usepro.xml	2008-09-25 23:04:26 UTC (rev 5067)
@@ -1400,10 +1400,10 @@
               of duplicates to serve as the first line of defense against
               loops.</t>
 
-              <t>The news-to-mail gateway adds an X-Gateway header field
-              to all messages it generates. The mail-to-news gateway
-              discards any incoming messages containing this header field.
-              This is robust against mailing list managers that replace
+              <t>The news-to-mail gateway adds an X-* header field to all
+              messages it generates. The mail-to-news gateway discards
+              any incoming messages containing this header field.  This
+              is robust against mailing list managers that replace
               the message identifier, and against any number of email
               hops, provided that the other message header fields are
               preserved.</t>



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 m8PN44hB037285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 16:04:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PN44NG037284; Thu, 25 Sep 2008 16:04:04 -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.14.2/8.14.2) with ESMTP id m8PN3rfx037274 for <[e-mail]>; Thu, 25 Sep 2008 16:04:03 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ECC0E60F4B5 for <[e-mail]>; Thu, 25 Sep 2008 16:03:52 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id C648060F49D for <[e-mail]>; Thu, 25 Sep 2008 16:03:52 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9CDDFE7924; Thu, 25 Sep 2008 16:03:52 -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: Thu, 25 Sep 2008 16:03:52 -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: Thursday, September 25, 2008 @ 16:03:51
  Author: eagle
Revision: 5066

Further wording fixes based on Charles's comments.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-24 06:17:23 UTC (rev 5065)
+++ docs/usefor/usepro.xml	2008-09-25 23:03:51 UTC (rev 5066)
@@ -521,9 +521,9 @@
             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 might 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>
+            article it had not yet seen, so it ought not to 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
@@ -645,7 +645,7 @@
           <t>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
+          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
@@ -1985,10 +1985,10 @@
       <section anchor="supersedes" title="The Supersedes Header Field">
         <t>The presence of a Supersedes header field in an article
         requests that the message identifier given in that header field be
-        withdrawn in exactly the same manner as if it were the target of a
-        cancel control message.  Accordingly, news servers SHOULD use the
-        same authentication and authorization checks for deciding whether
-        to honor a Supersedes header field as they use for cancel control
+        withdrawn in exactly the same manner as if it were the target
+        of a cancel control message.  Accordingly, news servers SHOULD
+        apply to a Supersedes header field the same authentication and
+        authorization checks as they would apply to cancel control
         messages.  If the Supersedes header field is honored, the news
         server SHOULD take the same actions as it would take when honoring
         a cancel control message for the given target article.</t>



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 m8PMYNs3035415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 15:34:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PMYNDf035414; Thu, 25 Sep 2008 15:34:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8PMYCao035404 for <[e-mail]>; Thu, 25 Sep 2008 15:34:23 -0700 (MST) (envelope-from [e-mail])
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id m8PMY1sL029589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 15:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1222382051; x=1222468451; bh=bviMXgwDLmZFQQml9oMbbtCWtj2pc+18aykn bGZBxGA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=QgUYAh1CbFIOKURQD3g5K4PXmd XjPT8o09rIElE7HR2nQywVyoqS7VUY6UcFXkTYuG4hao0GxXnh5CWaSROCW+BV0Zh9Q pClINBkuIFq2c9BrzCbiQmfHkM8IecJX/JXjeCNfz/N52sWLSo75ol2xqn7tEwtj8hq 5vBywOY2dtE=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=vXpOe0jlL0+O+wrZg6ftiMP1GDFTKiybfvuTCD/CJ5xQwLo1e7fC75N0nAG3bVudb zFlIn1wI/vdY6cFCE0pG8oRpwtaSj41HvPe8ky2KBUk90/e268Cl2WHufea67fA9d5o XYhPS4BfTy12VjJQzHQvBHOhaJnd6NXG64c2Il0=
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 25 Sep 2008 15:33:40 -0700
To: [e-mail]
From: SM <[e-mail]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard
Cc: [e-mail], Russ Allbery <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

Hi Russ,

[I-D author requested Cc]

At 19:35 24-09-2008, Russ Allbery wrote:
>Well, I find that statement unobjectionable but essentially meaningless,
>in that I don't think the document says anything substantively different
>including that statement than without it.  But if it makes others feel
>more comfortable, I don't object to including it.

If you don't find that the addition changes anything, there is no 
point in including it.  The point was that the author address should 
be fixed if it's not according to the specifications for that 
medium.  I did not elaborate as the medium is not restricted to mail.

>That provision doesn't document what happens in practice, nor would it be
>possible to limit the header additions.  (For example, it's essentially
>impossible to send something as an e-mail message without adding Received
>headers.)  I prefer to give implementors a better idea of what to expect,
>and in practice arbitrary headers will get added by the transit through
>the mail system, including all sorts of X-* headers, trace headers, and
>random detritus from spam filters.

Okay.

>We could easily remove that specific header field name from the example
>and instead just say:
>
>     The news-to-mail gateway adds an X-* header field to all messages it
>     generates.  The mail-to-news gateway discards any incoming messages
>     containing this header field.
>
>Would that be an improvement?

Yes, that's better.

Regards,
-sm 



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 m8PJ6tOm022245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 12:06:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PJ6trs022244; Thu, 25 Sep 2008 12:06:55 -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.14.2/8.14.2) with ESMTP id m8PJ6sps022238 for <[e-mail]>; Thu, 25 Sep 2008 12:06:54 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E7F060F0FB for <[e-mail]>; Thu, 25 Sep 2008 12:06:54 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id EF9A760E53F for <[e-mail]>; Thu, 25 Sep 2008 12:06:53 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id EA3C2E7924; Thu, 25 Sep 2008 12:06:53 -0700 (PDT)
To: [e-mail]
Subject: Re: Niggles in usepro-draft-11
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu\, 25 Sep 2008 15\:14\:08 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Thu, 25 Sep 2008 12:06:53 -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:

>>How about this:
>
>>      <section anchor="supersedes" title="The Supersedes Header Field">
>>        <t>The presence of a Supersedes header field in an article
>>        requests that the message identifier given in that header field be
>>        withdrawn in exactly the same manner as if it were the target 
>>        of a cancel control message.  Accordingly, news servers SHOULD
>>        apply to a Supersedes header field the same authentication and
>>        authorization checks as they would apply to cancel control
>>        messages.  If the Supersedes header field is honored, the news
>>        server SHOULD take the same actions as it would take when honoring
>>        a cancel control message for the given target article.</t>
>
>>I think inverting the sentence makes it clearer.
>
> Yes, but I would still like to see the word "whatever" in there
> somewhere, just to make it clear that there might well be no checks on
> cancel messages (and hence no action applicable to Supersedes). That is,
> in fact, the common current practice, much as we might wish otherwise
> :-( .

Does "the same authentication and authorization checks as they would
apply" versus "whatever authentication and authorization checks they would
apply" feel different in meaning to you?  That shading of meaning is too
fine for me to detect, and the word "whatever" seems less formal and
precise, which is why I used the former wording.

"The same" to me includes the possibility of "none."

-- 
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.14.2/8.14.2) with ESMTP id m8PIsgGP021175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 11:54:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PIsgTL021173; Thu, 25 Sep 2008 11:54:42 -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.14.2/8.14.2) with ESMTP id m8PIsVNw021157 for <[e-mail]>; Thu, 25 Sep 2008 11:54:41 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4E82C60EF71 for <[e-mail]>; Thu, 25 Sep 2008 11:54:31 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 2E53360EF94 for <[e-mail]>; Thu, 25 Sep 2008 11:54:30 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 7DE20E7924; Thu, 25 Sep 2008 11:54:30 -0700 (PDT)
To: [e-mail]
Subject: Re: No posting flag
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu\, 25 Sep 2008 15\:19\:44 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <B4F3927BBA3A4D19A1265D9882A27072@Iulius> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Thu, 25 Sep 2008 11:54:30 -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:

>>Instead of:
>
>>      newsgroups-line     = newsgroup-name
>>                               [ 1*HTAB newsgroup-description ]
>>                               [ *WSP moderation-flag ]
>>      moderation-flag     = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")"
>>                               ; SPACE + case sensitive "(Moderated)"
>
>>having status-flag which can be moderation-flag or nopost-flag.
>
> Such a flag would be meaningless except in moderated groups (and one-way
> groups really OUGHT to be moderated).

It would correspond to the 'n' flag in the NNTP protocol, which does
indeed prevent posting.

> Even if your intention was that presence of the flag in a checkgroups
> would change the ACTIVE flag to 'n', no existing server would do so, and
> it would be a long time before it was widely adopted.

True, although this would hardly be the first provision in the draft that
would take a long time to be adopted.

It may be too late to be adding new features, though.

-- 
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.14.2/8.14.2) with ESMTP id m8PGiwhQ011591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 09:44:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PGiwNP011590; Thu, 25 Sep 2008 09:44:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 42.mail-out.ovh.net (42.mail-out.ovh.net [213.251.189.42]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8PGiv34011581 for <[e-mail]>; Thu, 25 Sep 2008 09:44:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 8924 invoked by uid 503); 25 Sep 2008 16:44:37 -0000
Received: from b6.ovh.net (HELO mail432.ha.ovh.net) (213.186.33.56) by 42.mail-out.ovh.net with SMTP; 25 Sep 2008 16:44:37 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 25 Sep 2008 16:44:56 -0000
Received: from aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.112.31.236) by ns0.ovh.net with SMTP; 25 Sep 2008 16:44:55 -0000
Message-ID: <19223A9EF6D348E39943A0D4861B47D4@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Tr: No posting flag
Date: Thu, 25 Sep 2008 18:44:44 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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
X-Ovh-Tracer-Id: 13837028380869787065
X-Ovh-Remote: 83.112.31.236 (aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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>

Hi Charles,

> Such a flag would be meaningless except in moderated groups (and one-way
> groups really OUGHT to be moderated).

I agree.  Still, it prevents people from adding Approved: headers and posting
such articles.  Not everyone uses pgpmoose!


> Even if your intention was that presence of the flag in a checkgroups
> would change the ACTIVE flag to 'n', no existing server would do so

Hmm... INN 2.5 could do so :)


> and it would be a long time before it was widely adopted.

Not longer than the use of the Injection-Info: header.

-- 
Julien ÉLIE

« A facto ad ius non datur consequentia. »



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 m8PGdNQO010968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 09:39:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PGdNIi010967; Thu, 25 Sep 2008 09:39:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 42.mail-out.ovh.net (42.mail-out.ovh.net [213.251.189.42]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8PGdCUS010949 for <[e-mail]>; Thu, 25 Sep 2008 09:39:22 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 2294 invoked by uid 503); 25 Sep 2008 16:38:50 -0000
Received: from b6.ovh.net (HELO mail432.ha.ovh.net) (213.186.33.56) by 42.mail-out.ovh.net with SMTP; 25 Sep 2008 16:38:50 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 25 Sep 2008 16:39:08 -0000
Received: from aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.112.31.236) by ns0.ovh.net with SMTP; 25 Sep 2008 16:39:08 -0000
Message-ID: <797B4B631C6E449A82A048C1676828C5@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Tr: ISSUE: Length and final dots of newsgroups descriptions.
Date: Thu, 25 Sep 2008 18:38:57 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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
X-Ovh-Tracer-Id: 13739356563313130937
X-Ovh-Remote: 83.112.31.236 (aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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 think the group decided that "Tale's rules" for checkgroups lines were
> two arcane to standardize, and the best that could be done was to document
> them (for historic pouposes) in USEAGE.

All right.  Thanks, Charles.  (Also thanks for your other answers.)

-- 
Julien ÉLIE

« À l'école, en algèbre, j'étais du genre Einstein.
  Mais plutôt Franck qu'Albert. » (Philippe Geluck) 



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 m8PGCGuw009306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 09:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PGCGZY009302; Thu, 25 Sep 2008 09:12:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8PGC3Va009255 for <[e-mail]>; Thu, 25 Sep 2008 09:12:15 -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 v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48dbb852.6375.d for [e-mail]; Thu, 25 Sep 2008 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 m8PGC1V9008545 for <[e-mail]>; Thu, 25 Sep 2008 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8PGC1Eb008542 for [e-mail]; Thu, 25 Sep 2008 17:12:01 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24919
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Niggles in usepro-draft-11
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 25 Sep 2008 15:14:08 GMT
Lines: 48
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:

>>>    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
>>                                           ^^^^^^^^
>>                                            (this
>>>    article back into a proto-article.)

>The parenthetical is a complete sentence and therefore should begin with a
>capital letter.

Yes, but my suggestion was to make it a continuation of the preceding
sentence (hence I removed the '.'). But it is no huge issue :-) .


>How about this:

>      <section anchor="supersedes" title="The Supersedes Header Field">
>        <t>The presence of a Supersedes header field in an article
>        requests that the message identifier given in that header field be
>        withdrawn in exactly the same manner as if it were the target 
>        of a cancel control message.  Accordingly, news servers SHOULD
>        apply to a Supersedes header field the same authentication and
>        authorization checks as they would apply to cancel control
>        messages.  If the Supersedes header field is honored, the news
>        server SHOULD take the same actions as it would take when honoring
>        a cancel control message for the given target article.</t>

>I think inverting the sentence makes it clearer.

Yes, but I would still like to see the word "whatever" in there somewhere,
just to make it clear that there might well be no checks on cancel
messages (and hence no action applicable to Supersedes). That is, in fact,
the common current practice, much as we might wish otherwise :-( .

-- 
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.14.2/8.14.2) with ESMTP id m8PGCGNI009308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 09:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PGCGcO009303; Thu, 25 Sep 2008 09:12:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8PGC3bw009256 for <[e-mail]>; Thu, 25 Sep 2008 09:12:15 -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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48dbb852.14d4.1 for [e-mail]; Thu, 25 Sep 2008 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 m8PGC2YB008553 for <[e-mail]>; Thu, 25 Sep 2008 17:12:02 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8PGC1f9008550 for [e-mail]; Thu, 25 Sep 2008 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24920
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: No posting flag
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <B4F3927BBA3A4D19A1265D9882A27072@Iulius>
Date: Thu, 25 Sep 2008 15:19:44 GMT
Lines: 45
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 <B4F3927BBA3A4D19A1265D9882A27072@Iulius> =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]> writes:

>Hi,

>I thought it might be worth forwarding this remark from D. Stussy in
>news.software.nntp <news:gbbqv3$lcq$[e-mail]>.

>> 2)  I have also noticed that some local/regional/special hierarchies gate
>> mailing lists in a ONE WAY fashion.  For them, the appropriate moderation
>> status in the active file is "n".  Perhaps the "checkgroups" control
>> messages should handle this with a "(No Posting)" tag, similar to that of
>> "(Moderated)", in the description field.  Group creation should also support
>> this.

>" (No Posting)" or " (No posting)" maybe should be added to the newgroups line.

>Instead of:

>      newsgroups-line     = newsgroup-name
>                               [ 1*HTAB newsgroup-description ]
>                               [ *WSP moderation-flag ]
>      moderation-flag     = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")"
>                               ; SPACE + case sensitive "(Moderated)"

>having status-flag which can be moderation-flag or nopost-flag.

Such a flag would be meaningless except in moderated groups (and one-way
groups really OUGHT to be moderated). Otherwise postings to the group would
succeed and propagate normally thoughout Usenet, even if they did not get
back to the mailint list.

Even if your intention was that presence of the flag in a checkgroups
would change the ACTIVE flag to 'n', no existing server would do so, and
it would be a long time before it was widely adopted.

-- 
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.14.2/8.14.2) with ESMTP id m8PGCGix009310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 09:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PGCGiV009305; Thu, 25 Sep 2008 09:12:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8PGC5ku009261 for <[e-mail]>; Thu, 25 Sep 2008 09:12:15 -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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48dbb854.1336.9 for [e-mail]; Thu, 25 Sep 2008 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 m8PGC1ML008536 for <[e-mail]>; Thu, 25 Sep 2008 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8PGC0Ad008531 for [e-mail]; Thu, 25 Sep 2008 17:12:00 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24918
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: ISSUE: treatment of POSTED in proto articles
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 25 Sep 2008 15:06:35 GMT
Lines: 67
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>

Sory, I omitted to change the Subject line to include "ISSUE" the first
time I posted this.

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

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

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

>> 3.4.1.  Proto-articles
>>
>>    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 MUST NOT contain a "POSTED" <diag-keyword>; and any
>>    of the following mandatory header fields MAY be omitted: Message-ID,
>>    Date, and Path.  In all other respects, a proto-article MUST be a
>>    valid Netnews article.  In particular, the header fields which may be
>>    omitted MUST NOT be present with invalid content.
>>
>> I am worried about that 'MUST NOT contain a "POSTED" <diag-keyword>'. It
>> would cause no interoperability problems and cause no significant harm,
>> and hence a "MUST" cannot be justified under RFC 2119. Nothing breaks if
>> two "POSTEDs appear in one Path.  Indeed, it could arise legitimately in
>> multiple injection "after the fact", and in other exotic gatewaying
>> situations.
>>
>> Yes, some s[pc]ammers will preload the Path so as to disguise the true
>> origin of an article (which is indeed why POSTED was invented), but that
>> is a matter to be taken up by the netkops rather than the protocols. And
>> I would prefer to preserve all evidence left over from previous Paths in
>> order to facilitate bebugging of broken gateways, etc.
>>
>> So, at the most, it ought to be a SHOULD, and I would be happy to omit
>> it altogether. Note that whatever change is made here, corresponding
>> changes would be needed in 3.4.2 and 3.5.2 Step 2.

>This is also a protocol change and should therefore be a separate issue.
>I'm inclined to agree with you that MUST isn't justified here and SHOULD
>is more appropriate.  I think we already talked about this before,
>although I haven't gone back and looked.

OK, here it is. I note that you agree that MUST is too strong.

However, I think SHOULD (and perhaps even MAY) is too strong. The protocol
use to prevent loops is not affected by this change. But the Path is also
important for diagnosing the cause of loops (not necessarily
non-terminating ones) such as those caused by peculiar gatewaying, and for
spotting trollers who try to disguise the source of their articles.

So seeing two 'POSTED's in a Path should immediately raise alarm bells
(even though it may occasionally turn out to have a benign explanation).
But if duplicate 'POSTED's are removed, then no alarm bells will be
heard. So leave them in, and let the Debuggers and the Netkops take care
of them.

In either case, there would be consequential changes elsewhere, as noted.

-- 
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.14.2/8.14.2) with ESMTP id m8PGCGKj009309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 09:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PGCGAn009304; Thu, 25 Sep 2008 09:12:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8PGC3qW009257 for <[e-mail]>; Thu, 25 Sep 2008 09:12:15 -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 v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48dbb853.5cb6.24 for [e-mail]; Thu, 25 Sep 2008 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 m8PGC2k7008561 for <[e-mail]>; Thu, 25 Sep 2008 17:12:02 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8PGC2BI008558 for [e-mail]; Thu, 25 Sep 2008 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24921
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Tr: ISSUE: Checkgroups control messages
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <FDD172E722E445F8BCD9252E9BE21220@Iulius>
Date: Thu, 25 Sep 2008 15:26:17 GMT
Lines: 23
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 <FDD172E722E445F8BCD9252E9BE21220@Iulius> =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]> writes:

>Well, if your news server does not do any kind of expiration, what do you
>once you have exhausted the whole range of article numbers?

Who (apart from Google) has the resources to store the complete set of
articles in a group which has run-around its article numbers?

And what else could such a server do if it intended to continue accepting
new articles? Move the old ones to a separate archive group? It is no use
arbitrarily deciding to use 64 bit numbers, because its client user agents
would break.

-- 
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.14.2/8.14.2) with ESMTP id m8PGCGQv009307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 09:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8PGCGIY009301; Thu, 25 Sep 2008 09:12:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8PGC367009258 for <[e-mail]>; Thu, 25 Sep 2008 09:12:15 -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 v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48dbb853.60b4.12 for [e-mail]; Thu, 25 Sep 2008 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 m8PGC3rQ008578 for <[e-mail]>; Thu, 25 Sep 2008 17:12:03 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8PGC3Wn008572 for [e-mail]; Thu, 25 Sep 2008 17:12:03 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24922
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: ISSUE: Length and final dots of newsgroups descriptions.
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <4E57E0839E9E4A51954B5CD2CD8FA3E1@Iulius>
Date: Thu, 25 Sep 2008 15:32:13 GMT
Lines: 35
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 <4E57E0839E9E4A51954B5CD2CD8FA3E1@Iulius> =?ISO-8859-15?Q?Julien_=C9LIE?= <[e-mail]> writes:

>I wonder whether final dots should not be added to descriptions.

>Maybe it should also be specified that the length of such descriptions
>SHOULD NOT be too long:  a reasonable length not to exceed is 56 characters.

>There should be one or more hard tabs (assume 8 column tabstops) to
>get to a description; if the group.name is more than 24 characters,
>use just one tab.  The description should start with a capital and end
>in a period and not be more than 56 characters (80 - 24) long.  If the
>group is moderated, it should have " (Moderated)" following the
>period, not counted as part of the length of the description.  The
>goal is to keep the total line under 80 columns, so if the group name
>is 25 characters long you'd have eight less description characters to
>work with.

I think the group decided that "Tale's rules" for checkgroups lines were
two arcane to standardize, and the best that could be done was to document
them (for historic pouposes) in USEAGE.

As for the final '.', it is useless, and they have been systematically
excised from the uk.* hierarchy (and the relevant test in Tale's
pgpcontrol script modified accordingly).

-- 
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.14.2/8.14.2) with ESMTP id m8P36vOa052071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 20:06:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8P36vp2052070; Wed, 24 Sep 2008 20:06:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8P36h4o052051 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 24 Sep 2008 20:06:55 -0700 (MST) (envelope-from [e-mail])
Received: from [10.134.51.32] (sys-fw1.off.connect.com.au [192.94.41.120]) by tertius.net.au (Postfix) with ESMTP id C0FDF8080C6 for <[e-mail]>; Thu, 25 Sep 2008 13:06:41 +1000 (EST)
Message-Id: <[e-mail]>
From: Thorfinn <[e-mail]>
To: Usefor WG <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: ISSUE: Checkgroups control messages
Date: Thu, 25 Sep 2008 13:06:29 +1000
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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 Sep 2008, at 02:33, Charles Lindsey wrote:
> In <[e-mail]> Thorfinn <[e-mail] 
> > writes:
>> *nod* 64 bit is becoming fairly prevalent, and that should certainly
>> be enough.
>
>> That said - the DNS world is pretty used to using a 32 bit integer
>> circle for comparison.
>
>> Looking at the current USEPRO text... *ponder* Serial number MUST
>> increase.  That is definitely a problem - you certainly can run out  
>> of
>> 32 bit integer.  It's not all that likely, but it's certainly  
>> possible.
>
> Well, it has taken 30 years for a few heavily populated groups to come
> within sight of overflowing the 32-bit article numbers, and the  
> number of
> checkgroups messages sent is many orders of magnitude less than what  
> such
> groups have seen. So I think 32 bits is fine. People still regard 32  
> bits
> as the 'normal' length of an integer, even though modern hardware is  
> able
> to cope with 64bit, especially for addresses.


*nod* I'm pretty comfortable with no numerical limit on checkgroups  
serial number (i.e., stick with the current text).  There's no good  
reason to treat the serial number as an binary integer at all... it's  
perfectly orderable using trim leading zeros, then compare with string  
length followed by ascii ordering after that.  It's not exactly a  
comparison you have to do very often.

Offtopic:

NNTP article numbers, different story - there are, after all, rather a  
lot more of them on a busy news server, and they are potentially  
needed as index entries and such.

Sequence space arithmetic is definitely good if you're playing with a  
limited number space - the DNS folks had it right way back then. :-)

Meep,

  Thorf

-- 
<a href="http://tertius.net.au/~thorfinn/">[e-mail]</a>
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 m8P2ZM1e050242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 19:35:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8P2ZM01050241; Wed, 24 Sep 2008 19:35:22 -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.14.2/8.14.2) with ESMTP id m8P2ZBOG050228 for <[e-mail]>; Wed, 24 Sep 2008 19:35:21 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5C29B659C9A; Wed, 24 Sep 2008 19:35:10 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id ACABD65A99F; Wed, 24 Sep 2008 19:35:08 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 7CDF0E7924; Wed, 24 Sep 2008 19:35:08 -0700 (PDT)
To: SM <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Tue\, 23 Sep 2008 23\:22\:13 -0700")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 24 Sep 2008 19:35:08 -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>

(I am not a subscriber to the ietf list and would appreciate copies of
replies.)

SM <[e-mail]> writes:
> At 19:44 21-09-2008, Russ Allbery wrote:
>
>> The message is still meaningful; however, it violates a SHOULD in RFC
>> 2822 (well, sort of, depending on how you interpret "belong" in the
>> case of an address that by definition doesn't belong to anyone).
>
> The message may be meaningful for a broadcast but not for two-way
> communication.  For example, if you were reading this mailing list and
> replying to this message through Netnews, I would not be able to send
> you a reply.

Well, the *message* may still be meaningful as part of a two-way
communication.  I get messages all the time from entities with whom I'm in
two-way communication that don't have repliable addresses (such as my
bank).  But I see your basic point.

The common gatewaying case is indeed to a mailing list.

> As obfuscated mailboxes such as example@example dot nospam dot com are
> commonly used in Netnews, proposing ".invalid" as a suffix at least
> ensures that the mailboxes is actually invalid.

Yes, that was the intent.  It's a controversial topic in Netnews.

> Section 3.10.1 mentions practices that are encouraged.  As the document
> "creates" the problem, it may be good for the document to address it
> especially given the different interpretations of "meaningful".  I suggest
> the following in Section 3.10.1:
>
>    5.  The message should be compliant with the specifications for that
> medium.

Well, I find that statement unobjectionable but essentially meaningless,
in that I don't think the document says anything substantively different
including that statement than without it.  But if it makes others feel
more comfortable, I don't object to including it.

>> Yes, thank you.  I now have:
>>
>>    2.  The proto-article is sent as an email with the addition of any
>>        header fields required for an email as defined in [RFC2822], and
>>        possibly with the addition of other header fields conventional in
>>        email such as To and Received.  The existing Message-ID header
>>        field SHOULD be retained.
>
> I don't see the need for specifying additional headers.  You could keep it
> simple with the following:
>
>    2.  The proto-article is sent as an email with the addition of any
>        header fields required for an email as defined in [RFC2822].
>        The existing Message-ID header field SHOULD be retained.

That provision doesn't document what happens in practice, nor would it be
possible to limit the header additions.  (For example, it's essentially
impossible to send something as an e-mail message without adding Received
headers.)  I prefer to give implementors a better idea of what to expect,
and in practice arbitrary headers will get added by the transit through
the mail system, including all sorts of X-* headers, trace headers, and
random detritus from spam filters.

It's also nearly universal current practice to add an explicit To header,
in part because of spam filtering, although there's no standards reason to
require that.

The addition of random headers, and sometimes the modification of random
headers, is why the document tries to push things towards encapsulation
instead of transformation into an e-mail message, but unfortunately most
moderation software can't cope with encapsulated articles currently.

>> I can see your point here, but I'm not sure the lack is particularly
>> important.  I'd really rather not see us make further changes to
>> USEFOR; generally an X-* header is used for this and is adequate in
>> practice.

> Each implementation might use a different header field name.  It's might
> become a problem in future.

Each implementation using a different header field name is perfectly fine
and doesn't pose any problems for the specific issue being addressed by
that part of the example code.

> Implementors will likely pick X-Gateway as you mentioned that header name
> in the example.

We could easily remove that specific header field name from the example
and instead just say:

    The news-to-mail gateway adds an X-* header field to all messages it
    generates.  The mail-to-news gateway discards any incoming messages
    containing this header field.

Would that be an improvement?

-- 
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.14.2/8.14.2) with ESMTP id m8P1IvJf045785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 18:18:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8P1Ivnn045784; Wed, 24 Sep 2008 18:18:57 -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.14.2/8.14.2) with ESMTP id m8P1IjjU045777 for <[e-mail]>; Wed, 24 Sep 2008 18:18:55 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6F4EC60E84C for <[e-mail]>; Wed, 24 Sep 2008 18:18:45 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 4F91060E856 for <[e-mail]>; Wed, 24 Sep 2008 18:18:44 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 23C38E7924; Wed, 24 Sep 2008 18:18:44 -0700 (PDT)
To: [e-mail]
Subject: Expected <path-identity> wording
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 24 Sep 2008 18:18:44 -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>

This was in my long reply, so pulling it out separately since I want
opinions on it.  Does this change look okay to everyone for the section on
Path headers?

--- usepro.xml  (revision 5041)
+++ usepro.xml  (working copy)
@@ -405,7 +405,13 @@
                   followed by the FQDN, IP address, or expected
                   &lt;path-identity> of the source.</t>
                 </list>
-              Be aware that <xref target="RFC1036" /> did not include
+              The "expected &lt;path-identity> of the source of the
+              article" is a &lt;path-identity> for the injecting or
+              relaying agent that passed the article to this relaying or
+              serving agent, determined by properties of connection via
+              which the article was received (for example, an
+              authentication identity or a peer IP address).  Be aware
+              that <xref target="RFC1036" /> did not include
               &lt;path-diagnostic>.  Implementations which predate this
               specification will add only single "!" characters between
               &lt;path-identity> strings.</t>

-- 
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.14.2/8.14.2) with ESMTP id m8P1HtNc045724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 18:17:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8P1Ht69045723; Wed, 24 Sep 2008 18:17:55 -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.14.2/8.14.2) with ESMTP id m8P1Hiq5045713 for <[e-mail]>; Wed, 24 Sep 2008 18:17:54 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4DED82D69E6 for <[e-mail]>; Wed, 24 Sep 2008 18:17:44 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 21B4E2D6946 for <[e-mail]>; Wed, 24 Sep 2008 18:17:43 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id ADB1AE7924; Wed, 24 Sep 2008 18:17:43 -0700 (PDT)
To: [e-mail]
Subject: Re: Niggles in usepro-draft-11
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Wed\, 24 Sep 2008 16\:27\:01 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 24 Sep 2008 18:17:43 -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:

>>>    o  ............  If this
>>>       interval is shorter than the time it takes for an article to
>>>       propagate through the network, the agent might reject an article
>>>       it had not yet seen, so it ought not be aggressively short. .....
>>>                                           ^
>>>                                           to
>
>> It's an unusual formulation in general, but I believe the current
>> formulation is more grammatically correct.  The subject of the dependent
>> clause is "it" and the verb is "be".  If "be" is converted to an
>> infinitive, the dependent clause no longer has a verb.
>
> No, the verb in that dependent clause is "ought".
>
> Consider the sentence "You ought to know better." Surely that is
> gramatically correct, but it needs the infinitive "to know" to make it
> work.

Ah, yes, thank you.  I missed that.  Fixed now.

>>    <t>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
>                                     ^
>                                     ,

I changed it to another supposedly-unconnected one instead.  Using them
both as adjectives rather than separating out the phrase reads better to
me.

>>    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
>                                           ^^^^^^^^
>                                            (this
>>    article back into a proto-article.)

The parenthetical is a complete sentence and therefore should begin with a
capital letter.

> Yes, but we make a suggestion (explicitly 'pgpverify' now) in the case of
> control messages, but remain devoid of suggestions for cancels.

We can suggest cancel lock.  I almost did, except that it's not widely
deployed like pgpverify is.  There are some implementations, though.

> Perhaps the following alternative wording would convey the sense better:
>
>>>    message.  Accordingly, news servers SHOULD use the same
>>>                                               ^^^^^^^^^^^^
>                                                  apply whatever
>>>    authentication and authorization checks for deciding whether to honor
>>>                                           ^
>                                       they already apply
>>>    a Supersedes header field as they use for cancel control messages.
>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                  in the case of
>
> which has the advantage of being shorter, and gives no implication that
> such checks are normal for cancel messages (which, sadly, they are not).

How about this:

      <section anchor="supersedes" title="The Supersedes Header Field">
        <t>The presence of a Supersedes header field in an article
        requests that the message identifier given in that header field be
        withdrawn in exactly the same manner as if it were the target 
        of a cancel control message.  Accordingly, news servers SHOULD
        apply to a Supersedes header field the same authentication and
        authorization checks as they would apply to cancel control
        messages.  If the Supersedes header field is honored, the news
        server SHOULD take the same actions as it would take when honoring
        a cancel control message for the given target article.</t>

I think inverting the sentence makes it clearer.

-- 
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.14.2/8.14.2) with ESMTP id m8OKAgam028433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 13:10:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OKAgTr028432; Wed, 24 Sep 2008 13:10:42 -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.14.2/8.14.2) with ESMTP id m8OKAVhE028385 for <[e-mail]>; Wed, 24 Sep 2008 13:10:42 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8AED860F85C for <[e-mail]>; Wed, 24 Sep 2008 13:10:31 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 6E79E60F800 for <[e-mail]>; Wed, 24 Sep 2008 13:10:30 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 7DDC2E7924; Wed, 24 Sep 2008 13:10:30 -0700 (PDT)
To: "Usefor WG" <[e-mail]>
Subject: Re: ISSUE:  Length and final dots of newsgroups descriptions.
In-Reply-To: <4E57E0839E9E4A51954B5CD2CD8FA3E1@Iulius> ("Julien =?iso-8859-1?Q?=C9LIE=22's?= message of "Wed\, 24 Sep 2008 19\:22\:54 +0200")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <4E57E0839E9E4A51954B5CD2CD8FA3E1@Iulius>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 24 Sep 2008 13:10:30 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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>

Julien =C9LIE <[e-mail]> writes:

> I wonder whether final dots should not be added to descriptions.

There was general consensus in the group a while back that sacrificing an
occasionally valuable character to fairly pointless punctuation wasn't a
good idea (but also that it wasn't something that should be standardized,
so I think that language moved to USEAGE, if it's in any of our drafts).

--=20
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.14.2/8.14.2) with ESMTP id m8OHN8kW014443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 10:23:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OHN8L4014442; Wed, 24 Sep 2008 10:23:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8OHN6GU014433 for <[e-mail]>; Wed, 24 Sep 2008 10:23:07 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10549 invoked by uid 503); 24 Sep 2008 17:23:08 -0000
Received: from b7.ovh.net (HELO mail181.ha.ovh.net) (213.186.33.57) by 30.mail-out.ovh.net with SMTP; 24 Sep 2008 17:23:08 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 24 Sep 2008 17:22:36 -0000
Received: from aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.112.31.236) by ns0.ovh.net with SMTP; 24 Sep 2008 17:22:34 -0000
Message-ID: <4E57E0839E9E4A51954B5CD2CD8FA3E1@Iulius>
From: =?ISO-8859-15?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: ISSUE:  Length and final dots of newsgroups descriptions.
Date: Wed, 24 Sep 2008 19:22:54 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="ISO-8859-15"; 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
X-Ovh-Tracer-Id: 8600186438900841913
X-Ovh-Remote: 83.112.31.236 (aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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>

Hi,

I wonder whether final dots should not be added to descriptions.

      For your newsgroups file:
      example.admin.info      About the example.* groups (Moderated)

-> About the example.* groups. (Moderated)


      example.moderated         A moderated newsgroup (Moderated)
      example.test              An unmoderated test group

-> with final dots.

Maybe it should also be specified that the length of such descriptions
SHOULD NOT be too long:  a reasonable length not to exceed is 56 characters.


Source:
    ftp://ftp.isc.org/pub/pgpcontrol/FORMAT

group.name<tabs>description.[ (Moderated)]

There should be one or more hard tabs (assume 8 column tabstops) to
get to a description; if the group.name is more than 24 characters,
use just one tab.  The description should start with a capital and end
in a period and not be more than 56 characters (80 - 24) long.  If the
group is moderated, it should have " (Moderated)" following the
period, not counted as part of the length of the description.  The
goal is to keep the total line under 80 columns, so if the group name
is 25 characters long you'd have eight less description characters to
work with.

-- 
Julien ÉLIE

« Tu l'as trop écrasé, César, ce Port-Salut. »



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 m8OHG6Fg013653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 10:16:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OHG6bc013652; Wed, 24 Sep 2008 10:16:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8OHG5fS013645 for <[e-mail]>; Wed, 24 Sep 2008 10:16:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26004 invoked by uid 503); 24 Sep 2008 17:16:06 -0000
Received: from b7.ovh.net (HELO mail181.ha.ovh.net) (213.186.33.57) by 30.mail-out.ovh.net with SMTP; 24 Sep 2008 17:16:06 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 24 Sep 2008 17:15:35 -0000
Received: from aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.112.31.236) by ns0.ovh.net with SMTP; 24 Sep 2008 17:15:33 -0000
Message-ID: <FDD172E722E445F8BCD9252E9BE21220@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Tr: ISSUE: Checkgroups control messages
Date: Wed, 24 Sep 2008 19:15:53 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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
X-Ovh-Tracer-Id: 8481685474164014521
X-Ovh-Remote: 83.112.31.236 (aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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>

Hi Charles,

>>DNS solves the problem by saying "sequence space arithmetic"...
>>meaning if you are within plus half-the-number-range, you can consider
>>the number "greater than", but if you are within minus half-the-number-
>>range, then you consider it less than.
>
> Ah! That might well be an acceptable solution to the run-around of article
> numbers problem, which has just reared its head on the NNTP list.

Well, if your news server does not do any kind of expiration, what do you
once you have exhausted the whole range of article numbers?

ARTICLE 12 -> returns the last 12th article? :)
Ranges would also be tricky!

-- 
Julien ÉLIE

« Il y a trois façons de faire les choses : la bonne, la mauvaise, et la mienne. » 



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 m8OHAJ6s012949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 10:10:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OHAJHf012948; Wed, 24 Sep 2008 10:10:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8OHA7lS012914 for <[e-mail]>; Wed, 24 Sep 2008 10:10:18 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 30864 invoked by uid 503); 24 Sep 2008 17:10:08 -0000
Received: from b7.ovh.net (HELO mail181.ha.ovh.net) (213.186.33.57) by 30.mail-out.ovh.net with SMTP; 24 Sep 2008 17:10:08 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 24 Sep 2008 17:09:36 -0000
Received: from aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.112.31.236) by ns0.ovh.net with SMTP; 24 Sep 2008 17:09:35 -0000
Message-ID: <B4F3927BBA3A4D19A1265D9882A27072@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: No posting flag
Date: Wed, 24 Sep 2008 19:09:56 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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
X-Ovh-Tracer-Id: 8380917431622237625
X-Ovh-Remote: 83.112.31.236 (aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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>

Hi,

I thought it might be worth forwarding this remark from D. Stussy in
news.software.nntp <news:gbbqv3$lcq$[e-mail]>.

> 2)  I have also noticed that some local/regional/special hierarchies gate
> mailing lists in a ONE WAY fashion.  For them, the appropriate moderation
> status in the active file is "n".  Perhaps the "checkgroups" control
> messages should handle this with a "(No Posting)" tag, similar to that of
> "(Moderated)", in the description field.  Group creation should also support
> this.

" (No Posting)" or " (No posting)" maybe should be added to the newgroups line.

Instead of:

      newsgroups-line     = newsgroup-name
                               [ 1*HTAB newsgroup-description ]
                               [ *WSP moderation-flag ]
      moderation-flag     = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")"
                               ; SPACE + case sensitive "(Moderated)"

having status-flag which can be moderation-flag or nopost-flag.

-- 
Julien ÉLIE

« Être raisonnable en toutes circonstances. Il faudrait être fou... »
  (Raymond Devos)



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 m8OGdL9W010340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 09:39:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OGdLHf010339; Wed, 24 Sep 2008 09:39:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8OGd9Tx010316 for <[e-mail]>; Wed, 24 Sep 2008 09:39:20 -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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48da6c92.31e.37 for [e-mail]; Wed, 24 Sep 2008 17:36:34 +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 m8OGaVA6010656 for <[e-mail]>; Wed, 24 Sep 2008 17:36:31 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8OGaUhh010652 for [e-mail]; Wed, 24 Sep 2008 17:36:30 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24907
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Niggles in usepro-draft-11
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Wed, 24 Sep 2008 16:27:01 GMT
Lines: 122
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:

OK, you seem to have covered most of my suggestions, and I have created
Issues for the two that need discussion, as you suggested.

Here are a few remaining niggles.

>> 3.3.  Article History and Duplicate Suppression
>>
>>    o  ............  If this
>>       interval is shorter than the time it takes for an article to
>>       propagate through the network, the agent might reject an article
>>       it had not yet seen, so it ought not be aggressively short. .....
>>                                           ^
>>                                           to

>It's an unusual formulation in general, but I believe the current
>formulation is more grammatically correct.  The subject of the dependent
>clause is "it" and the verb is "be".  If "be" is converted to an
>infinitive, the dependent clause no longer has a verb.

No, the verb in that dependent clause is "ought".

Consider the sentence "You ought to know better." Surely that is
gramatically correct, but it needs the infinitive "to know" to make it
work.

It would be similar in French: "Il vous faut savoir mieux."

>> 3.4.2.  Multiple Injection of Articles

>I now have the following, which makes the handling of Path consistent with
>the current definition of a proto-article.  This is only provisional until
>we resolve handling of the POSTED <diag-keyword> in Path as discussed
>above.

>    <t>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
                                          ^^^^^^^^
                                           (this
>    article back into a proto-article.)  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.

>> 5.4.  The Supersedes Header Field
>>
>>    The presence of a Supersedes header field in an article requests that
>>    the message identifier given in that header field be withdrawn in
>>    exactly the same manner as if it were the target of a cancel control
>>    message.  Accordingly, news servers SHOULD use the same
>>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    authentication and authorization checks for deciding whether to honor
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    a Supersedes header field as they use for cancel control messages.
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    If the Supersedes header field is honored, the news server SHOULD
>>    take the same actions as it would take when honoring a cancel control
>>    message for the given target article.
>>
>> The bit I have marked with ^^^^^^^^ is all fine and dandy, except that
>> the preceding section 5.3 on Cancel Messages make no mention of
>> "authentication and authorization".

>It's covered by section 5.1.

>> However, what is currently said in our section 5.1 is fine (so far as it
>> goes) for Group Control Messages, but has nothing to say of relevance to
>> Cancels and Supersedes.

>How so?  I think this pretty much covers it:

>   Agents acting on control messages SHOULD take steps to authenticate
>   control messages before acting on them, as determined by local
>   authorization policy.  Whether this is done via the use of an
>   unstandardized authentication protocol, by comparison with
>   information obtained through another protocol, by human review, or by
>   some other means is left unspecified by this document.  Further
>   extensions or revisions of this protocol are expected to standardize
>   a digital signature mechanism.

>There isn't anything specific to group control messages there.  Those are,
>stated generally, exactly the same provisions as should apply to cancel
>messages and Supersedes.

Yes, but we make a suggestion (explicitly 'pgpverify' now) in the case of
control messages, but remain devoid of suggestions for cancels.

Perhaps the following alternative wording would convey the sense better:

>>    message.  Accordingly, news servers SHOULD use the same
>>                                               ^^^^^^^^^^^^
                                                 apply whatever
>>    authentication and authorization checks for deciding whether to honor
>>                                           ^
                                      they already apply
>>    a Supersedes header field as they use for cancel control messages.
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 in the case of

which has the advantage of being shorter, and gives no implication that
such checks are normal for cancel messages (which, sadly, they are not).

-- 
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.14.2/8.14.2) with ESMTP id m8OGar9b010168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 09:36:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OGarL5010167; Wed, 24 Sep 2008 09:36:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8OGafho010078 for <[e-mail]>; Wed, 24 Sep 2008 09:36:52 -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 v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48da6c99.406b.1092 for [e-mail]; Wed, 24 Sep 2008 17:36:41 +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 m8OGaVIV010678 for <[e-mail]>; Wed, 24 Sep 2008 17:36:31 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8OGaVgF010673 for [e-mail]; Wed, 24 Sep 2008 17:36:31 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24908
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: ISSUE: Checkgroups control messages
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 24 Sep 2008 16:33:48 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]> Thorfinn <[e-mail]> writes:

>On 23 Sep 2008, at 11:49, Russ Allbery wrote:

>>
>> Thorfinn <[e-mail]> writes:
>>
>>> 640kb should be enough for anyone. Um. :-)
>>>
>>> That is, yes, 32 bit unsigned integer is better, not 15 bit.
>>
>> Just to clarify, the current draft has no limit at all.  I think  
>> it's safe
>> and reasonable to add a limit of 2^32 - 1, but I'm always nervous  
>> about
>> adding limits on values because you never know when you might want  
>> them to
>> be larger later.
>>
>> On the other hand, Julien has a good point that implementers aren't  
>> going
>> to add a bigint implementation just to check sequence numbers.


>*nod* 64 bit is becoming fairly prevalent, and that should certainly  
>be enough.

>That said - the DNS world is pretty used to using a 32 bit integer  
>circle for comparison.

>Looking at the current USEPRO text... *ponder* Serial number MUST  
>increase.  That is definitely a problem - you certainly can run out of  
>32 bit integer.  It's not all that likely, but it's certainly possible.

Well, it has taken 30 years for a few heavily populated groups to come
within sight of overflowing the 32-bit article numbers, and the number of
checkgroups messages sent is many orders of magnitude less than what such
groups have seen. So I think 32 bits is fine. People still regard 32 bits
as the 'normal' length of an integer, even though modern hardware is able
to cope with 64bit, especially for addresses.

-- 
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.14.2/8.14.2) with ESMTP id m8OGaaUc010069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 09:36:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OGaaTQ010068; Wed, 24 Sep 2008 09:36:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8OGaYeK010059 for <[e-mail]>; Wed, 24 Sep 2008 09:36:35 -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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.301) id 48da6c93.3984.f5f for [e-mail]; Wed, 24 Sep 2008 17:36:35 +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 m8OGaWwV010686 for <[e-mail]>; Wed, 24 Sep 2008 17:36:32 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8OGaWi2010683 for [e-mail]; Wed, 24 Sep 2008 17:36:32 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24909
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: ISSUE: Checkgroups control messages
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CA16CE52C5DC4BD698ADE845E45573D7@Iulius> <[e-mail]>
Date: Wed, 24 Sep 2008 16:36:20 GMT
Lines: 20
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]> Thorfinn <[e-mail]> writes:

>DNS solves the problem by saying "sequence space arithmetic"...  
>meaning if you are within plus half-the-number-range, you can consider  
>the number "greater than", but if you are within minus half-the-number- 
>range, then you consider it less than.

Ah! That might well be an acceptable solution to the run-around of article
numbers problem, which has just reared its head on the NNTP list.

-- 
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.14.2/8.14.2) with ESMTP id m8OGCOaP007889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 09:12:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OGCOZG007888; Wed, 24 Sep 2008 09:12:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8OGC3vH007811 for <[e-mail]>; Wed, 24 Sep 2008 09:12:15 -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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.301) id 48da66d5.5506.1ba0 for [e-mail]; Wed, 24 Sep 2008 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 m8OGC2gp008192 for <[e-mail]>; Wed, 24 Sep 2008 17:12:02 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8OGC27N008189 for [e-mail]; Wed, 24 Sep 2008 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24905
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Niggles in usepro-draft-11
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Wed, 24 Sep 2008 15:57:37 GMT
Lines: 62
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:

>> 3.4.1.  Proto-articles
>>
>>    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 MUST NOT contain a "POSTED" <diag-keyword>; and any
>>    of the following mandatory header fields MAY be omitted: Message-ID,
>>    Date, and Path.  In all other respects, a proto-article MUST be a
>>    valid Netnews article.  In particular, the header fields which may be
>>    omitted MUST NOT be present with invalid content.
>>
>> I am worried about that 'MUST NOT contain a "POSTED" <diag-keyword>'. It
>> would cause no interoperability problems and cause no significant harm,
>> and hence a "MUST" cannot be justified under RFC 2119. Nothing breaks if
>> two "POSTEDs appear in one Path.  Indeed, it could arise legitimately in
>> multiple injection "after the fact", and in other exotic gatewaying
>> situations.
>>
>> Yes, some s[pc]ammers will preload the Path so as to disguise the true
>> origin of an article (which is indeed why POSTED was invented), but that
>> is a matter to be taken up by the netkops rather than the protocols. And
>> I would prefer to preserve all evidence left over from previous Paths in
>> order to facilitate bebugging of broken gateways, etc.
>>
>> So, at the most, it ought to be a SHOULD, and I would be happy to omit
>> it altogether. Note that whatever change is made here, corresponding
>> changes would be needed in 3.4.2 and 3.5.2 Step 2.

>This is also a protocol change and should therefore be a separate issue.
>I'm inclined to agree with you that MUST isn't justified here and SHOULD
>is more appropriate.  I think we already talked about this before,
>although I haven't gone back and looked.

OK, here it is. I note that you agree that MUST is too strong.

However, I think SHOULD (and perhaps even MAY) is too strong. The protocol
use to prevent loops is not affected by this change. But the Path is also
important for diagnosing the cause of loops (not necessarily
non-terminating ones) such as those caused by peculiar gatewaying, and for
spotting trollers who try to disguise the source of their articles.

So seeing two 'POSTED's in a Path should immediately raise alarm bells
(even though it may occasionally turn out to have a benign explanation).
But if duplicate 'POSTED's are removed, then no alarm bells will be
heard. So leave them in, and let the Debuggers and the Netkops take care
of them.

In either case, there would be consequential changes elsewhere, as noted.

-- 
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.14.2/8.14.2) with ESMTP id m8OGCFVI007853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8OGCFrW007852; Wed, 24 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8OGC39A007809 for <[e-mail]>; Wed, 24 Sep 2008 09:12:15 -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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.301) id 48da66d5.4084.705 for [e-mail]; Wed, 24 Sep 2008 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 m8OGC1qI008184 for <[e-mail]>; Wed, 24 Sep 2008 17:12:01 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8OGC2Zw008181 for [e-mail]; Wed, 24 Sep 2008 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24904
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: ISSUE: posting agents MAY add Injection-Date
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Wed, 24 Sep 2008 15:45:03 GMT
Lines: 59
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:

>> 3.2.1.  Constructing the Path Header Field

>> We are now allowing (sometimes even requiring) posting agents to insert
>> an Injection Date.  Whereas clueful multiple injectors will probably do
>> this correctly, I am worried that incompetent MUA implementors (or which
>> there are many :-( ) will do it wrongly.
>>
>> On the other hand, now it seems to have been decided only to allow
>> injection agents to insert it in limited situations, it is desirable
>> that posting agents should be encouraged (somewhere between MAY and
>> SHOULD) to do it routinely (otherwise this new header will never catch
>> on). So I suggest:
>>    
>>    When the proto-article already contains both Message-ID and Date
>>    header fields, posting agents MAY, as part of the injection process
>>    (i.e. immediately before passing it to an injection agent), add an
>>    Injection-Date header field to that proto-article (a useful practice,
>>    since it provides diagnostic information and can imrove propagation).
>>    Moreover, 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. and they MUST do so if the
>>    proto-article is being submitted to more than one injecting agent;
>>    see Section 3.4.2.

>This is a protocol change, so I'd rather have you raise this one as a
>separate issue so that we can go through more process on addressing it.
>Personally, I'd prefer for most posting agents to not supply Message-ID,
>since the news server can generally do a better job, but I know that isn't
>always realistic.  Failing that, what you're saying does make sense to me.

OK, here it is, and I see that you partially agree.

My point is that many News User Agents do double duty as Email User
Agents. They routinely create Message-IDs for email messages, and hence
are likely to do the same for news articles. Granted they often do it
wrong (at one stage, my email was going out with Message-IDs based on
'localhost' :-( ), but that is the way it is, even if I might agree that
servers might indeed do the job better. So in that case, it is now likely
that the majority or articles will never receive an Injection-Date (which
is why I didn't like the IR formulation).

My proposal above is intended to mitigate this by encouraging ("MAY") user
agents to insert Injection-Date themselves if they are already doing
Message-ID.

-- 
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.14.2/8.14.2) with ESMTP id m8O6Mqr4038657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 23:22:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8O6Mq0C038656; Tue, 23 Sep 2008 23:22:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8O6Mfmd038641 for <[e-mail]>; Tue, 23 Sep 2008 23:22:51 -0700 (MST) (envelope-from [e-mail])
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id m8O6MSv7024395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 23:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1222237359; x=1222323759; bh=uD0ZoUYotHwhvgKHyHCSvBsXzKnoFMlqiOF9 riTVR7U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=n3ALCqGk5YkHzrTcfZr074mnNj qCVtv/Weky9ocs4Sq4gb93ooe5Wc1r6IaMD9FmoPmrnLglFxzcybUqX+oqhw8xGcAkv AWVw7RiucrwkkaKGZQvdqevq2YOq7nSIvjeX5YDHGK4ovL4HCwLDkI+dazz3tabiwez swCiKOHJLGY=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=1qh6D2FN7LqbrmyNN8hqw0gvKgzuoVmedJ0KR+x2LI+oT0IQJKoU4/y1jW2h3N0m1 b8Tx/BUWKfmpUwN67p/FvzaYIEa7Gi+lE2D7Ehmpa8AF7nr2RCjawZUVX++ugTtFSYo 4QMCXxLDDfErEo/7EfM+1O9/VOgHOQ07B2lAZTo=
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 23 Sep 2008 23:22:13 -0700
To: [e-mail]
From: SM <[e-mail]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard
Cc: [e-mail], Russ Allbery <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 19:44 21-09-2008, Russ Allbery wrote:
>(I am not a subscriber to the ietf list and would appreciate copies of
>replies.)

Cc as requested.

>The message is still meaningful; however, it violates a SHOULD in RFC 2822
>(well, sort of, depending on how you interpret "belong" in the case of an
>address that by definition doesn't belong to anyone).

The message may be meaningful for a broadcast but not for two-way 
communication.  For example, if you were reading this mailing list 
and replying to this message through Netnews, I would not be able to 
send you a reply.

As obfuscated mailboxes such as example@example dot nospam dot com 
are commonly used in Netnews, proposing ".invalid" as a suffix at 
least ensures that the mailboxes is actually invalid.

>I think a gateway has two acceptable choices: preserve the From header and
>violate the SHOULD, or replace the From header with some contact address
>for the gateway (a copy of the Sender header, for example).  From a
>quality of implementation perspective, as a consumer of a gateway, I'd
>much prefer the former behavior.

In this case, it may be better to violate the "SHOULD" and provide an 
valid mailbox to which replies can be sent (second choice).

>Regardless, however, news-to-mail gateways are not standardized by this
>draft, so I don't think this is an issue for this document.  See 3.10.1:
>
>    From the perspective of Netnews, an outgoing gateway is just a
>    special type of reading agent.  The exact nature of what the outgoing
>    gateway will need to do to articles depends on the medium to which
>    the articles are being gated.
>
>I think work on a best-practices guide for gateways would be great, but I
>think the e-mail side of the gateway is outside the scope of this
>document.

Section 3.10.1 mentions practices that are encouraged.  As the 
document "creates" the problem, it may be good for the document to 
address it especially given the different interpretations of 
"meaningful".  I suggest the following in Section 3.10.1:

    5.  The message should be compliant with the specifications for 
that medium.

>This wouldn't be a gateway; it would be transmission of a news article
>through e-mail.  See 3.10:

I suggested that as an alternative to work around the issue if you 
prefer not to fix the invalid address.

>Yes, thank you.  I now have:
>
>    2.  The proto-article is sent as an email with the addition of any
>        header fields required for an email as defined in [RFC2822], and
>        possibly with the addition of other header fields conventional in
>        email such as To and Received.  The existing Message-ID header
>        field SHOULD be retained.

I don't see the need for specifying additional headers.  You could 
keep it simple with the following:

    2.  The proto-article is sent as an email with the addition of any
        header fields required for an email as defined in [RFC2822].
        The existing Message-ID header field SHOULD be retained.

>Hm.  Well, if we were to add a new header field, it really needs to go
>into USEFOR and not here, since USEFOR is the canonical document for
>header fields for netnews articles.  USEFOR has already gone through Last
>Call, however.
>
>I can see your point here, but I'm not sure the lack is particularly
>important.  I'd really rather not see us make further changes to USEFOR;
>generally an X-* header is used for this and is adequate in practice.

Each implementation might use a different header field name.  It's 
might become a problem in future.

>Well, this is very explicitly an example based on a specific
>implementation, which happens to use an X-* header.  But I can see where
>this would be less than ideal.  However, as above, I'm hesitant to invent
>a new header for this purpose and add the necessary machinery for
>registering it when there is no standardized existing practice and it's
>not clear what issues are involved in picking a header field,
>standardizing its format, and so forth.

Implementors will likely pick X-Gateway as you mentioned that header 
name in the example.  Once people start using specific headers, it's 
difficult to depreciate them in favor of some standardized format.

Regards,
-sm 



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 m8N8JYuL027942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 01:19:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8N8JY6u027941; Tue, 23 Sep 2008 01:19:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8N8JWOs027934 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 23 Sep 2008 01:19:33 -0700 (MST) (envelope-from [e-mail])
Received: from [10.134.51.32] (sys-fw1.off.connect.com.au [192.94.41.120]) by tertius.net.au (Postfix) with ESMTP id C1F198080B9 for <[e-mail]>; Tue, 23 Sep 2008 18:19:31 +1000 (EST)
Message-Id: <[e-mail]>
From: Thorfinn <[e-mail]>
To: Usefor WG <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: ISSUE: Checkgroups control messages
X-Priority: 3
Date: Tue, 23 Sep 2008 18:19:30 +1000
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CA16CE52C5DC4BD698ADE845E45573D7@Iulius> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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 23 Sep 2008, at 17:02, Thorfinn wrote:
>
> 1. the current text: "unsigned integer there is no limit" - in which  
> case implementers can actually trim leading zeros and do a straight  
> asciibetical comparison, no bigint library required.

I lied - string length *then* asciibetical comparison for strings of  
same length.  :-)

-- 
<a href="http://tertius.net.au/~thorfinn/">[e-mail]</a>
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 m8N736kW019829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 00:03:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8N7368b019828; Tue, 23 Sep 2008 00:03:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8N72r1V019793 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 23 Sep 2008 00:03:05 -0700 (MST) (envelope-from [e-mail])
Received: from [10.134.51.32] (sys-fw1.off.connect.com.au [192.94.41.120]) by tertius.net.au (Postfix) with ESMTP id D30588080B9; Tue, 23 Sep 2008 17:02:52 +1000 (EST)
From: Thorfinn <[e-mail]>
To: =?ISO-8859-1?Q?Julien_=C9LIE?= <[e-mail]>
In-Reply-To: <CA16CE52C5DC4BD698ADE845E45573D7@Iulius>
Subject: Re: ISSUE: Checkgroups control messages
X-Priority: 3
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <CA16CE52C5DC4BD698ADE845E45573D7@Iulius>
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 23 Sep 2008 17:02:51 +1000
Cc: "Usefor WG" <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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 23 Sep 2008, at 16:20, Julien =C9LIE wrote:
> Hi Thorfinn,
>
>> Looking at the current USEPRO text... *ponder* Serial number MUST  =20=

>> increase.  That is definitely a problem - you certainly can run out =20=

>> of  32 bit integer.  It's not all that likely, but it's certainly =20
>> possible.
>
> That is why I also suggested a mechanism (yet to be defined) to =20
> *reset*
> the counter.  But the main problem is that it will cause problems to
> a news server which does not receive the message of reset...
> So it is maybe a bad idea.

Yep - reset doesn't work, for exactly that reason.  We know that =20
relying on a single message to propagate for future correctness is =20
poor behaviour, especially since we know that message propagation =20
isn't even guaranteed to be in sequence, let alone delivered at all.

>> I'd be uncomfortable putting in a 32 bit limit unless we also =20
>> change  the text to deal with serial comparison in the same way =20
>> that DNS  serial numbers are compared.
>>
>> =46rom RFC 1035:
>> SERIAL The unsigned 32 bit version number of the original copy of =20
>> the  zone. Zone transfers preserve this value. This value wraps and =20=

>> should  be compared using sequence space arithmetic.
>
> I reckon it is the best solution to adopt.
> Say that there is a 32 bit limit and that serial numbers SHOULD be =20
> used
> in case the checkgroups sender does not want to run out of available =20=

> numbers.
> It is up to him if he does not want to use serial numbers.


DNS solves the problem by saying "sequence space arithmetic"... =20
meaning if you are within plus half-the-number-range, you can consider =20=

the number "greater than", but if you are within minus half-the-number-=20=

range, then you consider it less than.

e.g. for a sequence space of decimal 1000:

if your number is 250, then anything up to 750 is considered "greater =20=

than", but from 751 - 249 is considered "less than".  Or, if your =20
number is 999, then anything up to 499 is considered "greater than", =20
and 500-998 is considered "less than".  (I might be off-by-one, but it =20=

sort of doesn't matter - close enough is good enough for this purpose.)

So there's "effectively" a reset - because if you keep incrementing by =20=

small amounts, you eventually come around to the other side of the =20
sequence space, and that "resets" it for you.

I note that a few DNS implementations do actually fail to implement =20
this correctly... but at least the standard says something useful, and =20=

most DNS servers do implement handling of SERIAL changes correctly.

So I'd either go with:

1. the current text: "unsigned integer there is no limit" - in which =20
case implementers can actually trim leading zeros and do a straight =20
asciibetical comparison, no bigint library required.

2. unsigned 32 bit number, wrapping and compared using sequence space =20=

arithmetic.

--=20
<a href=3D"http://tertius.net.au/~thorfinn/">[e-mail]</a>
To err is human, to moo bovine.  -- 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 m8N6Ko3r014402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 23:20:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8N6Kolj014401; Mon, 22 Sep 2008 23:20:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 26.mail-out.ovh.net (26.mail-out.ovh.net [91.121.27.225]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8N6KbEV014340 for <[e-mail]>; Mon, 22 Sep 2008 23:20:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 11476 invoked by uid 503); 23 Sep 2008 06:20:57 -0000
Received: from b7.ovh.net (HELO mail53.ha.ovh.net) (213.186.33.57) by 26.mail-out.ovh.net with SMTP; 23 Sep 2008 06:20:57 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 23 Sep 2008 06:20:37 -0000
Received: from aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.112.31.236) by ns0.ovh.net with SMTP; 23 Sep 2008 06:20:34 -0000
Message-ID: <CA16CE52C5DC4BD698ADE845E45573D7@Iulius>
From: =?iso-8859-1?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Tue, 23 Sep 2008 08:20:25 +0200
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
X-Ovh-Tracer-Id: 9994050523623652793
X-Ovh-Remote: 83.112.31.236 (aaubervilliers-151-1-58-236.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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>

Hi Thorfinn,

>>> 640kb should be enough for anyone. Um. :-)

"I have to say in 1981 making those decisions I felt like I was providing
enough freedom for ten years, that is the move from 64k to 640k felt like
something that would last a great deal of time." (said in 1989 by Bill Gates)

"It [640K] was ten times what we had before.  But to my surprise, we ran out
of that address base for applications within - oh five or six years people
were complaining." (said in 1993 by Bill Gates)



> Looking at the current USEPRO text... *ponder* Serial number MUST  increase.  That is definitely a problem - you certainly can run 
> out of  32 bit integer.  It's not all that likely, but it's certainly possible.

That is why I also suggested a mechanism (yet to be defined) to *reset*
the counter.  But the main problem is that it will cause problems to
a news server which does not receive the message of reset...
So it is maybe a bad idea.



> I'd be uncomfortable putting in a 32 bit limit unless we also change  the text to deal with serial comparison in the same way that 
> DNS  serial numbers are compared.
>
> From RFC 1035:
> SERIAL The unsigned 32 bit version number of the original copy of the  zone. Zone transfers preserve this value. This value wraps 
> and should  be compared using sequence space arithmetic.

I reckon it is the best solution to adopt.
Say that there is a 32 bit limit and that serial numbers SHOULD be used
in case the checkgroups sender does not want to run out of available numbers.
It is up to him if he does not want to use serial numbers.

-- 
Julien ÉLIE

« -- C'est une bonne situation ça, scribe ?
  -- Oh, c'est une situation assise. » (Astérix)



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 m8N2FVaP091122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 19:15:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8N2FVP6091121; Mon, 22 Sep 2008 19:15:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8N2FSYS091110 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 22 Sep 2008 19:15:30 -0700 (MST) (envelope-from [e-mail])
Received: from [10.134.51.32] (sys-fw1.off.connect.com.au [192.94.41.120]) by tertius.net.au (Postfix) with ESMTP id A6FC98080B9; Tue, 23 Sep 2008 12:15:27 +1000 (EST)
Cc: "Usefor WG" <[e-mail]>
Message-Id: <[e-mail]>
From: Thorfinn <[e-mail]>
To: Russ Allbery <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: ISSUE: Checkgroups control messages
Date: Tue, 23 Sep 2008 12:15:26 +1000
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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 23 Sep 2008, at 11:49, Russ Allbery wrote:

>
> Thorfinn <[e-mail]> writes:
>
>> 640kb should be enough for anyone. Um. :-)
>>
>> That is, yes, 32 bit unsigned integer is better, not 15 bit.
>
> Just to clarify, the current draft has no limit at all.  I think  
> it's safe
> and reasonable to add a limit of 2^32 - 1, but I'm always nervous  
> about
> adding limits on values because you never know when you might want  
> them to
> be larger later.
>
> On the other hand, Julien has a good point that implementers aren't  
> going
> to add a bigint implementation just to check sequence numbers.


*nod* 64 bit is becoming fairly prevalent, and that should certainly  
be enough.

That said - the DNS world is pretty used to using a 32 bit integer  
circle for comparison.

Looking at the current USEPRO text... *ponder* Serial number MUST  
increase.  That is definitely a problem - you certainly can run out of  
32 bit integer.  It's not all that likely, but it's certainly possible.

You're not likely to run out of 64 bit integer, provided you aren't  
silly and start somewhere near the very top of the integer space.

I'd be uncomfortable putting in a 32 bit limit unless we also change  
the text to deal with serial comparison in the same way that DNS  
serial numbers are compared.

 From RFC 1035:
SERIAL The unsigned 32 bit version number of the original copy of the  
zone. Zone transfers preserve this value. This value wraps and should  
be compared using sequence space arithmetic.


-- 
<a href="http://tertius.net.au/~thorfinn/">[e-mail]</a>
~/ For those who've come across the seas, ~/ We've boundless plains to  
share, ~/
~/   With courage let us all combine,     ~/    To Advance Australia  
Fair.    ~/
      -- The end of the second verse of the Australian National  
Anthem. --




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 m8N1nlrB088231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 18:49:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8N1nlro088230; Mon, 22 Sep 2008 18:49:47 -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.14.2/8.14.2) with ESMTP id m8N1naMG088208 for <[e-mail]>; Mon, 22 Sep 2008 18:49:46 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4123560EB60 for <[e-mail]>; Mon, 22 Sep 2008 18:49:36 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 25EA960EB5D for <[e-mail]>; Mon, 22 Sep 2008 18:49:35 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id AFA69E7924; Mon, 22 Sep 2008 18:49:35 -0700 (PDT)
To: "Usefor WG" <[e-mail]>
Subject: Re: ISSUE: Checkgroups control messages
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Tue\, 23 Sep 2008 11\:46\:58 +1000")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Mon, 22 Sep 2008 18:49:35 -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>

Thorfinn <[e-mail]> writes:

> 640kb should be enough for anyone. Um. :-)
>
> That is, yes, 32 bit unsigned integer is better, not 15 bit.

Just to clarify, the current draft has no limit at all.  I think it's safe
and reasonable to add a limit of 2^32 - 1, but I'm always nervous about
adding limits on values because you never know when you might want them to
be larger later.

On the other hand, Julien has a good point that implementers aren't going
to add a bigint implementation just to check sequence numbers.

-- 
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.14.2/8.14.2) with ESMTP id m8N1lOZA088048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 18:47:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8N1lOVp088047; Mon, 22 Sep 2008 18:47:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8N1lBnu088027 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 22 Sep 2008 18:47:23 -0700 (MST) (envelope-from [e-mail])
Received: from [10.134.51.32] (sys-fw1.off.connect.com.au [192.94.41.120]) by tertius.net.au (Postfix) with ESMTP id AE4E78080B9; Tue, 23 Sep 2008 11:47:04 +1000 (EST)
Cc: "Usefor WG" <[e-mail]>
Message-Id: <[e-mail]>
From: Thorfinn <[e-mail]>
To: Russ Allbery <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: ISSUE: Checkgroups control messages
Date: Tue, 23 Sep 2008 11:46:58 +1000
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
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 22 Sep 2008, at 19:33, Russ Allbery wrote:

>
> "Charles Lindsey" <[e-mail]> writes:
>> Julien =C9LIE <[e-mail]> wrote:
>
>>> I do not think it wise to limit this number to 32768 because one =20
>>> could
>>> not use DNS serial numbers (which are practical).  2^31=3D2147483648
>>> would be better, at least.  It could be said that implementations
>>> should except <chksernr> arguments to be a 32-bit integer.  And that
>>> the (unsigned) integer should be less than 2^32.
>
>> Yes, I agree that any number expressed in 32 bit would be better. Can
>> Russ quietly slip it in?
>
> It seems like a reasonable change to me, but I'd like to get more =20
> opinions
> from the working group just to be sure.


640kb should be enough for anyone. Um. :-)

That is, yes, 32 bit unsigned integer is better, not 15 bit.

--=20
<a href=3D"http://tertius.net.au/~thorfinn/">[e-mail]</a>
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 m8M9XtGt095089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 02:33:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M9Xt8l095088; Mon, 22 Sep 2008 02:33:55 -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.14.2/8.14.2) with ESMTP id m8M9Xcvk095067 for <[e-mail]>; Mon, 22 Sep 2008 02:33:54 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9A5912D6ECE for <[e-mail]>; Mon, 22 Sep 2008 02:33:38 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 7D4FE2D6ADD for <[e-mail]>; Mon, 22 Sep 2008 02:33:38 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3A7FDE791A; Mon, 22 Sep 2008 02:33:38 -0700 (PDT)
To: "Usefor WG" <[e-mail]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Mon\, 22 Sep 2008 10\:07\:36 +0100")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <677A58E1687B42AF841127606D0CAB2A@Iulius> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Mon, 22 Sep 2008 02:33:38 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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:
> Julien =C9LIE <[e-mail]> wrote:

>> I do not think it wise to limit this number to 32768 because one could
>> not use DNS serial numbers (which are practical).  2^31=3D2147483648
>> would be better, at least.  It could be said that implementations
>> should except <chksernr> arguments to be a 32-bit integer.  And that
>> the (unsigned) integer should be less than 2^32.

> Yes, I agree that any number expressed in 32 bit would be better. Can
> Russ quietly slip it in?

It seems like a reasonable change to me, but I'd like to get more opinions
from the working group just to be sure.

--=20
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.14.2/8.14.2) with ESMTP id m8M97siQ091690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 02:07:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M97sjh091689; Mon, 22 Sep 2008 02:07:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8M97gBn091634 for <[e-mail]>; Mon, 22 Sep 2008 02:07:53 -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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48d7605d.1ab6.767; Mon, 22 Sep 2008 10:07:41 +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 m8M97aLN018870; Mon, 22 Sep 2008 10:07:37 +0100 (BST)
Date: Mon, 22 Sep 2008 10:07:36 +0100
To: =?iso-8859-1?Q?Julien_=C9LIE?= <[e-mail]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
From: "Charles Lindsey" <[e-mail]>
Cc: "Usefor WG" <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
References: <677A58E1687B42AF841127606D0CAB2A@Iulius>
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>
In-Reply-To: <677A58E1687B42AF841127606D0CAB2A@Iulius>
User-Agent: Opera Mail/9.25 (SunOS)
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 Fri, 19 Sep 2008 21:32:33 +0100, Julien ÉLIE <[e-mail]>  
wrote:

> Hi Charles,
>
> Your address at clw.cs.man.ac.uk does not work for me:
>     Remote host said: 550 relay not permitted

That address has not worked for many years past.
>
>>> * If I have a hierarchy like this one:
>>>    fr.bienvenue
>>>    fr.test
>>> and if another administrator is in charge of the sub-hierarchy
>>> fr.autres, with for instance:
>>>    fr.autres
>>>    fr.autres.fiction
>>>    fr.autres.histoires
>>> how can he specify in the Control: header that his checkgroups
>>> contains fr.autres?
>>>    Control: checkgroups fr.autres #1
>>> means fr.autres.* and does not create fr.autres (which I do not
>>> want in my own hierarchy).
>>
>> That is correct. I think the term "sub-hiererchy" is defined as a set of
>> groups with a common prefix (ending in '.'), and so does not include its
>> own root. So it would be up to the administrator of fr.* to include
>> "fr.autres" in HIS checkgroups.
>
> I think USEPRO should not do so something which leads sub-hierarchies
> not to be self-managed:  they should not lay on the checkgroups of the
> main hierarchy in case the root of the sub-hierarchy is a valid newsgroup
> (which is not a root for the super-hierarchy).

Neither the fr.autres.* subhierarchy nor the group fr.autres can exist at  
all without the agreement of the administrators of fr.*, so I see no  
problem in agreeing with the fr.* administrator to handle the rare cases  
in which fr.autres needs some amendment. Too much copmplication in the  
chackgroups rules. So I do not want to change it (if any other USEPRO  
member wants it changed, then he will have to speak up).
>
>
>> The chkscope parameter was invented for the benefit of the de.alt.*
>> hierachy (which is used as an example in our draft). I don't think the
>> individual group de.alt actually exists, but the wording surrounding  
>> that
>> example seems to confirm my interpretation.
>
> I understand that the <chkscope> parameter was invented for de.alt.*
> but there is also cn.bbs.* in the same case.  (fido.* groups are
> almost defunct.)

Yes, I was aware of the similar cn.bbs.* case.

> And what strikes me most is that USEPRO sticks to the behaviour of
> de.alt.* (where de.alt is not a newsgroup) and do not try to be
> more general.
>
>
>>>   The <chksernr> argument may be any positive integer.
>>> Could it be better specified what should look like this integer?
>>> Especially, why not suggest something like DNS serial numbers
>>> #2008090701?  Why not limit the size of this integer (32 bits?)
>>> Suppose that I put a 448-digit number, I am not sure news servers
>>> will manage to save it and compare it with the next one.

>>
>> I wouldn't want to specify its format any further, but we might insist
>> that the integer should be less that 32768, or somesuch.
>
> I do not think it wise to limit this number to 32768 because one
> could not use DNS serial numbers (which are practical).
> 2^31=2147483648 would be better, at least.
> It could be said that implementations should except <chksernr> arguments
> to be a 32-bit integer.  And that the (unsigned) integer should be less
> than 2^32.
>

Yes, I agree that any number expressed in 32 bit would be better. Can Russ  
quietly slip it in?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [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.14.2/8.14.2) with ESMTP id m8M2irDS066268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 19:44:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M2irqd066267; Sun, 21 Sep 2008 19:44:53 -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.14.2/8.14.2) with ESMTP id m8M2iq39066260 for <[e-mail]>; Sun, 21 Sep 2008 19:44:52 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 710AC2D6A50; Sun, 21 Sep 2008 19:44:52 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id B7D9F2D6D6B; Sun, 21 Sep 2008 19:44:51 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3C1A9E7AB7; Sun, 21 Sep 2008 19:44:51 -0700 (PDT)
To: SM <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Sat\, 06 Sep 2008 08\:36\:29 -0700")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Sun, 21 Sep 2008 19:44:51 -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>

(I am not a subscriber to the ietf list and would appreciate copies of
replies.)

SM <[e-mail]> writes:

> Section 3.4 of this I-D states that:
>
>   "Contrary to [RFC2822], which implies that the mailbox or mailboxes in
>    the From header field should be that of the poster or posters, a
>    poster who does not, for whatever reason, wish to use his own mailbox
>    MAY use any mailbox ending in the top level domain ".invalid"
>    [RFC2606]."
>
> The use of an invalid email address for the author can be a problem if the
> message goes through a news-to-mail gateway.  Section 3.10.1 (Duties of an
> Outgoing Gateway) doesn't mention what should be done in such a case.
> Section 3.6.2 of RFC 2822 mentions that:
>
>   "In all cases, the "From:" field SHOULD NOT contain any mailbox that
>    does not belong to the author(s) of the message."
>
> Should such messages be discarded by a news-to-mail gateway as they are
> not meaningful in that medium?

The message is still meaningful; however, it violates a SHOULD in RFC 2822
(well, sort of, depending on how you interpret "belong" in the case of an
address that by definition doesn't belong to anyone).

I think a gateway has two acceptable choices: preserve the From header and
violate the SHOULD, or replace the From header with some contact address
for the gateway (a copy of the Sender header, for example).  From a
quality of implementation perspective, as a consumer of a gateway, I'd
much prefer the former behavior.

Regardless, however, news-to-mail gateways are not standardized by this
draft, so I don't think this is an issue for this document.  See 3.10.1:

   From the perspective of Netnews, an outgoing gateway is just a
   special type of reading agent.  The exact nature of what the outgoing
   gateway will need to do to articles depends on the medium to which
   the articles are being gated.

I think work on a best-practices guide for gateways would be great, but I
think the e-mail side of the gateway is outside the scope of this
document.

> That could be avoided by encapsulating the message in a new message and
> sending it with Content-Type application/news-transmission.

This wouldn't be a gateway; it would be transmission of a news article
through e-mail.  See 3.10:

   A gateway transforms an article into the native message format of
   another medium, or translates the messages of another medium into
   news articles, or transforms articles into proto-articles for
   injection into a separate Netnews network.  Encapsulation of a news
   article into a message of MIME type application/news-transmission, or
   the subsequent undoing of that encapsulation, is not gatewaying,
   since it involves no transformation of the article.

> In Section 3.5.1:
>
>   "The proto-article is sent as an email with the addition of any
>    header fields (such as a To header field) required for an email."
>
> The To header field is not required; the From header is.  I suggest:
>
>    The proto-article is sent as an email with the addition of any
>    header fields required for an email as defined in RFC2822.

Yes, thank you.  I now have:

   2.  The proto-article is sent as an email with the addition of any
       header fields required for an email as defined in [RFC2822], and
       possibly with the addition of other header fields conventional in
       email such as To and Received.  The existing Message-ID header
       field SHOULD be retained.

> Section 3.10.2 recommends the following for an incoming gateway:
>
>  "If the original message already had a Sender header field, it SHOULD be
>   renamed so that its contents can be preserved."
>
> The draft doesn't specify to what the header should be renamed.  I
> suggest creating a new header field for it.
>
>   If the original message already had a Sender header field, it SHOULD be
>   renamed to original-sender so that its contents can be preserved.
>
>     original-sender          =   "Original-Sender:" mailbox CRLF
>
> A request to IANA to update the the Permanent Message Header Field
> Repository with the following is required:
>
>    Header field name:  Original-Sender
>    Applicable protocol:  Netnews
>    Status:  standard
>    Author/Change controller:  IETF
>    Specification document(s):  This document (section 3.10.2)

Hm.  Well, if we were to add a new header field, it really needs to go
into USEFOR and not here, since USEFOR is the canonical document for
header fields for netnews articles.  USEFOR has already gone through Last
Call, however.

I can see your point here, but I'm not sure the lack is particularly
important.  I'd really rather not see us make further changes to USEFOR;
generally an X-* header is used for this and is adequate in practice.

> In Section 3.10.3, it is mentioned that:
>
>  "The news-to-mail gateway adds an X-Gateway header field to all
>   messages it generates."
>
> It may be better to depreciate the use of X- headers.

Well, this is very explicitly an example based on a specific
implementation, which happens to use an X-* header.  But I can see where
this would be less than ideal.  However, as above, I'm hesitant to invent
a new header for this purpose and add the necessary machinery for
registering it when there is no standardized existing practice and it's
not clear what issues are involved in picking a header field,
standardizing its format, and so forth.

One of the problems is that the working group is very low on resources for
taking on much more work at this point.

-- 
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.14.2/8.14.2) with ESMTP id m8M2hB5G066188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 19:43:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M2hBWR066187; Sun, 21 Sep 2008 19:43: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.14.2/8.14.2) with ESMTP id m8M2hBmX066181 for <[e-mail]>; Sun, 21 Sep 2008 19:43:11 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E862860E9B2 for <[e-mail]>; Sun, 21 Sep 2008 19:43:10 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 72C3C60E934 for <[e-mail]>; Sun, 21 Sep 2008 19:43:10 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6DFF8E7AB7; Sun, 21 Sep 2008 19:43:10 -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, 21 Sep 2008 19:43:10 -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, September 21, 2008 @ 19:43:09
  Author: eagle
Revision: 5046

To is not required for e-mail, so don't claim it is.  Mention in the
forwarding method for moderated groups that doesn't use encapsulation
that various other headers not required for e-mail may be added.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-22 02:11:06 UTC (rev 5045)
+++ docs/usefor/usepro.xml	2008-09-22 02:43:09 UTC (rev 5046)
@@ -898,9 +898,11 @@
               transport through email.</t>
 
               <t>The proto-article is sent as an email with the addition
-              of any header fields (such as a To header field) required
-              for an email.  The existing Message-ID header field SHOULD
-              be retained.</t>
+              of any header fields required for an email as defined in
+              <xref target="RFC2822" />, and possibly with the addition of
+              other header fields conventional in email such as To and
+              Received.  The existing Message-ID header field SHOULD be
+              retained.</t>
             </list>
           </t>
 



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 m8M2B9HO064753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 19:11:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M2B9iP064752; Sun, 21 Sep 2008 19:11:09 -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.14.2/8.14.2) with ESMTP id m8M2B8kX064746 for <[e-mail]>; Sun, 21 Sep 2008 19:11:08 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E6F360EA58 for <[e-mail]>; Sun, 21 Sep 2008 19:11:08 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 72EDD60E9B2 for <[e-mail]>; Sun, 21 Sep 2008 19:11:07 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6EF71E7AA9; Sun, 21 Sep 2008 19:11:07 -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, 21 Sep 2008 19:11:07 -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, September 21, 2008 @ 19:11:06
  Author: eagle
Revision: 5045

Add informative references to PGP Moose and pgpverify, as requested by
the security review during Last Call.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-22 01:57:54 UTC (rev 5044)
+++ docs/usefor/usepro.xml	2008-09-22 02:11:06 UTC (rev 5045)
@@ -1726,7 +1726,8 @@
         standardized means of authenticating the sender of a control
         message or verifying that the contents of a control message were
         sent by the claimed sender.  There are, however, some
-        unstandardized authentication mechanisms in common use.</t>
+        unstandardized authentication mechanisms in common use, such as
+        <xref target="PGPVERIFY" />.</t>
 
         <t>Agents acting on control messages SHOULD take steps to
         authenticate control messages before acting on them, as
@@ -2120,7 +2121,10 @@
         SHOULD verify that messages approved for a moderated newsgroup are
         being injected by the moderator using authentication information
         from the underlying transport or some other authentication
-        mechanism arranged with the moderator.</t>
+        mechanism arranged with the moderator.  There is, at present, no
+        standardized method of authenticating approval of messages to
+        moderated groups, although some unstandardized authentication
+        methods such as <xref target="PGPMOOSE" /> are in common use.</t>
 
         <t>A malicious news server participating in a Netnews network may
         bypass checks performed by injecting agents, forge Path header
@@ -2259,6 +2263,29 @@
     </references>
 
     <references title="Informative References">
+      <reference anchor="PGPMOOSE" target="http://seer-grog.net/README">
+        <front>
+          <title>PGP Moose</title>
+          <author initials="G." surname="Rose" fullname="Greg Rose">
+            <organization>QUALCOMM</organization>
+          </author>
+          <date day="26" month="November" year="1998" />
+        </front>
+        <format type="TXT" target="http://seer-grog.net/README" />
+      </reference>
+      <reference anchor="PGPVERIFY"
+        target="ftp://ftp.isc.org/pub/pgpcontrol/FORMAT">
+        <front>
+          <title>Signing Control Messages</title>
+          <author initials="D." surname="Lawrence"
+            fullname="David C. Lawrence">
+            <organization>Internet Systems Consortium, Inc.</organization>
+          </author>
+          <date month="August" year="2001" />
+        </front>
+        <format type="TXT"
+          target="ftp://ftp.isc.org/pub/pgpcontrol/FORMAT" />
+      </reference>
       &rfc0976;
       &rfc1036;
       &rfc2045;



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 m8M1Uahr062262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 18:30:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M1Ua2V062261; Sun, 21 Sep 2008 18:30:36 -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.14.2/8.14.2) with ESMTP id m8M1UZfQ062255 for <[e-mail]>; Sun, 21 Sep 2008 18:30:36 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D521F2D6AFC for <[e-mail]>; Sun, 21 Sep 2008 18:30:35 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 9AD102D6A50 for <[e-mail]>; Sun, 21 Sep 2008 18:30:35 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 94F45E7A68; Sun, 21 Sep 2008 18:30:35 -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, 21 Sep 2008 18:30:35 -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, September 21, 2008 @ 18:30:34
  Author: eagle
Revision: 5043

Wording changes based on Charles's comprehensive review.  Most of the
changes are minor.  The only substantial changes are to add Path to
the list of headers that have to be removed or renamed during multiple
injection (provisionally, until we decide how to handle POSTED), and
adding a paragraph to Supersedes clarifying that those articles should
not be treated as control messages.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-22 00:40:25 UTC (rev 5042)
+++ docs/usefor/usepro.xml	2008-09-22 01:30:34 UTC (rev 5043)
@@ -49,7 +49,7 @@
     </author>
 
     <author initials="C.H." surname="Lindsey" fullname="Charles H. Lindsey">
-      <organization>University of Manchester</organization>
+      <organization></organization>
       <address>
         <postal>
           <street>5 Clerewood Avenue</street>
@@ -625,10 +625,10 @@
 
         <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
+          <t>Under some circumstances (posting to multiple supposedly
+          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
@@ -644,18 +644,18 @@
 
           <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
+          after injection, 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.
+          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.)  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.
             <list style="empty">
               <t>NOTE: Multiple injection inherently risks duplicating
-              articles.  Multiple injection after the fact, by converting
+              articles.  Multiple injection after injection, 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
@@ -746,10 +746,10 @@
 
           <t>The content of the new article's References header field MUST
           be formed from the content of the parent's References header
-          field if present and the content of the Message-ID header field
-          of the parent.  If the parent had a References header, FWS as
-          defined in <xref target="USEFOR" /> MUST be added between its
-          content and the Message-ID header field content.</t>
+          field if present, followed by the content of the Message-ID
+          header field of the parent.  If the parent had a References
+          header, FWS as defined in <xref target="USEFOR" /> MUST be added
+          between its content and the Message-ID header field content.</t>
 
           <t>If the resulting References header field would, after
           unfolding, exceed 998 characters in length (including its field
@@ -988,9 +988,9 @@
             <t>It SHOULD reject any article that matches an
             already-received cancel control message or the contents of the
             Supersedes header field of an accepted article, provided that
-            the relaying agent chose (on the basis of local site policy)
-            to honor that cancel control message or Supersedes header
-            field.</t>
+            the relaying agent has chosen (on the basis of local site
+            policy) to honor that cancel control message or Supersedes
+            header field.</t>
 
             <t>It MAY reject any article without an Approved header field
             posted to a newsgroup known to be moderated.  This practice is
@@ -1989,6 +1989,11 @@
         messages.  If the Supersedes header field is honored, the news
         server SHOULD take the same actions as it would take when honoring
         a cancel control message for the given target article.</t>
+
+        <t>The article containing the Supersedes header field, whether or
+        not the Supersedes header field is honored, SHOULD be handled as a
+        normal article and SHOULD NOT receive the special treatment of
+        control messages described in <xref target="serving" />.</t>
       </section>
 
       <section anchor="sendme" title="The ihave and sendme Control Messages">



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 m8M1TIoQ062201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 18:29:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M1TIfk062200; Sun, 21 Sep 2008 18:29: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.14.2/8.14.2) with ESMTP id m8M1TGDG062193 for <[e-mail]>; Sun, 21 Sep 2008 18:29:17 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CAA212D6C7F for <[e-mail]>; Sun, 21 Sep 2008 18:29:16 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id 6F85B2D6A50 for <[e-mail]>; Sun, 21 Sep 2008 18:29:16 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 68699E7A68; Sun, 21 Sep 2008 18:29:16 -0700 (PDT)
To: [e-mail]
Subject: Re: Niggles in usepro-draft-11
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Thu\, 28 Aug 2008 17\:05\:58 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Sun, 21 Sep 2008 18:29:16 -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:

> 3.2.1.  Constructing the Path Header Field
>
>    ........  Note that the Path header
>    field content is constructed from right to left by prepending
>    elements.
>
>    1.  ........
>
>    2.  ........
>
>    3.  A relaying or serving agent SHOULD prepend a <path-diagnostic> to
>        the Path header field content, where the <path-diagnostic> is
>        chosen as follows:
>
>        *  If the expected <path-identity> of the source of the article
>           matches the leftmost <path-identity> of the Path header
>           field's content, use "!" (<diag-match>), resulting in two
>           consecutive "!"s.
>
>        *  If the expected <path-identity> of the source of the article
>           does not match, use "!.MISMATCH." followed by the expected
>           <path-identity> of the source or its IP address.
>
>        *  If the relaying or serving agent is not willing or able to
>           check the <path-identity>, use "!.SEEN." followed by the FQDN,
>           IP address, or expected <path-identity> of the source.
>
> The term "expected <path-identity>" has been used three times there. but
> has not been properly explained. I would suggest adding, at the end of
> these steps:
>
>    In the above, the "expected" <path-identity> refers to that
>    appropriate to the apparent source of the article (e.g. as determined
>    by the channel whence it arrived, its IP address, or some
>    authentication provided during connection setup).

How about this?

--- usepro.xml	(revision 5041)
+++ usepro.xml	(working copy)
@@ -405,7 +405,13 @@
                   followed by the FQDN, IP address, or expected
                   &lt;path-identity> of the source.</t>
                 </list>
-              Be aware that <xref target="RFC1036" /> did not include
+              The "expected &lt;path-identity> of the source of the
+              article" is a &lt;path-identity> for the injecting or
+              relaying agent that passed the article to this relaying or
+              serving agent, determined by properties of connection via
+              which the article was received (for example, an
+              authentication identity or a peer IP address).  Be aware
+              that <xref target="RFC1036" /> did not include
               &lt;path-diagnostic>.  Implementations which predate this
               specification will add only single "!" characters between
               &lt;path-identity> strings.</t>

"Source" wasn't really defined either, so I tried to tackle that.  It's
surprisingly hard to come up with good text for this.

> But then there is no explanation of why barbaz used that "!!" delimiter
> (all the other funnies in the example _do_ get accounted for in further
> on in the text). So I would suggest:
>
>    barbaz, being satisfied that it had indeed been recceived from
>    baz.isp.example, inserted a "!!" <path-delimiter>. It then relayed it
>    to old.site.example .........

Agreed.  Just committed a fix.

> 3.3.  Article History and Duplicate Suppression
>
>    o  ............  If this
>       interval is shorter than the time it takes for an article to
>       propagate through the network, the agent might reject an article
>       it had not yet seen, so it ought not be aggressively short. .....
>                                           ^
>                                           to

It's an unusual formulation in general, but I believe the current
formulation is more grammatically correct.  The subject of the dependent
clause is "it" and the verb is "be".  If "be" is converted to an
infinitive, the dependent clause no longer has a verb.

>    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 do not have extensive experience with
>    Netnews and the subtle effects of its flood-fill algorithm.
>                ^^^
>            with the more

Hm, that seems to me like more words and a more roundabout phrasing to say
the same thing.

> We are now allowing (sometimes even requiring) posting agents to insert
> an Injection Date.  Whereas clueful multiple injectors will probably do
> this correctly, I am worried that incompetent MUA implementors (or which
> there are many :-( ) will do it wrongly.
>
> On the other hand, now it seems to have been decided only to allow
> injection agents to insert it in limited situations, it is desirable
> that posting agents should be encouraged (somewhere between MAY and
> SHOULD) to do it routinely (otherwise this new header will never catch
> on). So I suggest:
>    
>    When the proto-article already contains both Message-ID and Date
>    header fields, posting agents MAY, as part of the injection process
>    (i.e. immediately before passing it to an injection agent), add an
>    Injection-Date header field to that proto-article (a useful practice,
>    since it provides diagnostic information and can imrove propagation).
>    Moreover, 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. and they MUST do so if the
>    proto-article is being submitted to more than one injecting agent;
>    see Section 3.4.2.

This is a protocol change, so I'd rather have you raise this one as a
separate issue so that we can go through more process on addressing it.
Personally, I'd prefer for most posting agents to not supply Message-ID,
since the news server can generally do a better job, but I know that isn't
always realistic.  Failing that, what you're saying does make sense to me.

> 3.4.1.  Proto-articles
>
>    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 MUST NOT contain a "POSTED" <diag-keyword>; and any
>    of the following mandatory header fields MAY be omitted: Message-ID,
>    Date, and Path.  In all other respects, a proto-article MUST be a
>    valid Netnews article.  In particular, the header fields which may be
>    omitted MUST NOT be present with invalid content.
>
> I am worried about that 'MUST NOT contain a "POSTED" <diag-keyword>'. It
> would cause no interoperability problems and cause no significant harm,
> and hence a "MUST" cannot be justified under RFC 2119. Nothing breaks if
> two "POSTEDs appear in one Path.  Indeed, it could arise legitimately in
> multiple injection "after the fact", and in other exotic gatewaying
> situations.
>
> Yes, some s[pc]ammers will preload the Path so as to disguise the true
> origin of an article (which is indeed why POSTED was invented), but that
> is a matter to be taken up by the netkops rather than the protocols. And
> I would prefer to preserve all evidence left over from previous Paths in
> order to facilitate bebugging of broken gateways, etc.
>
> So, at the most, it ought to be a SHOULD, and I would be happy to omit
> it altogether. Note that whatever change is made here, corresponding
> changes would be needed in 3.4.2 and 3.5.2 Step 2.

This is also a protocol change and should therefore be a separate issue.
I'm inclined to agree with you that MUST isn't justified here and SHOULD
is more appropriate.  I think we already talked about this before,
although I haven't gone back and looked.

> 3.4.2.  Multiple Injection of Articles
>
>    Under some circumstances (posting to multiple disjoint networks,
>                                                 ^
>                                              supposedly

Changed.

>    injecting agents with spotty connectivity, or for redundancy, for
>    example), ........
>
>    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
>            ^^^^^^^^^^^^^
>            proto-articles
>    identical.

Intentionally singular both here and in the first sentence of that
paragraph to emphasize that there's only one proto-article which is
offered identically to each injecting agent.

>    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.
>
> I don't like the term "after the fact" (it has no intuitive meaning),

Changed to "after injection", which is more precise.

> and I don't think "converting back to a proto-article" is the best way
> to describe what needs to be done (since it can still contain various
> headers not present in the first-time-around proto-article). Here is an
> alternative wording:
>
>    In some cases, multiple injection arises (perhaps inadvertently) when
>    gatewaying articles found on one Netnews network to another,
>    supposedly unconnected one.  In this case, the (re-)posting agent
>    MUST remove any Xref header field and either rename or remove any
>    Injection-Info header field and other trace fields (thus converting
>    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.

Mmm, I see your point, but I don't prefer your wording.  Among other
things, it doesn't make any sense to me to insert a "perhaps
inadvertently" comment here, since if it's inadvertent, the agent has no
way of knowing that it should do this.  The current wording makes it clear
that this requirement applies to all cases of multiple injection after the
initial injection, regardless of whether the networks are disjoint.

> Note that wording might need further revision, depending on what we
> decide regarding allowing "POSTED" to appear twice in a Path.

Yes.

I now have the following, which makes the handling of Path consistent with
the current definition of a proto-article.  This is only provisional until
we resolve handling of the POSTED <diag-keyword> in Path as discussed
above.

    <t>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.)  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.

>    Multiple injection of an article listing one or more moderated
>    newsgroups in its Newsgroups header field SHOULD only be done by a
>                                                     ^^^^
> 						    ONLY
>    moderator and MUST only be done after the proto-article has been
>                       ^^^^
> 		      ONLY
>    approved for all moderated groups to which it is to be posted and has
>    an Approved header field (see Section 3.9).  .....
>
> I think that is well within the spirit of RFC 2119, and will be much
> clearer.

I'd rather keep the capitalized words only at the RFC 2119 ones, and I
don't think this changes the clarity.  But if other people agree, I'll
change it.

> 3.4.4.  Construction of the References Header Field
>
>
>    The content of the new article's References header field MUST be
>    formed from the content of the parent's References header field if
>    present and the content of the Message-ID header field of the parent.
>            ^^^
>         followed by

Changed.

> 3.6.  Duties of a Relaying Agent
>
>    5.  It SHOULD reject any article that matches an already-received
>        cancel control message or the contents of the Supersedes header
>        field of an accepted article, provided that the relaying agent
>        chose (on the basis of local site policy) to honor that cancel
>        ^^^^^
>        has chosen
>        control message or Supersedes header field.

I'm not sure why the switch from past tense to present perfect tense here.
The decision to honor a cancel or Supersedes is normally made on receipt
of the cancel or Supersedes article.  I guess present perfect might be
more inclusive of different points at which that decision might be made,
and we don't actually care when the server makes the decision.

Okay, changed.

> 5.2.3.  The checkgroups Control Message
>
>    The body of the message is an entity of type application/
>                              ^
>        (or contains, as part of a multipart/mixed)

No, that would break compatibility with existing software.

> Cf. wording in 5.2.1.

They don't have the same legacy issues.  Legacy newgroup message
processing searches the body for the key string.  Legacy checkgroups
processing uses the entire article verbatim and hence would treat MIME
separators, headers, and other text as group names.

> 5.4.  The Supersedes Header Field
>
>    The presence of a Supersedes header field in an article requests that
>    the message identifier given in that header field be withdrawn in
>    exactly the same manner as if it were the target of a cancel control
>    message.  Accordingly, news servers SHOULD use the same
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    authentication and authorization checks for deciding whether to honor
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    a Supersedes header field as they use for cancel control messages.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    If the Supersedes header field is honored, the news server SHOULD
>    take the same actions as it would take when honoring a cancel control
>    message for the given target article.
>
> The bit I have marked with ^^^^^^^^ is all fine and dandy, except that
> the preceding section 5.3 on Cancel Messages make no mention of
> "authentication and authorization".

It's covered by section 5.1.

> However, what is currently said in our section 5.1 is fine (so far as it
> goes) for Group Control Messages, but has nothing to say of relevance to
> Cancels and Supersedes.

How so?  I think this pretty much covers it:

   Agents acting on control messages SHOULD take steps to authenticate
   control messages before acting on them, as determined by local
   authorization policy.  Whether this is done via the use of an
   unstandardized authentication protocol, by comparison with
   information obtained through another protocol, by human review, or by
   some other means is left unspecified by this document.  Further
   extensions or revisions of this protocol are expected to standardize
   a digital signature mechanism.

There isn't anything specific to group control messages there.  Those are,
stated generally, exactly the same provisions as should apply to cancel
messages and Supersedes.

> And also, as regards Supersedes headers, we do not actually say that, in
> addition to acting as a Cancel, they are also propagated and displayed
> like an ordinary article. I therefore suggest the following additional
> paragraph:
>
>    The article containing the Supersedes header field is itself still
>    intended to be made available to reading agents in the usual manner.

Agreed.  I tried to make the wording a bit more specific and now have:

        <t>The article containing the Supersedes header field, whether or
        not the Supersedes header field is honored, SHOULD be handled as a
        normal article and SHOULD NOT receive the special treatment of
        control messages described in <xref target="serving" />.</t>

This borders on a protocol change, but I think this just clarifies what
everyone's understanding was anyway, so I went ahead and changed it.

> Agreed as far as Cancels, but does there in fact exist such "widespread
> abuse" of Supersedes?

Yes.  It used to be significant.

>    Such articles intended to deny service, or other articles of an
>    inflammatory nature, may also have their From or Reply-To addresses
>    set to valid but incorrect email addresses, thus causing large
>    volumes of email to descend on the true owners of those addresses.
>                    ^
>               ("mailbombs")

Eh, I don't think that really adds anything.

>    Users and agents should always be aware that identifying information
>    in articles may be forged.
>
> Please add:
>
>    The inclusion of a Disposition-Notification-To header field could
>    also give rise to such mailbombs (hence its deprecation for Netnews
>    in [RFC3798]).

Wouldn't that be overkill?  No one has ever implemented that header for
netnews, no one has ever considered it so far as I've heard, and it's
explicitly deprecated for it.  I don't think it's enough risk to warrant
singling out specifically here.

> Authors' Addresses
>
>    Charles H. Lindsey
>    University of Manchester
>    5 Clerewood Avenue
>    Heald Green
>    Cheadle
>    Cheshire  SK8 3JU
>    United Kingdom
>
> I would suggest removing that "University of Manchester" line. I am long
> retired from the University, and I would not like to people to think
> that the address of the University was "5 Clerewood Avenue, Heald Green"
> :-) .

It took a little to figure out how to do that.  Apparently the trick is an
empty <organization> tag; you can't omit it entirely.

-- 
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.14.2/8.14.2) with ESMTP id m8M0ebU9059223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 17:40:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M0ebSM059222; Sun, 21 Sep 2008 17:40: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.14.2/8.14.2) with ESMTP id m8M0eRxW059213 for <[e-mail]>; Sun, 21 Sep 2008 17:40:37 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E323F2D6D63 for <[e-mail]>; Sun, 21 Sep 2008 17:40:26 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id C2A5A2D6A94 for <[e-mail]>; Sun, 21 Sep 2008 17:40:26 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 74CB8E7A4C; Sun, 21 Sep 2008 17:40:26 -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, 21 Sep 2008 17:40:26 -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, September 21, 2008 @ 17:40:25
  Author: eagle
Revision: 5042

Clarifications to the Path Header Field Example.  Explain that barbaz
verified the <path-identity> of the previous hop and change the
terminology to be consistent about referring to <path-diagnostic>.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-22 00:18:17 UTC (rev 5041)
+++ docs/usefor/usepro.xml	2008-09-22 00:40:25 UTC (rev 5042)
@@ -455,7 +455,10 @@
           "not-for-mail is a common &lt;tail-entry>.</t>
 
           <t>The article was relayed to the relaying agent known, at least
-          to old.site.example, as "barbaz".</t>
+          to old.site.example, as "barbaz".  That relaying agent confirmed
+          to its satisfaction that "baz.isp.example" was an expected
+          &lt;path-identity> for the source of the article and therefore
+          used &lt;diag-match> ("!") for its &lt;path-diagnostic>.</t>
 
           <t>barbaz relayed it to old.site.example, which does not support
           &lt;diag-keyword> and therefore used the old "!" delimiter.
@@ -464,7 +467,7 @@
 
           <t>old.site.example relayed it to a news server using the
           &lt;path-identity> of bar.isp.example and claiming (by using the
-          "!!" path delimiter) to have verified that it came from
+          "!" &lt;path-diagnostic>) to have verified that it came from
           old.site.example.</t>
 
           <t>bar.isp.example relayed it to foo-news which, not being



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 m8M0IU2J058249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 17:18:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M0IUJ8058248; Sun, 21 Sep 2008 17:18:30 -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.14.2/8.14.2) with ESMTP id m8M0IJkU058235 for <[e-mail]>; Sun, 21 Sep 2008 17:18:29 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7D3DD60E8D9 for <[e-mail]>; Sun, 21 Sep 2008 17:18:19 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id 597E560E8D6 for <[e-mail]>; Sun, 21 Sep 2008 17:18:18 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id EA1BDE7A31; Sun, 21 Sep 2008 17:18:18 -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, 21 Sep 2008 17:18:18 -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, September 21, 2008 @ 17:18:17
  Author: eagle
Revision: 5041

Fix a conflict between the wording of the application/news-checkgroups
message and the checkgroups control message around <chkscope>.  Clarify
that a checkgroups can be limited by external information, and that
limits the requirement for it to be complete to a SHOULD.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-22 00:13:33 UTC (rev 5040)
+++ docs/usefor/usepro.xml	2008-09-22 00:18:17 UTC (rev 5041)
@@ -1663,9 +1663,11 @@
 
         <t>One application/news-checkgroups message may contain
         information for one or more hierarchies and is considered complete
-        for any hierarchy for which it contains a &lt;valid-group>.  In
-        other words, an application/news-checkgroups body part consisting
-        of:</t>
+        for any hierarchy for which it contains a &lt;valid-group> unless
+        accompanied by external information limiting its scope (such as a
+        &lt;chkscope> parameter to a checkgroups control message as
+        described in <xref target="checkgroups" />).  In other words, an
+        application/news-checkgroups body part consisting of:</t>
 
         <figure>
           <artwork>
@@ -1679,7 +1681,8 @@
         This media type therefore MUST NOT be used for conveying partial
         information about a hierarchy; if a group from a given hierarchy
         is present, all groups that exist in that hierarchy MUST be
-        listed.</t>
+        listed unless its scope is limited by external information, in
+        which case all groups SHOULD be listed.</t>
       </section>
     </section>
 



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 m8M0HgPt058213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2008 17:17:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8M0HgDH058212; Sun, 21 Sep 2008 17:17:42 -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.14.2/8.14.2) with ESMTP id m8M0HVib058203 for <[e-mail]>; Sun, 21 Sep 2008 17:17:42 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7C52D65A19B for <[e-mail]>; Sun, 21 Sep 2008 17:17:31 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 5459765AD4C for <[e-mail]>; Sun, 21 Sep 2008 17:17:30 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id DC1B9E7A31; Sun, 21 Sep 2008 17:17:30 -0700 (PDT)
To: [e-mail]
Subject: Re: ISSUE: 4.3 contradicts 5.2.3
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Tue\, 16 Sep 2008 14\:28\:18 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Sun, 21 Sep 2008 17:17:30 -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:

> Yes, that should cover it, but you might add that, where there IS
> "external information" (and maybe the chkscope shold be mentioned
> explicitly), it SHOULD be listed.

Done.

> A bit awkward, but good enough for our purpose (unless anyone can come up
> with something better).

I've committed this fix (see the separate commit message).  I'm certainly
happy to modify the wording if anyone comes up with something better.

-- 
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.14.2/8.14.2) with ESMTP id m8KFZ1j1050215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Sep 2008 08:35:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8KFZ12g050214; Sat, 20 Sep 2008 08:35:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m8KFYoFH050183 for <[e-mail]>; Sat, 20 Sep 2008 08:35:01 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 4559 invoked by uid 503); 20 Sep 2008 15:34:52 -0000
Received: from gw2.ovh.net (HELO mail22.ha.ovh.net) (213.251.189.202) by 30.mail-out.ovh.net with SMTP; 20 Sep 2008 15:34:52 -0000
Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 20 Sep 2008 15:34:30 -0000
Received: from aaubervilliers-151-1-94-38.w83-199.abo.wanadoo.fr (HELO Iulius) (postmaster%trigofacile.com@83.199.213.38) by ns0.ovh.net with SMTP; 20 Sep 2008 15:34:29 -0000
Message-ID: <512A1446B4894410BC9E2C4EF107464B@Iulius>
From: =?iso-8859-15?Q?Julien_=C9LIE?= <[e-mail]>
To: <[e-mail]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
Date: Sat, 20 Sep 2008 17:34:46 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-15"; 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
X-Ovh-Tracer-Id: 1730789632204144057
X-Ovh-Remote: 83.199.213.38 (aaubervilliers-151-1-94-38.w83-199.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|H 0.5/N
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>

Hi Charles,

>> * If I have a hierarchy like this one:
>>    fr.bienvenue
>>    fr.test
>> and if another administrator is in charge of the sub-hierarchy
>> fr.autres, with for instance:
>>    fr.autres
>>    fr.autres.fiction
>>    fr.autres.histoires
>> how can he specify in the Control: header that his checkgroups
>> contains fr.autres?
>>    Control: checkgroups fr.autres #1
>> means fr.autres.* and does not create fr.autres (which I do not
>> want in my own hierarchy).
>
> That is correct. I think the term "sub-hiererchy" is defined as a set of
> groups with a common prefix (ending in '.'), and so does not include its
> own root. So it would be up to the administrator of fr.* to include
> "fr.autres" in HIS checkgroups.

I think USEPRO should not do something which leads sub-hierarchies
not to be self-managed:  they should not lay on the checkgroups of the
main hierarchy in case the root of the sub-hierarchy is a valid newsgroup
(which is not a root for the super-hierarchy).


> The chkscope parameter was invented for the benefit of the de.alt.*
> hierachy (which is used as an example in our draft). I don't think the
> individual group de.alt actually exists, but the wording surrounding that
> example seems to confirm my interpretation.

I understand that the <chkscope> parameter was invented for de.alt.*;
note that there is also cn.bbs.* in the same case.  (fido.* groups are
almost defunct.)
What strikes me most is that USEPRO sticks to the behaviour of
de.alt.* (where de.alt is not a newsgroup) and do not try to be
more general and foresee what could happen.


>>   The <chksernr> argument may be any positive integer.
>> Could it be better specified what should look like this integer?
>> Especially, why not suggest something like DNS serial numbers
>> #2008090701?  Why not limit the size of this integer (32 bits?)
>> Suppose that I put a 448-digit number, I am not sure news servers
>> will manage to save it and compare it with the next one.
>
> I wouldn't want to specify its format any further, but we might insist
> that the integer should be less that 32768, or somesuch.

I do not think it wise to limit this number to 32768 because one
could not use DNS serial numbers (which are practical).
2^31-1 = 2,147,483,647 would be better, at least.
It could be said that implementations should except <chksernr> arguments
to be a 32-bit integer.  And that the (unsigned) integer should be less
than 2^32-1.

-- 
Julien ÉLIE

« Et rose elle a vécu ce que vivent les roses :
  L'espace d'un matin. » (François de Malherbe)



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 m8IBECOm041871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 04:14:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8IBEC1w041870; Thu, 18 Sep 2008 04:14:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8IBE0Po041857 for <[e-mail]>; Thu, 18 Sep 2008 04:14:11 -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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48d23783.3b79.13a for [e-mail]; Thu, 18 Sep 2008 12: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 m8IBC3eg001328 for <[e-mail]>; Thu, 18 Sep 2008 12:12:03 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8IBC2IV001325 for [e-mail]; Thu, 18 Sep 2008 12:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24886
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> 	<[e-mail]> <[e-mail]>
Date: Thu, 18 Sep 2008 10:16:26 GMT
Lines: 27
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:
>> Russ Allbery <[e-mail]> writes:

>>> There is also "and should not be honored" where "SHOULD" should be used,
>>> shouldn't it?

>> +1

>Examples intentionally don't use RFC 2119 language because they're not
>normative.  (The constraint is already stated elsewhere with SHOULD.)

OK

s/+1/+0/

-- 
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.14.2/8.14.2) with ESMTP id m8I2C8RB004315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 19:12:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8I2C85r004314; Wed, 17 Sep 2008 19: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 smtp2.stanford.edu (smtp2.Stanford.EDU [171.67.20.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8I2BvCD004262 for <[e-mail]>; Wed, 17 Sep 2008 19:12:07 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 25F0B65B3D4 for <[e-mail]>; Wed, 17 Sep 2008 19:11:57 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id 04B6C65B3B2 for <[e-mail]>; Wed, 17 Sep 2008 19:11:56 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id B5FA9E78F7; Wed, 17 Sep 2008 19:11:56 -0700 (PDT)
To: [e-mail]
Subject: Re: Fwd: ISSUE: Checkgroups control messages
In-Reply-To: <[e-mail]> (Charles Lindsey's message of "Tue\, 16 Sep 2008 15\:08\:05 GMT")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Wed, 17 Sep 2008 19:11:56 -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:

>> There is also "and should not be honored" where "SHOULD" should be used,
>> shouldn't it?

> +1

Examples intentionally don't use RFC 2119 language because they're not
normative.  (The constraint is already stated elsewhere with SHOULD.)

-- 
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.14.2/8.14.2) with ESMTP id m8GGCHAL057863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 09:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8GGCH39057862; Tue, 16 Sep 2008 09:12:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8GGC47w057774 for <[e-mail]>; Tue, 16 Sep 2008 09:12:14 -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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48cfdad3.490c.6e4 for [e-mail]; Tue, 16 Sep 2008 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 m8GGC3B6007157 for <[e-mail]>; Tue, 16 Sep 2008 17:12:03 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8GGC3FL007153 for [e-mail]; Tue, 16 Sep 2008 17:12:03 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24883
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Last Call on USEFOR - procedures and reminder of deadline
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 16 Sep 2008 15:27:52 GMT
Lines: 52
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]> Harald Tveit Alvestrand <[e-mail]> writes:

>As you probably have seen, Lisa was true to her promise and Last-Called 
>usefor-12 on August 30, with a Last Call expiry date of September 12 (6 
>days from now).

That seems a very short interval. I have been on hboliday for 10 days, and
the Last Call seems to have openened and closed within that time.

>I would particularly like to ask Charles to go over his August 28 long 
>commentary on -11 and check what issues remain in -12, and if any of 
>them need to be raised above the editorial level.

None of the issues I raised was fixed in -12 (bar one). I think it best if
Russ looks carefully through it and indicates which is is happy to accept
(possibly reworded) as editorial corrections.

The only items which probably need discussion here are:

1. The MUST NOT in 
  "the    Path header field MUST NOT contain a "POSTED" <diag-keyword>;"
in Proto-articles (3.4.1) (since no interoperability arises, and there
might be diagnostic benefit in allowing it to remain in there).

2. The wording in 5.4 (Supersedes header) which is clearly wrong as it
stands, but I am not sure of the best way to fix it.

Also, it needs to be realised that the resolution of the IR/IC issue was
made by arbitrary decision of the Chair. I agree there was no better way
to resolve it (though naturally I disagree with the side of the fence that
the Chair fell onto :-) ). Ordinarily, one might ask the IETF to resolve
such dilemmas, but this case depends on a detailed understanding of the
foibles of newsgroup propagation).

>I'm hoping that we'll close this WG soon.

I think we need to review the list of things we once had on our list of
future work, and to decide which of them to do (which might be zero, of
course). But some of them are mentioned in our draft as future
possibilities, and such references might need to be edited out at some
later stage.

-- 
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.14.2/8.14.2) with ESMTP id m8GGCFeG057851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8GGCFmj057848; Tue, 16 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8GGC3b5057772 for <[e-mail]>; Tue, 16 Sep 2008 09:12:14 -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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48cfdad2.a91.f37 for [e-mail]; Tue, 16 Sep 2008 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 m8GGC2Pf007139 for <[e-mail]>; Tue, 16 Sep 2008 17:12:02 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8GGC2ti007136 for [e-mail]; Tue, 16 Sep 2008 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24881
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: ISSUE: 4.3 contradicts 5.2.3
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Date: Tue, 16 Sep 2008 14:28:18 GMT
Lines: 34
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:

>I think the fix would be to change to something like this:

>  ...and is considered complete for any hierarchy for which it contains
>  a <valid-group> unless accompanied by external information limiting
>  its scope (such as a <chkscope> parameter to a checkgroups control
>  message as described in Section 5.2.3)

>and at the end, add:

>  ...MUST be listed unless its scope is limited by external information.

Yes, that should cover it, but you might add that, where there IS
"external information" (and maybe the chkscope shold be mentioned
explicitly), it SHOULD be listed.

>but I'm not horribly happy with that.  It feels awkward.  I suppose the
>other way of going about it is to redefine hierarchy, but I think that
>would be tricky to do.

A bit awkward, but good enough for our purpose (unless anyone can come up
with something better).

-- 
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.14.2/8.14.2) with ESMTP id m8GGCFoP057849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8GGCFqg057847; Tue, 16 Sep 2008 09:12:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8GGC4ai057773 for <[e-mail]>; Tue, 16 Sep 2008 09:12:14 -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 v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 48cfdad3.2bf2.99a for [e-mail]; Tue, 16 Sep 2008 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 m8GGC2ON007147 for <[e-mail]>; Tue, 16 Sep 2008 17:12:03 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8GGC2iZ007144 for [e-mail]; Tue, 16 Sep 2008 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24882
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]>
Mime-Version: 1.0
Date: Tue, 16 Sep 2008 15:08:05 GMT
Lines: 103
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:

>Forwarding by request, since Julien's mail isn't making it through
>moderation of the list.


>From: Julien ÉLIE <[e-mail]>
>To: "Russ Allbery" <[e-mail]>
>Subject: Tr: ISSUE: Checkgroups control messages
>Date: Tue, 9 Sep 2008 20:02:11 +0200

>I see a few issues about checkgroups (section 5.2.3):


>* If I have a hierarchy like this one:

>    fr.bienvenue
>    fr.test

>and if another administrator is in charge of the sub-hierarchy
>fr.autres, with for instance:

>    fr.autres
>    fr.autres.fiction
>    fr.autres.histoires

>how can he specify in the Control: header that his checkgroups
>contains fr.autres?

>    Control: checkgroups fr.autres #1

>means fr.autres.* and does not create fr.autres (which I do not
>want in my own hierarchy).

That is correct. I think the term "sub-hiererchy" is defined as a set of
groups with a common prefix (ending in '.'), and so does not include its
own root. So it would be up to the administrator of fr.* to include
"fr.autres" in HIS checkgroups.

The chkscope parameter was invented for the benefit of the de.alt.*
hierachy (which is used as an example in our draft). I don't think the
individual group de.alt actually exists, but the wording surrounding that
example seems to confirm my interpretation.

>It looks that USEPRO implicitely considers that the top-level
>of a hierarchy (and also a sub-hierarchy) cannot be a valid
>newsgroup. (Anyway, I cannot make "fr" be a newsgroup at all
>with that system.)

No, there is nothing impossible about a group whose name is the name of a
sub-hierarchy, though there was a time when admins used to insist that your
top-level subgroup should be known as fr.autres.misc. But that rule has
been broken many times since those days.

>* I read:

>    The <chksernr> argument may be any positive integer.

>Could it be better specified what should look like this integer?
>Especially, why not suggest something like DNS serial numbers
>#2008090701?  Why not limit the size of this integer (32 bits?)
>Suppose that I put a 448-digit number, I am not sure news servers
>will manage to save it and compare it with the next one.

I wouldn't want to specify its format any further, but we might insist
that the integer should be less that 32768, or somesuch.

>* I read:

>    If provided, news servers SHOULD remember the <chksernr>
>    value of the previous checkgroups control message honored for
>    a particular hierarchy or sub-hierarchy.

>What happens if not provided for a given checkgroups whereas previous
>ones for the same hierarchy had been provided?  Should it be honoured?

NO.

>According to the wording, two separate counters must be used, right?
>One for "fr" and another one for "fr.autres" (sub-)hierarchies.

Yes.

>I reckon that a means should be provided to allow a hierarchy
>administrator to change his counter....

-1

>There is also "and should not be honored" where "SHOULD" should be used,
>shouldn't it?

+1

-- 
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.14.2/8.14.2) with ESMTP id m8GGC8gH057783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 09:12:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8GGC82X057782; Tue, 16 Sep 2008 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 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 m8GGC6BD057776 for <[e-mail]>; Tue, 16 Sep 2008 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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.301) id 48cfdad6.b8a.8d7 for [e-mail]; Tue, 16 Sep 2008 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 m8GGC2i0007131 for <[e-mail]>; Tue, 16 Sep 2008 17:12:02 +0100 (BST)
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id m8GGC1RN007128 for [e-mail]; Tue, 16 Sep 2008 17:12:02 +0100 (BST)
To: [e-mail]
Xref: clerew local.usefor:24880
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
Message-ID: <[e-mail]>
X-Newsreader: NN version 6.5.2 (NOV)
References: <[e-mail]> <[e-mail]>
Date: Tue, 16 Sep 2008 14:22:23 GMT
Lines: 84
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]> SM <[e-mail]> writes:

>Section 3.4 of this I-D states that:

>   "Contrary to [RFC2822], which implies that the mailbox or mailboxes in
>    the From header field should be that of the poster or posters, a
>    poster who does not, for whatever reason, wish to use his own mailbox
>    MAY use any mailbox ending in the top level domain ".invalid"
>    [RFC2606]."

>The use of an invalid email address for the author can be a problem 
>if the message goes through a news-to-mail gateway....

>   "In all cases, the "From:" field SHOULD NOT contain any mailbox that
>    does not belong to the author(s) of the message."

>Should such messages be discarded by a news-to-mail gateway as they 
>are not meaningful in that medium?

The practice of munging From addresses is widespread on Usenet (with or
without the use of 'invalid'), so it isn't going to go away. But anyone
who munges his from address assumes the risk that various agents will
decline to display it; his choice.

I think it is up to the discretion of the gateway administrator. If he
lets it through, some email servers (e.g. those that check From addresses
for existence in the DNS) may drop it. That is the risk the sender took.

So I would leave our wording as it stands.

>In Section 3.5.1:

>   "The proto-article is sent as an email with the addition of any
>    header fields (such as a To header field) required for an email."

>The To header field is not required; the From header is.  I suggest:

>    The proto-article is sent as an email with the addition of any
>    header fields required for an email as defined in RFC2822.

Yes, that is technically better. But what is usual practice here? Do
gateways usually insert "To: [e-mail]"? If so, perhaps we
should advise it.

>Section 3.10.2 recommends the following for an incoming gateway:

>  "If the original message already had a Sender header field, it SHOULD be
>   renamed so that its contents can be preserved."

>The draft doesn't specify to what the header should be renamed.  I 
>suggest creating a new header field for it.

No, there is an established tradition for adding X-headers with obviously
recognisable names (such as X-Orig-Sender) which newsadmins and netkops
can easily recognise, and if we do something special for this header there
are probaly 27 other special headers we should invent for similar
purposes.

>In Section 3.10.3, it is mentioned that:

>  "The news-to-mail gateway adds an X-Gateway header field to all
>   messages it generates."

>It may be better to depreciate the use of X- headers.

No. That particular header needs to be recognised only by the site that
inserted it (in case there is a loop). I think we agreed that people
inventing headers which might reasonably become permanent in some future
standard should avoid the use of X-headers (and, of course, it is now
possible to make a provisional registration of such headers with IANA).
But X-headers are still useful for ad-hoc purposes where there is no
expectation that widely-deployed software has any need to recognise them
automatically.

-- 
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.14.2/8.14.2) with ESMTP id m8GFgcst055604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 08:42:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8GFgc9K055603; Tue, 16 Sep 2008 08:42:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m8GFgPQQ055583 for <[e-mail]>; Tue, 16 Sep 2008 08:42:37 -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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.301) id 48cfd3d9.4c29.56d; Tue, 16 Sep 2008 16:42:17 +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 m8GFfud7004774; Tue, 16 Sep 2008 16:41:58 +0100 (BST)
Date: Tue, 16 Sep 2008 16:41:56 +0100
To: "Charles Clancy" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: secdir review of draft-ietf-usefor-usepro-12
From: "Charles Lindsey" <[e-mail]>
Cc: "Usefor Mailing List" <[e-mail]>
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
MIME-Version: 1.0
References: <[e-mail]>
Content-Transfer-Encoding: 8bit
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Opera Mail/9.25 (SunOS)
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 Wed, 10 Sep 2008 02:03:24 +0100, Charles Clancy <[e-mail]>  
wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> Document: draft-ietf-usefor-usepro-12
> Document Title: Netnews Architecture and Protocols
>
> This document is an updated to RFC 1036, and defines the Netnews system.  
>   This document specifically addresses the Netnews architecture, with  
> another document defining the message formatting (and NNTP being defined  
> in a separate document, which is the most popular transport protocol).
>
> Having personally run my campus Usenet server while in college 10 years  
> ago, this document brings back all sorts of fun memories of a  
> pre-blog/wiki world.  The major issue back then seemed to be keeping  
> alt.binaries from filling up your server's disk.
>
> Overall, Newnews is known to have a myriad of security flaws that have  
> persisted since its inception, much like SMTP.  Strangely there hasn't  
> been any major effort to that I'm aware of to institutionalize things  
> such as digital signatures to Netnews articles.  The document indicates  
> that such an effort is underway (see section 5.1).  Is that true?
>
> A major avenue of attack for Netnews is unauthenticated control messages  
> that allow for operations such as the creation and deletion of  
> newsgroups, among other things.  Any Netnews Agent can generate such a  
> message, with any approving official's email address listed in the  
> header, and have them propagate through the Usenet system.
>
> While there is no authentication of Netnews control message, there is  
> typically some attempt to apply policy to authorize them (the major line  
> of defense against malicious control messages).  The irony here is that  
> authorization of unauthenticated messages gets you little more than a  
> minimal level of heuristic security.

This was discussed in the early days of USEFOR, and the decision was made  
to defer these security issues to a separate document (of which hints  
remain in the present draft).

Items to be considered in such a document would include:
    signing of control messages (the present ad hoc signing method works  
well
       but could not be standardized as it stands because it uses an
       X-header)
    signing of messages by moderators (which currently uses yet another
       X-header, but sadly a different one to control messages)
    cancel locks (there is an ancient draft for these)
    maybe some other things (e.g. I would like to standardize NoCems)

But whether such a project now goes ahead is open to considerable doubt  
:-(.

> Therefore much of the security of Netnews is then delegated to NNTP,  
> which can provide authenticated communications channels between Netnews  
> Agents.  This, however, only provides hop-by-hop security, and not any  
> form of end-to-end security.  I recommend the document discuss the  
> ramifications of this (i.e. any compromised NNTP server can generate and  
> propagate false control messages throughout the entire Usenet system, so  
> a secure Netnews transport protocol really only gives the system a false  
> sense of security).
>

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [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.14.2/8.14.2) with ESMTP id m89J4YdM002875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 12:04:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m89J4YuY002874; Tue, 9 Sep 2008 12:04:34 -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.14.2/8.14.2) with ESMTP id m89J4NKW002853 for <[e-mail]>; Tue, 9 Sep 2008 12:04:33 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EF33E60EFCE for <[e-mail]>; Tue,  9 Sep 2008 12:04:22 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id C027C60F3BF for <[e-mail]>; Tue,  9 Sep 2008 12:04:22 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 5BA9CE7926; Tue,  9 Sep 2008 12:04:22 -0700 (PDT)
To: [e-mail]
Subject: Fwd: ISSUE: Checkgroups control messages
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Tue, 09 Sep 2008 12:04:22 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
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>

Forwarding by request, since Julien's mail isn't making it through
moderation of the list.


From: Julien =C9LIE <[e-mail]>
To: "Russ Allbery" <[e-mail]>
Subject: Tr: ISSUE: Checkgroups control messages
Date: Tue, 9 Sep 2008 20:02:11 +0200

Hi,

I see a few issues about checkgroups (section 5.2.3):


* If I have a hierarchy like this one:

    fr.bienvenue
    fr.test

and if another administrator is in charge of the sub-hierarchy
fr.autres, with for instance:

    fr.autres
    fr.autres.fiction
    fr.autres.histoires

how can he specify in the Control: header that his checkgroups
contains fr.autres?

    Control: checkgroups fr.autres #1

means fr.autres.* and does not create fr.autres (which I do not
want in my own hierarchy).

It looks that USEPRO implicitely considers that the top-level
of a hierarchy (and also a sub-hierarchy) cannot be a valid
newsgroup. (Anyway, I cannot make "fr" be a newsgroup at all
with that system.)


* I read:

    The <chksernr> argument may be any positive integer.

Could it be better specified what should look like this integer?
Especially, why not suggest something like DNS serial numbers
#2008090701?  Why not limit the size of this integer (32 bits?)
Suppose that I put a 448-digit number, I am not sure news servers
will manage to save it and compare it with the next one.


* I read:

    If provided, news servers SHOULD remember the <chksernr>
    value of the previous checkgroups control message honored for
    a particular hierarchy or sub-hierarchy.

What happens if not provided for a given checkgroups whereas previous
ones for the same hierarchy had been provided?  Should it be honoured?

According to the wording, two separate counters must be used, right?
One for "fr" and another one for "fr.autres" (sub-)hierarchies.


I reckon that a means should be provided to allow a hierarchy
administrator to change his counter.  For instance if he does not want
to use it any longer (therefore, he wants to reset it to a null value)
or if he made a mistake and provided a too huge number (therefore, he
wants to reset it to #1 or a DNS serial number).




Note:  Adam H. Kerman also raised a few concerns about checkgroups here:
         http://groups.google.fr/group/news.admin.hierarchies/msg/f3c314b07=
f296bd3
         http://groups.google.fr/group/news.admin.hierarchies/msg/43cd4bcc8=
907f6db

but I am not talking about them here.

There is also "and should not be honored" where "SHOULD" should be used,
shouldn't it?

--=20
Julien =C9LIE

=AB I think it's a new feature.  Don't tell anyone it was an accident. =BB =
(Larry Wall)



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 m874WZmR002351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 21:32:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m874WZhL002350; Sat, 6 Sep 2008 21:32:35 -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.14.2/8.14.2) with ESMTP id m874WOuC002336 for <[e-mail]>; Sat, 6 Sep 2008 21:32:34 -0700 (MST) (envelope-from [e-mail])
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 53B3965A939 for <[e-mail]>; Sat,  6 Sep 2008 21:23:39 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp2.stanford.edu (Postfix) with ESMTP id F002F65A923 for <[e-mail]>; Sat,  6 Sep 2008 21:23:26 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id C83C3E7924; Sat,  6 Sep 2008 21:23:26 -0700 (PDT)
To: [e-mail]
Subject: ISSUE: 4.3 contradicts 5.2.3
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Sat, 06 Sep 2008 21:23:26 -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>

I was reading over the current draft as part of a recent discussion on
news.admin.hierarchies and noticed that 4.3 contains the statement:

  One application/news-checkgroups message may contain information for one
  or more hierarchies and is considered complete for any hierarchy for
  which it contains a <valid-group>. In other words, an
  application/news-checkgroups body part consisting of:

      example.moderated         A moderated newsgroup (Moderated)
      example.test              An unmoderated test group

  is a statement that the example.* hierarchy contains two newsgroups,
  example.moderated and example.test, and no others. This media type
  therefore MUST NOT be used for conveying partial information about a
  hierarchy; if a group from a given hierarchy is present, all groups that
  exist in that hierarchy MUST be listed.

However, this is not true in the presence of chkscope in 5.2.3:

  A checkgroups message is interpreted as an exhaustive list of the valid
  groups in all hierarchies or sub-hierarchies with a prefix listed in the
  <chkscope> argument, excluding any sub-hierarchy where the <chkscope>
  argument is prefixed by "!". If no <chkscope> argument is given, it
  applies to all hierarchies for which group statements appear in the body
  of the message. Since much existing software does not honor the
  <chkscope> argument, the body of the checkgroups control message MUST
  NOT contain group statements for newsgroups outside the intended scope
  and SHOULD contain a correct newsgroup list even for sub-hierarchies
  excluded with "!" <chkscope> terms. News servers, however, MUST honor
  <chkscope> as specified here.

I think the fix would be to change to something like this:

  ...and is considered complete for any hierarchy for which it contains
  a <valid-group> unless accompanied by external information limiting
  its scope (such as a <chkscope> parameter to a checkgroups control
  message as described in Section 5.2.3)

and at the end, add:

  ...MUST be listed unless its scope is limited by external information.

but I'm not horribly happy with that.  It feels awkward.  I suppose the
other way of going about it is to redefine hierarchy, but I think that
would be tricky to do.

(I've seen the other messages to the group over the past week and will
reply.  I'm still on vacation for a couple more days.  I just wanted to
send this out before I forgot about it.)

-- 
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.14.2/8.14.2) with ESMTP id m86Fcmpc065557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 08:38:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m86FcmlV065556; Sat, 6 Sep 2008 08:38:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m86FcbUL065537 for <[e-mail]>; Sat, 6 Sep 2008 08:38:47 -0700 (MST) (envelope-from [e-mail])
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id m86FcOjm001350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 08:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1220715515; x=1220801915; bh=oxILdWBf6MgK9950XLsKqNrT3kjEd2o8sc4W Y5HIlsA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=W6LWz8x/qxVtni7p9uEB0ydCyC P8qHYGQHP9MeLdKDe0IXzVTKJhpYeq9nnCUO5Np5BvomPwQI23M1D+f/hV9g5PGOZNT pQbCKTqhC4GZlcVYgT8a/lr0SF9fpf6GE581ePjEhjXOzW7Fn4WhKiQ0aN23U/R8ymE kITuMU0AmuM=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=YpI+NchCtfvWpcHw0XnSH8HxUGQuHC9Ah61B7tvuirikb5OD6mQEYoUORCdgo01L0 JoSWIA3XppezT6F4ekHTFiSSirYrgxiRsYo4lxuMsfg4ynZm8a5YH26PudfPB9N5eiO +MfIWYxsfKR3g5Gz3+Yq0tkYjENC9LECb9SZKKM=
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 06 Sep 2008 08:36:29 -0700
To: [e-mail]
From: SM <[e-mail]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard 
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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>

At 17:06 29-08-2008, The IESG wrote:
>The IESG has received a request from the Usenet Article Standard Update
>WG (usefor) to consider the following document:
>
>- 'Netnews Architecture and Protocols '
>    <draft-ietf-usefor-usepro-12.txt> as a Proposed Standard

Section 3.4 of this I-D states that:

   "Contrary to [RFC2822], which implies that the mailbox or mailboxes in
    the From header field should be that of the poster or posters, a
    poster who does not, for whatever reason, wish to use his own mailbox
    MAY use any mailbox ending in the top level domain ".invalid"
    [RFC2606]."

The use of an invalid email address for the author can be a problem 
if the message goes through a news-to-mail gateway.  Section 3.10.1 
(Duties of an Outgoing Gateway) doesn't mention what should be done 
in such a case.  Section 3.6.2 of RFC 2822 mentions that:

   "In all cases, the "From:" field SHOULD NOT contain any mailbox that
    does not belong to the author(s) of the message."

Should such messages be discarded by a news-to-mail gateway as they 
are not meaningful in that medium?

That could be avoided by encapsulating the message in a new message 
and sending it with Content-Type application/news-transmission.  Such 
messages might show up as attachments in some MUAs though.

In Section 3.5.1:

   "The proto-article is sent as an email with the addition of any
    header fields (such as a To header field) required for an email."

The To header field is not required; the From header is.  I suggest:

    The proto-article is sent as an email with the addition of any
    header fields required for an email as defined in RFC2822.

Section 3.10.2 recommends the following for an incoming gateway:

  "If the original message already had a Sender header field, it SHOULD be
   renamed so that its contents can be preserved."

The draft doesn't specify to what the header should be renamed.  I 
suggest creating a new header field for it.

   If the original message already had a Sender header field, it SHOULD be
   renamed to original-sender so that its contents can be preserved.

     original-sender          =   "Original-Sender:" mailbox CRLF

A request to IANA to update the the Permanent Message Header Field 
Repository with the following is required:

    Header field name:  Original-Sender
    Applicable protocol:  Netnews
    Status:  standard
    Author/Change controller:  IETF
    Specification document(s):  This document (section 3.10.2)

In Section 3.10.3, it is mentioned that:

  "The news-to-mail gateway adds an X-Gateway header field to all
   messages it generates."

It may be better to depreciate the use of X- headers.

Regards,
-sm 



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 m86Bs4eK050975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Sep 2008 04:54:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m86Bs4I0050974; Sat, 6 Sep 2008 04:54:04 -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.14.2/8.14.2) with ESMTP id m86Bs2QY050968 for <[e-mail]>; Sat, 6 Sep 2008 04:54:03 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 29A0939E66A for <[e-mail]>; Sat,  6 Sep 2008 13:53:36 +0200 (CEST)
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 6Uz4xQvFawRl for <[e-mail]>; Sat,  6 Sep 2008 13:53:35 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B2B5B39E402 for <[e-mail]>; Sat,  6 Sep 2008 13:53:35 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sat, 06 Sep 2008 13:54:01 +0200
From: Harald Tveit Alvestrand <[e-mail]>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Usefor Mailing List <[e-mail]>
Subject: Last Call on USEFOR - procedures and reminder of deadline
Content-Type: text/plain; charset=ISO-8859-1; 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>

As you probably have seen, Lisa was true to her promise and Last-Called 
usefor-12 on August 30, with a Last Call expiry date of September 12 (6 
days from now).

If you have comments you wish to record as Last Call comments, please 
follow the usual procedure:

- For any substantial issue, send a message with ISSUE: in the subject 
to the USEFOR mailing list, detailing ONE concern (or a group of closely 
related concerns).
Special since this is IETF Last Call: If you think the issue warrants 
IETF-wide attention, CC the IETF list ([e-mail]).
- We won't issue any new versions until after the Last Call has ended. 
Russ can check in new changes into his repository on a continuous basis, 
but there shouldn't be a -13 before September 12 at the earliest, and 
probably later (giving the WG Chairs some time to look through any 
issues raised).
- The WG chairs will record any ISSUEs that they don't dismiss out of 
hand in the issue tracker (eventually), and prepare a summary after the 
close of the Last Call.

I would particularly like to ask Charles to go over his August 28 long 
commentary on -11 and check what issues remain in -12, and if any of 
them need to be raised above the editorial level.

I'm hoping that we'll close this WG soon.

                          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 m85ItebR091495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2008 11:55:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m85Itet0091494; Fri, 5 Sep 2008 11:55:40 -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.14.2/8.14.2) with ESMTP id m85ItTJV091479 for <[e-mail]>; Fri, 5 Sep 2008 11:55:39 -0700 (MST) (envelope-from [e-mail])
Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E2F2860E204 for <[e-mail]>; Fri,  5 Sep 2008 11:55:28 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp3.stanford.edu (Postfix) with ESMTP id C8D6B60DF3C for <[e-mail]>; Fri,  5 Sep 2008 11:55:28 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 8D32AE7924; Fri,  5 Sep 2008 11:55:28 -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: Fri,  5 Sep 2008 11:55:28 -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: Friday, September 5, 2008 @ 11:55:27
  Author: eagle
Revision: 4949

Fix accidentally dropped word.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2008-09-05 04:01:48 UTC (rev 4948)
+++ docs/usefor/usepro.xml	2008-09-05 18:55:27 UTC (rev 4949)
@@ -1706,7 +1706,7 @@
 
       <t>Contrary to <xref target="RFC1036" />, the presence of a Subject
       header field starting with the string "cmsg&nbsp;" MUST NOT cause an
-      article to interpreted as a control message.  Agents MAY reject an
+      article to be interpreted as a control message.  Agents MAY reject an
       article with no Control header field and such a Subject header field
       as ambiguous.  Likewise, the presence of a &lt;newsgroup-name>
       ending in ".ctl" in the Newsgroups header field or the presence of