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

From: SM <[email-masked]>
Date: Sat, 06 Sep 2008 08:36:29 -0700

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 16 Sep 2008 14:22:23 GMT

>if the message goes through a news-to-mail gateway....

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

>    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: [email-masked]"? If so, perhaps we
should advise it.

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

>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: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Russ Allbery <[email-masked]>
Date: Sun, 21 Sep 2008 19:44:51 -0700

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

SM <[email-masked]> writes:

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

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

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

> 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 ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: SM <[email-masked]>
Date: Tue, 23 Sep 2008 23:22:13 -0700

>(I am not a subscriber to the ietf list and would appreciate copies of

Cc as requested.

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

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

>think the e-mail side of the gateway is outside the scope of this

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.

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

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

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

>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

---

From: Russ Allbery <[email-masked]>
Date: Wed, 24 Sep 2008 19:35:08 -0700

SM <[email-masked]> writes:
>> 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).
>
> 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.

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

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.

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

---

From: SM <[email-masked]>
Date: Thu, 25 Sep 2008 15:33:40 -0700

Hi Russ,

[I-D author requested Cc]

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

>random detritus from spam filters.

Okay.

>Would that be an improvement?

Yes, that's better.

Regards,
-sm

---

From: Tony Hansen <[email-masked]>
Date: Fri, 26 Sep 2008 09:42:47 -0400

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
	[email-masked]

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 30 Sep 2008 11:32:05 GMT

>named differently? Why encourage the use of X- headers in a standards

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

To: [email-masked]
Xref: clerew local.usefor:24935
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
Date: Tue, 30 Sep 2008 11:32:05 GMT
Lines: 32
Sender: [email-masked]

>named differently? Why encourage the use of X- headers in a standards

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

To: [email-masked]
Xref: clerew local.usefor:24933
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Niggles in usepro-draft-11
Date: Fri, 26 Sep 2008 14:27:42 GMT
Lines: 41
Sender: [email-masked]

In <[email-masked]> Thorfinn <[email-masked]> 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 :-( .

Date: Fri, 26 Sep 2008 09:42:47 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
Sender: [email-masked]

My $0.02.

	Tony Hansen
	[email-masked]

> difficult to depreciate them in favor of some standardized format.

From: =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
To: <[email-masked]>
Subject: Re: Commit in docs/usefor (usepro.xml)
Date: Fri, 26 Sep 2008 08:04:13 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

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

From: =?iso-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Re: Niggles in usepro-draft-11
Date: Fri, 26 Sep 2008 07:57:04 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

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) 

From: Thorfinn <[email-masked]>
To: Usefor WG <[email-masked]>
Subject: Re: Niggles in usepro-draft-11
Date: Fri, 26 Sep 2008 10:23:22 +1000
Sender: [email-masked]

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

>
> "Charles Lindsey" <[email-masked]> 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/">[email-masked]</a>
The world is coming to an end.  Please log off.  -- BSD fortune file

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Thu, 25 Sep 2008 16:04:27 -0700 (PDT)
Sender: [email-masked]

    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>

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Thu, 25 Sep 2008 16:03:52 -0700 (PDT)
Sender: [email-masked]

    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>

Date: Thu, 25 Sep 2008 15:33:40 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard
Cc: [email-masked], Russ Allbery <[email-masked]>
Sender: [email-masked]

Hi Russ,

Okay.

Yes, that's better.

Regards,
-sm 

To: [email-masked]
Subject: Re: Niggles in usepro-draft-11
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 25 Sep 2008 12:06:53 -0700
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> 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."

To: [email-masked]
Subject: Re: No posting flag
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 25 Sep 2008 11:54:30 -0700
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> 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.

From: =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Tr: No posting flag
Date: Thu, 25 Sep 2008 18:44:44 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

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

From: =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
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/
Sender: [email-masked]

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

To: [email-masked]
Xref: clerew local.usefor:24919
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Niggles in usepro-draft-11
Date: Thu, 25 Sep 2008 15:14:08 GMT
Lines: 48
Sender: [email-masked]

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

>"Charles Lindsey" <[email-masked]> 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 :-( .

To: [email-masked]
Xref: clerew local.usefor:24920
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: No posting flag
Date: Thu, 25 Sep 2008 15:19:44 GMT
Lines: 45
Sender: [email-masked]

In <B4F3927BBA3A4D19A1265D9882A27072@Iulius> =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]> writes:

>Hi,

>I thought it might be worth forwarding this remark from D. Stussy in
>news.software.nntp <news:[email-masked]>.

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

To: [email-masked]
Xref: clerew local.usefor:24918
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ISSUE: treatment of POSTED in proto articles
Date: Thu, 25 Sep 2008 15:06:35 GMT
Lines: 67
Sender: [email-masked]

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

In <[email-masked]> "Charles Lindsey" <[email-masked]> writes:

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

>"Charles Lindsey" <[email-masked]> 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.

To: [email-masked]
Xref: clerew local.usefor:24921
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Tr: ISSUE: Checkgroups control messages
Date: Thu, 25 Sep 2008 15:26:17 GMT
Lines: 23
Sender: [email-masked]

In <FDD172E722E445F8BCD9252E9BE21220@Iulius> =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]> 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.

To: [email-masked]
Xref: clerew local.usefor:24922
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ISSUE: Length and final dots of newsgroups descriptions.
Date: Thu, 25 Sep 2008 15:32:13 GMT
Lines: 35
Sender: [email-masked]

In <4E57E0839E9E4A51954B5CD2CD8FA3E1@Iulius> =?ISO-8859-15?Q?Julien_=C9LIE?= <[email-masked]> 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).

From: Thorfinn <[email-masked]>
To: Usefor WG <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Thu, 25 Sep 2008 13:06:29 +1000
Sender: [email-masked]

On 25 Sep 2008, at 02:33, Charles Lindsey wrote:
> In <[email-masked]> Thorfinn <[email-masked] 
> > 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/">[email-masked]</a>
The world is coming to an end.  Please log off.  -- BSD fortune file

To: SM <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 24 Sep 2008 19:35:08 -0700
Sender: [email-masked]

To: [email-masked]
Subject: Expected <path-identity> wording
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 24 Sep 2008 18:18:44 -0700
Sender: [email-masked]

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>

To: [email-masked]
Subject: Re: Niggles in usepro-draft-11
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 24 Sep 2008 18:17:43 -0700
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> writes:
> Russ Allbery <[email-masked]> 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.

To: "Usefor WG" <[email-masked]>
Subject: Re: ISSUE:  Length and final dots of newsgroups descriptions.
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 24 Sep 2008 13:10:30 -0700
Sender: [email-masked]

Julien =C9LIE <[email-masked]> 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

From: =?ISO-8859-15?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: ISSUE:  Length and final dots of newsgroups descriptions.
Date: Wed, 24 Sep 2008 19:22:54 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

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

From: =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Tr: ISSUE: Checkgroups control messages
Date: Wed, 24 Sep 2008 19:15:53 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

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

From: =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: No posting flag
Date: Wed, 24 Sep 2008 19:09:56 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Hi,

I thought it might be worth forwarding this remark from D. Stussy in
news.software.nntp <news:[email-masked]>.

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

To: [email-masked]
Xref: clerew local.usefor:24907
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Niggles in usepro-draft-11
Date: Wed, 24 Sep 2008 16:27:01 GMT
Lines: 122
Sender: [email-masked]

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

>"Charles Lindsey" <[email-masked]> 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).

To: [email-masked]
Xref: clerew local.usefor:24908
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Wed, 24 Sep 2008 16:33:48 GMT
Lines: 51
Sender: [email-masked]

In <[email-masked]> Thorfinn <[email-masked]> writes:

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

>>
>> Thorfinn <[email-masked]> 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.

To: [email-masked]
Xref: clerew local.usefor:24909
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Wed, 24 Sep 2008 16:36:20 GMT
Lines: 20
Sender: [email-masked]

In <[email-masked]> Thorfinn <[email-masked]> 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.

To: [email-masked]
Xref: clerew local.usefor:24905
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Niggles in usepro-draft-11
Date: Wed, 24 Sep 2008 15:57:37 GMT
Lines: 62
Sender: [email-masked]

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

>"Charles Lindsey" <[email-masked]> 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.

To: [email-masked]
Xref: clerew local.usefor:24904
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: ISSUE: posting agents MAY add Injection-Date
Date: Wed, 24 Sep 2008 15:45:03 GMT
Lines: 59
Sender: [email-masked]

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

>"Charles Lindsey" <[email-masked]> 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.

Date: Tue, 23 Sep 2008 23:22:13 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard
Cc: [email-masked], Russ Allbery <[email-masked]>
Sender: [email-masked]

Cc as requested.

Regards,
-sm 

From: Thorfinn <[email-masked]>
To: Usefor WG <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Tue, 23 Sep 2008 18:19:30 +1000
Sender: [email-masked]

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/">[email-masked]</a>
The world is coming to an end.  Please log off.  -- BSD fortune file

From: Thorfinn <[email-masked]>
To: =?ISO-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Tue, 23 Sep 2008 17:02:51 +1000
Cc: "Usefor WG" <[email-masked]>
Sender: [email-masked]

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/">[email-masked]</a>
To err is human, to moo bovine.  -- BSD fortune file

From: =?iso-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Tue, 23 Sep 2008 08:20:25 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

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)

Cc: "Usefor WG" <[email-masked]>
From: Thorfinn <[email-masked]>
To: Russ Allbery <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Tue, 23 Sep 2008 12:15:26 +1000
Sender: [email-masked]

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

>
> Thorfinn <[email-masked]> 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/">[email-masked]</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. --

To: "Usefor WG" <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 22 Sep 2008 18:49:35 -0700
Sender: [email-masked]

Thorfinn <[email-masked]> 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.

Cc: "Usefor WG" <[email-masked]>
From: Thorfinn <[email-masked]>
To: Russ Allbery <[email-masked]>
Subject: Re: ISSUE: Checkgroups control messages
Date: Tue, 23 Sep 2008 11:46:58 +1000
Sender: [email-masked]

On 22 Sep 2008, at 19:33, Russ Allbery wrote:

>
> "Charles Lindsey" <[email-masked]> writes:
>> Julien =C9LIE <[email-masked]> 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/">[email-masked]</a>
The world is coming to an end.  Please log off.  -- BSD fortune file

To: "Usefor WG" <[email-masked]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 22 Sep 2008 02:33:38 -0700
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> writes:
> Julien =C9LIE <[email-masked]> 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

Date: Mon, 22 Sep 2008 10:07:36 +0100
To: =?iso-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
From: "Charles Lindsey" <[email-masked]>
Cc: "Usefor WG" <[email-masked]>
Sender: [email-masked]

On Fri, 19 Sep 2008 21:32:33 +0100, Julien ÉLIE <[email-masked]>  
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: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: SM <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 21 Sep 2008 19:44:51 -0700
Sender: [email-masked]

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Sun, 21 Sep 2008 19:43:10 -0700 (PDT)
Sender: [email-masked]

    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>

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Sun, 21 Sep 2008 19:11:07 -0700 (PDT)
Sender: [email-masked]

    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;

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Sun, 21 Sep 2008 18:30:35 -0700 (PDT)
Sender: [email-masked]

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

To: [email-masked]
Subject: Re: Niggles in usepro-draft-11
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 21 Sep 2008 18:29:16 -0700
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> 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.

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Sun, 21 Sep 2008 17:40:26 -0700 (PDT)
Sender: [email-masked]

    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

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Sun, 21 Sep 2008 17:18:18 -0700 (PDT)
Sender: [email-masked]

    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>

To: [email-masked]
Subject: Re: ISSUE: 4.3 contradicts 5.2.3
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 21 Sep 2008 17:17:30 -0700
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> 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.

From: =?iso-8859-15?Q?Julien_=C9LIE?= <[email-masked]>
To: <[email-masked]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
Date: Sat, 20 Sep 2008 17:34:46 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

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)

To: [email-masked]
Xref: clerew local.usefor:24886
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
Date: Thu, 18 Sep 2008 10:16:26 GMT
Lines: 27
Sender: [email-masked]

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

>"Charles Lindsey" <[email-masked]> writes:
>> Russ Allbery <[email-masked]> 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/

To: [email-masked]
Subject: Re: Fwd: ISSUE: Checkgroups control messages
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 17 Sep 2008 19:11:56 -0700
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> writes:
> Russ Allbery <[email-masked]> 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.)

To: [email-masked]
Xref: clerew local.usefor:24883
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Last Call on USEFOR - procedures and reminder of deadline
Date: Tue, 16 Sep 2008 15:27:52 GMT
Lines: 52
Sender: [email-masked]

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> 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.

To: [email-masked]
Xref: clerew local.usefor:24881
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: ISSUE: 4.3 contradicts 5.2.3
Date: Tue, 16 Sep 2008 14:28:18 GMT
Lines: 34
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> 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).

To: [email-masked]
Xref: clerew local.usefor:24882
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Fwd: ISSUE: Checkgroups control messages
Date: Tue, 16 Sep 2008 15:08:05 GMT
Lines: 103
Sender: [email-masked]

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

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

>From: Julien ÉLIE <[email-masked]>
>To: "Russ Allbery" <[email-masked]>
>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

To: [email-masked]
Xref: clerew local.usefor:24880
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
Date: Tue, 16 Sep 2008 14:22:23 GMT
Lines: 84
Sender: [email-masked]

Date: Tue, 16 Sep 2008 16:41:56 +0100
To: "Charles Clancy" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: secdir review of draft-ietf-usefor-usepro-12
From: "Charles Lindsey" <[email-masked]>
Cc: "Usefor Mailing List" <[email-masked]>
Sender: [email-masked]

On Wed, 10 Sep 2008 02:03:24 +0100, Charles Clancy <[email-masked]>  
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: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Subject: Fwd: ISSUE: Checkgroups control messages
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 09 Sep 2008 12:04:22 -0700
Sender: [email-masked]

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

From: Julien =C9LIE <[email-masked]>
To: "Russ Allbery" <[email-masked]>
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)

To: [email-masked]
Subject: ISSUE: 4.3 contradicts 5.2.3
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 06 Sep 2008 21:23:26 -0700
Sender: [email-masked]

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

Date: Sat, 06 Sep 2008 08:36:29 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and  Protocols) to Proposed Standard 
Cc: [email-masked]
Sender: [email-masked]

In Section 3.5.1:

Regards,
-sm 

Date: Sat, 06 Sep 2008 13:54:01 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: Last Call on USEFOR - procedures and reminder of deadline
Sender: [email-masked]

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 ([email-masked]).
- 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

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Fri,  5 Sep 2008 11:55:28 -0700 (PDT)
Sender: [email-masked]

    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