Subject: Missing RFC editor commit

From: Julien ÉLIE <[email-masked]>
Date: Wed, 27 May 2009 23:43:55 +0200

Hi,

Would it be possible to know what changes occur in USEPRO
between revision 5777 (March, 3rd) and revision 5921 (May, 25th)?

I see in revision 5922 (May, 25th):

@@ -171,7 +170,6 @@
       display-name        = <see [RFC5322] Section 3.4>
       local-part          = <see [RFC5322] Section 3.4.1>
       mailbox             = <see [RFC5322] Section 3.4>
-      utext               = <see [RFC2822] Section 3.2.6>
 ]]></artwork>
         </figure>
       </section>

whereas we still had RFC2822 everywhere in revision 5777.
Yet, no mails were sent to the mailing list for the intermediate
commits which must have happened.

(Maybe it was a commit which generated a mail whose length
exceeded the maximum allowed here?)

-- 
Julien ÉLIE

« Non omnibus aegris eadem auxilia conueniunt. »

---

From: Russ Allbery <[email-masked]>
Date: Wed, 27 May 2009 15:45:05 -0700

Julien ÉLIE <[email-masked]> writes:

> whereas we still had RFC2822 everywhere in revision 5777.  Yet, no
> mails were sent to the mailing list for the intermediate commits which
> must have happened.
>

I suspect it was too long for the mailing list.  I'll send it to you
separately.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 31 May 2009 22:56:10 +0200

Hi Russ,

> I suspect it was too long for the mailing list.  I'll send it to you

OK, thanks a lot!

Here are a few (minor) remarks:

@@ -476,13 +497,13 @@
-          <t>bar.isp.example relayed it to foo-news which, not being
+          <t>bar.isp.example relayed it to foo-news, which, not being
           convinced that it truly came from bar.isp.example, inserted the
           &lt;diag-keyword> "MISMATCH" and then stated that it received
           the article from the IPv6 address
           [2001:DB8:0:0:8:800:200C:417A].  (This is not to say that
           bar.isp.example was not a correct &lt;path-identity> for that
-          source but simply that that identity did not match the
+          source but simply that the identity did not match the
           expectations of foo-news.)</t>

Isn't there something better in English to say "that" in that case?
Because we have in the same sentence "that source" and "the identity";
it would be better to keep the meaning of "that identity".

"but simply that the expectations of foo-news were not matched
by that identity"?
Or another construction than "this is not to say that ... but that".

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

Is "or not" necessary?  Isn't "it won't know whether such articles" enough?
(It happens twice in the text.)

@@ -1249,23 +1272,26 @@
             <list style="numbers">
               <t>The message identifier of the news article should be
               preserved if at all possible, preferably as or within the
-              corresponding unique identifier of the other medium, but if
-              not at least as a comment in the message.  This helps
-              greatly with preventing loops.</t>
+              corresponding unique identifier of the other
+              medium. However, if it is not preserved in this way,
+              then at least it should be preserved
+              as a comment in the message.  This helps greatly with
+              preventing loops.</t>

Missing space before "However".

@@ -2412,8 +2497,9 @@
           <t>Additional media types are defined for improved
           structuring, specification, and automated processing of
-          control messages (<xref target="groupinfo" /> and <xref
-          target="checkgroup" />).</t>
+          control messages (Sections <xref target="groupinfo"
+          format="counter" /> and <xref
+          target="checkgroup" format="counter" />).</t>

It makes me notice that there is an inconsistency between "(Section x.y)"
and "(see Section x.y)" or equivalent in the RFC.  Most of the references
use "see" but a few, like this one, do not.  Shouldn't it be homogenized?

-- 
Julien ÉLIE

« Quo vadis ? » (saint Jean)

From: =?iso-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Re: Missing RFC editor commit
Date: Sun, 31 May 2009 22:56:10 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Hi Russ,

> I suspect it was too long for the mailing list.  I'll send it to you

OK, thanks a lot!

Here are a few (minor) remarks:

@@ -476,13 +497,13 @@
-          <t>bar.isp.example relayed it to foo-news which, not being
+          <t>bar.isp.example relayed it to foo-news, which, not being
           convinced that it truly came from bar.isp.example, inserted the
           &lt;diag-keyword> "MISMATCH" and then stated that it received
           the article from the IPv6 address
           [2001:DB8:0:0:8:800:200C:417A].  (This is not to say that
           bar.isp.example was not a correct &lt;path-identity> for that
-          source but simply that that identity did not match the
+          source but simply that the identity did not match the
           expectations of foo-news.)</t>

Isn't there something better in English to say "that" in that case?
Because we have in the same sentence "that source" and "the identity";
it would be better to keep the meaning of "that identity".

"but simply that the expectations of foo-news were not matched
by that identity"?
Or another construction than "this is not to say that ... but that".

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

Is "or not" necessary?  Isn't "it won't know whether such articles" enough?
(It happens twice in the text.)

@@ -1249,23 +1272,26 @@
             <list style="numbers">
               <t>The message identifier of the news article should be
               preserved if at all possible, preferably as or within the
-              corresponding unique identifier of the other medium, but if
-              not at least as a comment in the message.  This helps
-              greatly with preventing loops.</t>
+              corresponding unique identifier of the other
+              medium. However, if it is not preserved in this way,
+              then at least it should be preserved
+              as a comment in the message.  This helps greatly with
+              preventing loops.</t>

Missing space before "However".

@@ -2412,8 +2497,9 @@
           <t>Additional media types are defined for improved
           structuring, specification, and automated processing of
-          control messages (<xref target="groupinfo" /> and <xref
-          target="checkgroup" />).</t>
+          control messages (Sections <xref target="groupinfo"
+          format="counter" /> and <xref
+          target="checkgroup" format="counter" />).</t>

It makes me notice that there is an inconsistency between "(Section x.y)"
and "(see Section x.y)" or equivalent in the RFC.  Most of the references
use "see" but a few, like this one, do not.  Shouldn't it be homogenized?

-- 
Julien ÉLIE

« Quo vadis ? » (saint Jean)

To: "Usefor WG" <[email-masked]>
Subject: Re: Missing RFC editor commit
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 27 May 2009 15:45:05 -0700
Sender: [email-masked]

Julien =C9LIE <[email-masked]> writes:

>       display-name        =3D <see [RFC5322] Section 3.4>
>       local-part          =3D <see [RFC5322] Section 3.4.1>
>       mailbox             =3D <see [RFC5322] Section 3.4>
> -      utext               =3D <see [RFC2822] Section 3.2.6>
> ]]></artwork>
>         </figure>
>       </section>
>

--=20

From: =?ISO-8859-15?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Missing RFC editor commit
Date: Wed, 27 May 2009 23:43:55 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Hi,

@@ -171,7 +170,6 @@

-- 
Julien ÉLIE

From: =?iso-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Re: Possible typos
Date: Wed, 27 May 2009 19:17:07 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Hi Russ,

Thanks for your commits.

>> By the way, why does "Supersedes" always begin with a capital?  When
>> we do not speak about the header, it should be a lower-case letter
>> shouldn't it?  For instance in 3.4, "which cancels or Supersedes
>> another article".
>
> The RFC Editor noticed that too and lowercased it.  I added a
> parenthetical reference to the Supersedes header field, which is what I
> was trying to reference in too subtle of a way.

I see you added the reference once (that's fine -- no need to say it
several times).

>>    Cancel control messages are not required to have the same Newsgroups
>>    header field as the messages they are cancelling and, since they are
>>    sometimes processed before the original message is received, it may not
>>    be possible to check that they do.
>>
>> "to check what they do"?  "to check that"?
>
> Reworded, thanks.

Your new wording is clearer, thanks!

-- 
Julien ÉLIE

« Je ne voudrais tout de même pas que Cléopâtre m'ait dans le nez ! » (César)

From: =?iso-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Re: Tr: Injection-Info
Date: Wed, 27 May 2009 19:13:07 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

>> And Injection-Date: a sub-field of Injection-Info: (but maybe it was
>> done this way because it was easier to parse in order to obtain the
>> date?).
>
> Injection-Date is separate because it has a protocol purpose on transit
> servers and the like.  So it's the exact opposite of what I just wrote
> above -- it *is* needed regularly, and hence it's in a separate field.

OK, thanks Russ.

-- 
Julien ÉLIE

« Video meliora proboque deteriora sequor. » (Ovide) 

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Tue, 26 May 2009 21:32:11 -0700 (PDT)
Sender: [email-masked]

    Date: Tuesday, May 26, 2009 @ 21:32:10
  Author: eagle
Revision: 5936

Additional update from the RFC Editor.  Okay, they want to "abuse"
seriesInfo for the publisher rather than using the ISBN.  Works for
me.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 21:03:16 UTC (rev 5935)
+++ docs/usefor/usepro.xml	2009-05-27 04:32:10 UTC (rev 5936)
@@ -2448,7 +2448,7 @@
           </author>
           <date month="January" year="1992" />
         </front>
-        <seriesInfo name="ISBN-13" value="978-0-937175-93-4" />
+        <seriesInfo name="O'Reilly &" value="Associates Ltd." />
       </reference>
     </references>

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Tue, 26 May 2009 14:03:17 -0700 (PDT)
Sender: [email-masked]

    Date: Tuesday, May 26, 2009 @ 14:03:16
  Author: eagle
Revision: 5935

Also remove the ENTITY reference to the UUCP RFC.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 20:53:09 UTC (rev 5934)
+++ docs/usefor/usepro.xml	2009-05-26 21:03:16 UTC (rev 5935)
@@ -8,8 +8,6 @@
 <?rfc subcompact="no" ?>
 
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
-  <!ENTITY rfc0976 PUBLIC '' 
-    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0976.xml'>
   <!ENTITY rfc1036 PUBLIC '' 
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1036.xml'>
   <!ENTITY rfc2045 PUBLIC '' 

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Tue, 26 May 2009 13:53:10 -0700 (PDT)
Sender: [email-masked]

    Date: Tuesday, May 26, 2009 @ 13:53:09
  Author: eagle
Revision: 5934

The document is now the result of a twelve-year effort.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 20:52:34 UTC (rev 5933)
+++ docs/usefor/usepro.xml	2009-05-26 20:53:09 UTC (rev 5934)
@@ -2511,7 +2511,7 @@
     </section>
 
     <section title="Acknowledgements">
-      <t>This document is the result of a ten-year effort and the number
+      <t>This document is the result of a twelve-year effort and the number
       of people that have contributed to its content are too numerous to
       mention individually.  Many thanks go out to all past and present
       members of the USEFOR Working Group of the Internet Engineering Task

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Tue, 26 May 2009 13:52:36 -0700 (PDT)
Sender: [email-masked]

    Date: Tuesday, May 26, 2009 @ 13:52:34
  Author: eagle
Revision: 5933

Change the UUCP reference to the O'Reilly book rather than the RFC
for e-mail over UUCP (which isn't the protocol we're talking about).

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 20:38:28 UTC (rev 5932)
+++ docs/usefor/usepro.xml	2009-05-26 20:52:34 UTC (rev 5933)
@@ -219,8 +219,8 @@
       <t>The exact means used to transmit articles from one agent to
       another is not specified.  NNTP <xref target="RFC3977" /> is the
       most common transport mechanism for Netnews networks.  Other
-      methods in use include the Unix-to-Unix Copy Protocol (UUCP)
-      <xref target="RFC0976" />
+      methods in use include the Unix-to-Unix Copy Protocol
+      <xref target="UUCP" />
       (extensively used in the early days of Usenet) and physically
       delivered magnetic and optical media.  Any mechanism may be used
       in conjunction with this protocol provided that it can meet the
@@ -282,7 +282,6 @@
       additional effects than those described below.  Those effects
       are described in <xref target="control" />.</t>
 
-
       <section title="General Principles">
         <t>There are two important principles that news implementors and
         administrators need to keep in mind.  The first is the well-known
@@ -1543,7 +1542,6 @@
         </artwork>
       </figure>
 
-
       <section anchor="transmission" title="application/news-transmission">
         <t>The media type application/news-transmission is intended for
         the encapsulation of complete news articles where the intention is
@@ -2124,8 +2122,8 @@
         <t>The ihave and sendme control messages implement a predecessor
         of the NNTP <xref target="RFC3977" /> protocol.  They are largely
         obsolete on the Internet but still see use in conjunction with
-        some transport protocols such as UUCP.  News servers are not
-        required to support them.</t>
+        some transport protocols such as UUCP <xref target="UUCP" />.
+        News servers are not required to support them.</t>
 
         <figure>
           <preamble>ihave and sendme control messages share similar syntax
@@ -2414,7 +2412,6 @@
           target="ftp://ftp.isc.org/pub/pgpcontrol/FORMAT" />
       </reference>
 
-      &rfc0976;
       &rfc1036;
       &rfc2045;
       &rfc2606;
@@ -2431,7 +2428,7 @@
         </front>
         <seriesInfo name="Work in" value="Progress" />
       </reference>
-      <reference anchor="USEAGE" >
+      <reference anchor="USEAGE">
         <front>
           <title>Usenet Best Practice</title>
           <author initials="C." surname="Lindsey"
@@ -2442,6 +2439,19 @@
         </front>
         <seriesInfo name="Work in" value="Progress" />
       </reference>
+      <reference anchor="UUCP">
+        <front>
+          <title>Managing UUCP and Usenet</title>
+          <author initials="T." surname="O'Reilly" fullname="Tim O'Reilly">
+            <organization />
+          </author>
+          <author initials="G." surname="Todino" fullname="Grace Todino">
+            <organization />
+          </author>
+          <date month="January" year="1992" />
+        </front>
+        <seriesInfo name="ISBN-13" value="978-0-937175-93-4" />
+      </reference>
     </references>
 
     <section title="Changes to the Existing Protocols">

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Tue, 26 May 2009 13:38:30 -0700 (PDT)
Sender: [email-masked]

    Date: Tuesday, May 26, 2009 @ 13:38:28
  Author: eagle
Revision: 5932

Updated version of the document from the RFC Editor.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 06:00:51 UTC (rev 5931)
+++ docs/usefor/usepro.xml	2009-05-26 20:38:28 UTC (rev 5932)
@@ -1530,7 +1530,7 @@
                              handled as application/octet-stream.
                              Disposition should by default be inline.
 
-   Published specification:  [SON-OF-1036], RFC 5537
+   Published specification:  RFC 1036, RFC 5537
 
    Applications that use this media type:
                              Some old mail and news user agents.
@@ -1543,13 +1543,6 @@
         </artwork>
       </figure>
 
-<!--[rfced] 
-  For "Published specification", should RFC 1036 be listed instead of
-  SON-OF-1036? 
-  The IANA registry lists this document and RFC 1036 for message/news on
-  http://www.iana.org/assignments/media-types/message/.
-  Or should the registry be updated to list SON-OF-1036?
--->
 
       <section anchor="transmission" title="application/news-transmission">
         <t>The media type application/news-transmission is intended for
@@ -1587,7 +1580,7 @@
                              the recipient host's system beyond just
                              storage of the article.
 
-   Published specification:  RFC 5537
+   Published specification:  RFC 1036, RFC 5537
 
    Body part:                A complete proto-article ready for
                              injection into Netnews or an article
@@ -1796,7 +1789,7 @@
         which case all groups SHOULD be listed.</t>
 
         <t>Spaces are used in this example for formatting reasons.  In
-        an actual message the newsgroup name and description MUST be
+        an actual message, the newsgroup name and description MUST be
         separated by one or more tabs (HTAB, ASCII %d09), not spaces.</t>
       </section>
     </section>
@@ -1967,7 +1960,7 @@
             </figure>
 
             <t>Spaces are used in this example for formatting reasons.  In
-            an actual message the newsgroup name and description MUST be
+            an actual message, the newsgroup name and description MUST be
             separated by one or more tabs (HTAB, ASCII %d09), not
             spaces.</t>
           </section>
@@ -2434,8 +2427,9 @@
             fullname="Henry Spencer">
             <organization>SP Systems</organization>
           </author>
-          <date month="June" year="1994" />
+          <date month="May" year="2009" />
         </front>
+        <seriesInfo name="Work in" value="Progress" />
       </reference>
       <reference anchor="USEAGE" >
         <front>

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Mon, 25 May 2009 17:43:27 -0700 (PDT)
Sender: [email-masked]

    Date: Monday, May 25, 2009 @ 17:43:27
  Author: eagle
Revision: 5928

Further rewordings based on Charles's detailed reading and further
RFC Editor discussion.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 00:31:32 UTC (rev 5927)
+++ docs/usefor/usepro.xml	2009-05-26 00:43:27 UTC (rev 5928)
@@ -640,9 +640,9 @@
         <section anchor="multi-injection"
                  title="Multiple Injection of Articles">
           <t>Under some circumstances (for example, when posting to
-          multiple, supposedly disjoint, networks, when injecting
+          multiple, supposedly disjoint, networks, when using injecting
           agents with spotty connectivity, or when desiring
-          redundancy), a posting agent may wish to offer
+          additional redundancy), a posting agent may wish to offer
           the same article to multiple injecting agents.  In this unusual
           case, the goal is not to create multiple independent articles
           but rather to inject the same article at multiple points and let
@@ -1308,11 +1308,11 @@
           <t>An incoming gateway MUST NOT gate the same message twice.  It
           may not be possible to ensure this in the face of mangling or
           modification of the message, but at the very least a gateway,
-          when given a copy of a message that it has already gated identically
-          except for trace header fields (like Received in Email or Path
-          in Netnews), MUST NOT gate the message again.  An incoming
-          gateway SHOULD take precautions against having this rule
-          bypassed by modifications of the message that can be
+          when given a copy of a message that it has already gated and
+          that is identical except for trace header fields (like Received
+          in Email or Path in Netnews), MUST NOT gate the message again.
+          An incoming gateway SHOULD take precautions against having this
+          rule bypassed by modifications of the message that can be
           anticipated.</t>
 
           <t>News articles prepared by gateways MUST be valid news

To: [email-masked]
Subject: Re: Use of message disposition notification
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 25 May 2009 17:36:18 -0700
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> writes:
> Julien =C9LIE <[email-masked]> writes:

>> By the way, as you speak about security considerations, I see that
>> USEPRO references both pgpmoose and pgpverify.  Wouldn't a note on
>> Cancel-Lock be added in 6.1?  ("Currently, many sites are ignoring
>> all cancel control messages and Supersedes header fields due to the
>> difficulty of authenticating them and their widespread abuse.")  It
>> could be said that Cancel-Lock might be used
>> (draft-ietf-usefor-cancel-lock-01) and also NoCeM, which is more and
>> more spread nowadays.

> Cancel-Lock is not formally defined anywhere, hence I know of no
> news-server that ever looks at it, although a few people add it in
> hope :-).

> Our original plan of work was that, when we were done with our present
> drafts, the next jobs would be UTF-8 in newsgroup-names and a document
> covering security matters - notably pgpmoose and pgpverify (which
> really need to be unified) plus Cancel-Locks and, I would hope,
> NoCeM. But those would rechartering, and the probability of that
> happening is not, shall we say, too promising :-( .

Unless someone feels very strongly otherwise, I'm going to bail on
cancel lock for this document on those same "requires thought" grounds.
The logical next step for Cancel-Lock would be to complete the work of
publishing an RFC, which could then update this one and generate the
right references in RFC listings.

--=20

To: "Usefor WG" <[email-masked]>
Subject: Re: Duties of agents as for obsolete control messages
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 25 May 2009 17:34:42 -0700
Sender: [email-masked]

Julien =C9LIE <[email-masked]> writes:

> Shouldn't it be said something in the duties of injecting agents
> (and maybe relaying?) as for obsolete control messages
> like sendsys, version, whogets and senduuname (section 5.6)?
> They SHOULD be rejected (?)

Eh, I don't know.  We say:

        <t>The following control message types are declared obsolete by
        this document and SHOULD NOT be sent or honored:

and I'm not sure I want to say more than that or call it out
specifically for injecting agents.  I think that most injecting agents
currently don't think about control messages at all and just pass them
along.

--=20

To: "Usefor WG" <[email-masked]>
Subject: Re: Archived-At: header field
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 25 May 2009 17:33:07 -0700
Sender: [email-masked]

Julien =C9LIE <[email-masked]> writes:

> I see that RFC 5064 defines the Archived-At: header field for Netnews.
>    http://www.rfc-editor.org/rfc/rfc5064.txt
>
> Shouldn't it be referenced somewhere in USEFOR?
> (And maybe also in USEPRO?  as a note in the gatewaying section?)

I'm going to punt on this for this document.  I think RFC 5064 is
relatively clear, referencing it requires a bit of thought about how it
might be used, and at this stage in the document publication I don't
want to make changes that require a bit of thought.  We're too likely to
get them wrong.

--=20

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Mon, 25 May 2009 17:31:33 -0700 (PDT)
Sender: [email-masked]

    Date: Monday, May 25, 2009 @ 17:31:32
  Author: eagle
Revision: 5927

Add multiple minor typo fixes and clarifications.

Examples showing newsgroup description information now include a specific
note saying that the spaces are typographic and that in real messages
tabs are required.  Checkgroups update moderation status as well.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 00:19:41 UTC (rev 5926)
+++ docs/usefor/usepro.xml	2009-05-26 00:31:32 UTC (rev 5927)
@@ -959,7 +959,7 @@
         <t>A relaying agent accepts injected articles from injecting and
         other relaying agents and passes them on to relaying or serving
         agents.  To avoid bypass of injecting agent policies and forgery
-        of Path and Injector-Info headers, relaying agents SHOULD accept
+        of Path and Injection-Info headers, relaying agents SHOULD accept
         articles only from trusted agents.</t>
 
         <t>An article SHOULD NOT be relayed unless the sending agent has
@@ -1759,7 +1759,7 @@
         </figure>
 
         <figure>
-          <preamble>The content of the application/news-groupinfo body
+          <preamble>The content of the application/news-checkgroups body
           part is defined as:</preamble>
 
           <artwork type="abnf">
@@ -1794,6 +1794,10 @@
         is present, all groups that exist in that hierarchy MUST be
         listed unless its scope is limited by external information, in
         which case all groups SHOULD be listed.</t>
+
+        <t>Spaces are used in this example for formatting reasons.  In
+        an actual message the newsgroup name and description MUST be
+        separated by one or more tabs (HTAB, ASCII %d09), not spaces.</t>
       </section>
     </section>
 
@@ -1961,6 +1965,11 @@
       --nxtprt--
               </artwork>
             </figure>
+
+            <t>Spaces are used in this example for formatting reasons.  In
+            an actual message the newsgroup name and description MUST be
+            separated by one or more tabs (HTAB, ASCII %d09), not
+            spaces.</t>
           </section>
         </section>
 
@@ -1986,7 +1995,8 @@
           valid groups in a hierarchy with descriptions and moderation
           status.  It requests that a news server update its valid newsgroup
           list for that hierarchy to include the groups specified, remove
-          any groups not specified, and update group descriptions to match
+          any groups not specified, and update group descriptions and
+          moderation status to match
           those given in the checkgroups control message.  The syntax of
           its Control header field is:</t>
 
@@ -2213,9 +2223,10 @@
         difficulty of authenticating them and their widespread abuse.</t>
 
         <t>Cancel control messages are not required to have the same
-        Newsgroups header field as the messages they are cancelling and,
-        since they are sometimes processed before the original message is
-        received, it may not be possible to check that they do.  This
+        Newsgroups header field as the messages they are cancelling.
+        Since they are sometimes processed before the original message is
+        received, it may not be possible to check that the Newsgroup
+        header fields match.  This
         allows a malicious poster to inject a cancel control message for
         an article in a moderated newsgroup without adding an Approved
         header field to the control message, and to hide malicious cancel

To: "Usefor WG" <[email-masked]>
Subject: Re: Possible typos
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 25 May 2009 17:30:12 -0700
Sender: [email-masked]

Julien =C9LIE <[email-masked]> writes:

> Other typos:
>
> In 4.3:
>    The content of the application/news-groupinfo body part is defined as:
>
> It is application/news-checkgroups!

Thanks, fixed.

> In both 4.3 and 5.2.1.1, could it be said that in the examples, spaces
> are used in newsgroups descriptions but that they are in fact tabs?

Added.

> In 5.2.3, as for a checkgroups control message:
>
>    It requests a news server update its valid newsgroup list for that
>    hierarchy to include the groups specified, remove any groups not
>    specified, and update group descriptions to match those given in
>    the checkgroups control message.
>
> Could it be said "and update group descriptions as well as moderation
> status to match those..."?

Yes, good idea.  Done.

> In 5.3:
>
>    The cancel control message requests that a target article be withdrawn
>    from circulation and access.
>
> In order to be consistent with the previous paragraphs, "that" should
> not be added here after "requests" :)

The RFC Editor apparently has their own style for this, and thats were
added and changed all over the document for publication.  I'm leaving
all of that alone, since I have no strong opinions.  :)

> By the way, why does "Supersedes" always begin with a capital?  When
> we do not speak about the header, it should be a lower-case letter
> shouldn't it?  For instance in 3.4, "which cancels or Supersedes
> another article".

The RFC Editor noticed that too and lowercased it.  I added a
parenthetical reference to the Supersedes header field, which is what I
was trying to reference in too subtle of a way.

> In 6.1:
>
>    Cancel control messages are not required to have the same Newsgroups
>    header field as the messages they are cancelling and, since they are
>    sometimes processed before the original message is received, it may not
>    be possible to check that they do.
>
> "to check what they do"?  "to check that"?

Reworded, thanks.

--=20

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Mon, 25 May 2009 17:19:43 -0700 (PDT)
Sender: [email-masked]

    Date: Monday, May 25, 2009 @ 17:19:41
  Author: eagle
Revision: 5926

Use ABNF syntax when discussing ASCII values when describing transport
limitations.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 00:16:47 UTC (rev 5925)
+++ docs/usefor/usepro.xml	2009-05-26 00:19:41 UTC (rev 5926)
@@ -227,11 +227,11 @@
       requirements specified here.</t>
 
       <t>Transports for Netnews articles MUST treat news articles as
-      uninterpreted sequences of octets, excluding the values 0 (which may
-      not occur in Netnews articles) and 13 and 10 (which MUST only appear
-      in Netnews articles as a pair in that order and which, together,
-      denote a line separator).  These octets are the US-ASCII <xref
-      target="ASCII" /> characters NUL, CR, and LF respectively.
+      uninterpreted sequences of octets, excluding the values %d00 (which
+      may not occur in Netnews articles), %d13, and %d10 (which MUST only
+      appear in Netnews articles as a pair in that order and which,
+      together, denote a line separator).  These octets are the US-ASCII
+      <xref target="ASCII" /> characters NUL, CR, and LF respectively.
         <list style="empty">
           <t>NOTE: This corresponds to the range of octets permitted in
           MIME 8bit data <xref target="RFC2045" />.  Transports for

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Mon, 25 May 2009 17:16:47 -0700 (PDT)
Sender: [email-masked]

    Date: Monday, May 25, 2009 @ 17:16:47
  Author: eagle
Revision: 5925

Remove an incorrect !! from the example Path header field.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 00:12:22 UTC (rev 5924)
+++ docs/usefor/usepro.xml	2009-05-26 00:16:47 UTC (rev 5925)
@@ -454,7 +454,7 @@
             agents.</preamble>
 
             <artwork>
-    Path: foo.isp.example!.SEEN.isp.example!!foo-news
+    Path: foo.isp.example!.SEEN.isp.example!foo-news
       !.MISMATCH.2001:DB:0:0:8:800:200C:417A!bar.isp.example
       !!old.site.example!barbaz!!baz.isp.example
       !.POSTED.dialup123.baz.isp.example!not-for-mail

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Mon, 25 May 2009 17:12:23 -0700 (PDT)
Sender: [email-masked]

    Date: Monday, May 25, 2009 @ 17:12:22
  Author: eagle
Revision: 5924

Remove the URL for the PGPMOOSE specification.  It's not stable.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 00:11:49 UTC (rev 5923)
+++ docs/usefor/usepro.xml	2009-05-26 00:12:22 UTC (rev 5924)
@@ -2386,8 +2386,7 @@
     </references>
 
     <references title="Informative References">
-      <reference anchor="PGPMOOSE" 
-       target="http://seer-grog.net/README">
+      <reference anchor="PGPMOOSE">
         <front>
           <title>PGP Moose</title>
           <author initials="G." surname="Rose" fullname="Greg Rose">
@@ -2395,7 +2394,6 @@
           </author>
           <date day="26" month="November" year="1998" />
         </front>
-        <format type="TXT" target="http://seer-grog.net/README" />
       </reference>
 
       <reference anchor="PGPVERIFY"

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Mon, 25 May 2009 17:11:50 -0700 (PDT)
Sender: [email-masked]

    Date: Monday, May 25, 2009 @ 17:11:49
  Author: eagle
Revision: 5923

Following further discussion, remove RFC 1036 as a defining standard
for application/news-transmission.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-26 00:03:29 UTC (rev 5922)
+++ docs/usefor/usepro.xml	2009-05-26 00:11:49 UTC (rev 5923)
@@ -1587,7 +1587,7 @@
                              the recipient host's system beyond just
                              storage of the article.
 
-   Published specification:  RFC 1036, RFC 5537
+   Published specification:  RFC 5537
 
    Body part:                A complete proto-article ready for
                              injection into Netnews or an article

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Mon, 25 May 2009 17:03:30 -0700 (PDT)
Sender: [email-masked]

    Date: Monday, May 25, 2009 @ 17:03:29
  Author: eagle
Revision: 5922

Reference VCHAR instead of utext, removing the last reference to
RFC 2822.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-25 23:52:24 UTC (rev 5921)
+++ docs/usefor/usepro.xml	2009-05-26 00:03:29 UTC (rev 5922)
@@ -20,8 +20,6 @@
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
   <!ENTITY rfc2606 PUBLIC '' 
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2606.xml'>
-  <!ENTITY rfc2822 PUBLIC '' 
-    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
   <!ENTITY rfc5322 PUBLIC '' 
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml'>
   <!ENTITY rfc3629 PUBLIC '' 
@@ -151,6 +149,7 @@
       HTAB                = <see [RFC5234] Appendix B.1>
       SP                  = <see [RFC5234] Appendix B.1>
       WSP                 = <see [RFC5234] Appendix B.1>
+      VCHAR               = <see [RFC5234] Appendix B.1>
 
       argument            = <see [RFC5536] Section 3.2.3>
       article-locator     = <see [RFC5536] Section 3.2.14> 
@@ -171,7 +170,6 @@
       display-name        = <see [RFC5322] Section 3.4>
       local-part          = <see [RFC5322] Section 3.4.1>
       mailbox             = <see [RFC5322] Section 3.4>
-      utext               = <see [RFC2822] Section 3.2.6>
 ]]></artwork>
         </figure>
       </section>
@@ -1681,7 +1679,7 @@
                           = eightbit-utext *( *WSP eightbit-utext )
       moderation-flag     = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")"
                                ; SPACE + case sensitive "(Moderated)"
-      eightbit-utext      = utext / %d127-255
+      eightbit-utext      = VCHAR / %d127-255
           </artwork>
         </figure>
 
@@ -2364,7 +2362,6 @@
       </reference>
       &rfc2046;
       &rfc2119;
-      &rfc2822;
       &rfc5322;
       &rfc3629;
       &rfc4288;

To: [email-masked]
From: [email-masked]
Subject: Commit in docs/usefor (usepro.xml)
Date: Mon, 25 May 2009 16:52:25 -0700 (PDT)
Sender: [email-masked]

    Date: Monday, May 25, 2009 @ 16:52:24
  Author: eagle
Revision: 5921

The results of my editing pass following the RFC Editor editing pass.
Restore the correct link for the pgpverify format (not the README for
the software package).  Add some minor tweaks and clarifications.  Add
RFC 1036 as a specification for application/news-transmission and allow
our superseding status to disambiguate.  Minimally wrap long lines so
that the XML is still readable.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-05-25 23:49:56 UTC (rev 5920)
+++ docs/usefor/usepro.xml	2009-05-25 23:52:24 UTC (rev 5921)
@@ -173,19 +173,6 @@
       mailbox             = <see [RFC5322] Section 3.4>
       utext               = <see [RFC2822] Section 3.2.6>
 ]]></artwork>
-
-<!--[rfced] Since RFC 5322 obsoleted RFC 2822, we have updated this
-   document accordingly. 
-
-   However, if RFC 2822 should be referred to throughout the document,
-   then please add a sentence to mention the existence of RFC 5322 and
-   explain to the reader why it is not being used in this document.
-
-   Regarding "utext": It does not appear in RFC 5322, so this has not 
-   been changed.  Please let us know how this particular reference 
-   should be updated.  We note that RFC 5335 extends the 2822 "utext".
--->
-
         </figure>
       </section>
 
@@ -234,7 +221,8 @@
       <t>The exact means used to transmit articles from one agent to
       another is not specified.  NNTP <xref target="RFC3977" /> is the
       most common transport mechanism for Netnews networks.  Other
-      methods in use include the Unix-to-Unix Copy Protocol (UUCP) <xref target="RFC0976" />
+      methods in use include the Unix-to-Unix Copy Protocol (UUCP)
+      <xref target="RFC0976" />
       (extensively used in the early days of Usenet) and physically
       delivered magnetic and optical media.  Any mechanism may be used
       in conjunction with this protocol provided that it can meet the
@@ -273,10 +261,9 @@
       agent, transferred through one or more relaying agents, accepted by
       a serving agent, and finally retrieved by a reading agent.  Articles
       submitted to moderated groups go through an additional process,
-      which is described separately (see <xref target="moderate" /> and Step 7
-      of <xref target="injecting" />.  
-     Finally, the additional duties and
-      requirements of a gateway are discussed.</t>
+      which is described separately (see <xref target="moderate" /> and
+      Step 7 of <xref target="injecting" />).  Finally, the additional
+      duties and requirements of a gateway are discussed.</t>
 
       <t>At each step, each agent has a set of checks and transformations
       of the article that it is required to perform.  These are described
@@ -617,19 +604,20 @@
 
         <t>Contrary to <xref target="RFC5322" />, 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
+        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" <xref target="RFC2606"
         />.</t>
 
         <t>Posting agents meant for use by ordinary posters SHOULD reject
-        any attempt to post an article that cancels or supersedes another
+        any attempt to post an article that cancels or supersedes (via the
+        Supersedes header field) another
         article of which the poster is not the author or sender.</t>
 
         <section anchor="proto-article" title="Proto-Articles">
           <t>A proto-article is an article in the format used by a posting
-          agent when offering that article to an injecting agent.  It may omit certain
+          agent when offering that article to an injecting agent.  It may
+          omit certain
           header fields that can be better supplied by the injecting
           agent and will not contain header fields that are added by the
           injecting agent.  A proto-article is only for transmission to an
@@ -673,7 +661,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
+          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 fields before
@@ -700,7 +688,8 @@
           moderated newsgroups in its Newsgroups header field SHOULD only
           be done by a moderator and MUST only be done after the
           proto-article has been approved for all moderated groups to
-          which it is to be posted and after it has an Approved header field (see
+          which it is to be posted and after an Approved header
+          field has been added (see
           <xref target="moderator" />).  Multiple injection of an
           unapproved article intended for moderated newsgroups will
           normally only result in the moderator receiving multiple copies,
@@ -739,8 +728,8 @@
 
               <t>The Newsgroups header field SHOULD, by default, be
               inherited from the precursor's Followup-To header field if
-              present; otherwise, it is inherited from the precursor's Newsgroups
-              header field.</t>
+              present; otherwise, it is inherited from the precursor's
+              Newsgroups header field.</t>
 
               <t>The Subject header field SHOULD, by default, be inherited
               from that of the precursor.  The case-sensitive string
@@ -981,8 +970,7 @@
         field and at least one of the &lt;dist-name>s in its Distribution
         header field (if present).  Exceptionally, control messages
         creating or removing newsgroups (newgroup or rmgroup control
-        messages, for example) 
-        SHOULD be relayed if the affected group
+        messages, for example) SHOULD be relayed if the affected group
         appears in its Newsgroups header field and both the sending and
         receiving relaying agents are configured to relay a newsgroup of
         that name (whether or not such a newsgroup exists).</t>
@@ -1010,7 +998,8 @@
             If it implements one of the mechanisms described in <xref
             target="history" />, this means that it MUST reject any
             article whose date falls outside the cutoff interval since it
-            won't know whether or not such articles had been accepted previously.</t>
+            won't know whether or not such articles had been accepted
+            previously.</t>
 
             <t>It SHOULD reject any article that does not include all the
             mandatory header fields.  It MAY reject any article that
@@ -1092,7 +1081,8 @@
             If it implements one of the mechanisms described in <xref
             target="history" />, this means that it MUST reject any
             article whose date falls outside the cutoff interval since it
-            won't know whether or not such articles had been accepted previously.</t>
+            won't know whether or not such articles had been accepted
+            previously.</t>
 
             <t>It SHOULD reject any article that matches an
             already-received and honored cancel message or Supersedes
@@ -1286,12 +1276,10 @@
               <t>The message identifier of the news article should be
               preserved if at all possible, preferably as or within the
               corresponding unique identifier of the other
-              medium. However, if it is not preserved in this way,
-              then at least it should be preserved 
-              as a comment in the message.  This helps greatly with
-              preventing loops.</t>
+              medium. However, if it is not preserved in this way, then at
+              least it should be preserved as a comment in the message.
+              This helps greatly with preventing loops.</t>
 
-
               <t>The Date and Injection-Date of the news article should
               also be preserved if possible, for similar reasons.</t>
 
@@ -1353,7 +1341,8 @@
               articles are bad enough; spews of control messages with
               special significance to the news system, possibly resulting
               in high processing load or even in emails being sent for
-              every message received, are catastrophic.  It is far preferable to
+              every message received, are catastrophic.  It is far
+              preferable to
               construct a system specifically for posting control messages
               that can do appropriate consistency checks and
               authentication of the originator of the message.</t>
@@ -1600,7 +1589,7 @@
                              the recipient host's system beyond just
                              storage of the article.
 
-   Published specification:  RFC 5537
+   Published specification:  RFC 1036, RFC 5537
 
    Body part:                A complete proto-article ready for
                              injection into Netnews or an article
@@ -1615,13 +1604,6 @@
           </artwork>
         </figure>
 
-<!--[rfced] 2 questions about the registration above (first was 
-addressed in email from Lindsey on 4/16)
-
-For "Published specification", should RFC 1036 be added? Both this
-   document and 1036 are listed for news-transmission on
-   http://www.iana.org/assignments/media-types/application/
--->
         <t>usage=moderate indicates the article is intended for a
         moderator, usage=inject for an injecting agent, and usage=relay
         for a relaying agent.  The entity receiving the article may only
@@ -1786,7 +1768,6 @@
       checkgroups-body    = *( valid-group CRLF )
       valid-group         = newsgroups-line ; see Section 4.2
           </artwork>
-
         </figure>
 
         <t>The same restrictions on charset, &lt;newsgroup-name>, and
@@ -1843,7 +1824,8 @@
       header field starting with the string "cmsg&nbsp;" MUST NOT cause an
       article to be interpreted as a control message.  Agents MAY reject an
       article that has such a Subject header field and no Control
-      header field as ambiguous.  Likewise, the presence of a &lt;newsgroup-name>
+      header field as ambiguous.  Likewise, the presence of a
+      &lt;newsgroup-name>
       ending in ".ctl" in the Newsgroups header field or the presence of
       an Also-Control header field MUST NOT cause the article to be
       interpreted as a control message.</t>
@@ -2402,13 +2384,11 @@
             <organization>FlyDash, Inc.</organization>
           </author>
         </front>
-        <seriesInfo name="RFC"
-          value="5536" />
+        <seriesInfo name="RFC" value="5536" />
       </reference>
     </references>
 
     <references title="Informative References">
-
       <reference anchor="PGPMOOSE" 
        target="http://seer-grog.net/README">
         <front>
@@ -2422,7 +2402,7 @@
       </reference>
 
       <reference anchor="PGPVERIFY"
-        target="ftp://ftp.isc.org/pub/pgpcontrol/README.html">
+        target="ftp://ftp.isc.org/pub/pgpcontrol/FORMAT">
         <front>
           <title>Signing Control Messages</title>
           <author initials="D." surname="Lawrence"
@@ -2460,8 +2440,7 @@
           </author>
           <date month="March" year="2005" />
         </front>
-        <seriesInfo name="Work in"
-          value="Progress" />
+        <seriesInfo name="Work in" value="Progress" />
       </reference>
     </references>

Date: Tue, 12 May 2009 20:36:56 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: Usefor Mailing List <[email-masked]>
Subject: [Fwd: Son-of-1036]
Sender: [email-masked]

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

Just to keep everyone updated....

--------------090908070805020409090403
Content-Type: message/rfc822;
 name="Son-of-1036.eml"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="Son-of-1036.eml"

Date: Tue, 12 May 2009 19:25:45 +0100
To: [email-masked]
Subject: Son-of-1036
From: "Charles Lindsey" <[email-masked]>
Cc: "Henry Spencer" <[email-masked]>,
        "Harald Tveit Alvestrand" <[email-masked]>

I request publication of draft-spencer-usefor-son-of-1036-00.txt as an  
Historic RFC.

This draft, was written by Henry Spencer in June 1954, and subsequently  
revised by him, with my assistance with the detailed preparation, for  
publication as an Historic RFC. He will doubtless email you to confirm  
that this present request is made on his behalf.

In its original form, this draft was widely circulated, and was  
influential in the development of the Netnews protocols at that time, and  
formed the starting point for the USEFOR Working Group whose own drafts  
are now in AUTH48 as RFCs 5536 and 5537 (I am myself a joint author of  
both of those). Although never formally published as an ID, let alone as  
an RFC, I understand that there are precedents for such publications with  
Historic status.

The USEFOR WG had requested its publication some time back, in order that  
it could be referred to from within RFCs 5536 and 5537 (the only other  
current sources of the document are on private web sites which are not  
suitable for reference within an RFC). Lack of time prevented Henry from  
publishing it until I gave hiw a final prod, quite recently, and offered  
to do the grunt work in getting it out.

This publication project has been discussed during the AUTH48 exchanges  
between the authors of 553[67] and yourself (more specifically with Alice  
Hagens and Stacy Burns), and the USEFOR WG has been given an opportunity  
to comment upon it (which resulted in a few minor nits easily handled  
during AUTH48). I hope it will be possible to get it quickly at least to  
the stage of being assigned an RFC number, so that it may then be referred  
to in 553[67]; it would also be convenient to give it an RFC number less  
than 5536, if such a number is still available.

I can confirm that this draft has no IANA consequences (except insofar as  
some IANA templates currently attempt to reference it, though I am not  
sure that those references are necessary or correct).

I have CCed this to Harald Alvestrand, the USEFOR WG Chair, in the hope  
that he can suggest suitable reviewers for this draft, should you require  
them.

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

--------------090908070805020409090403--

To: [email-masked]
Xref: clerew local.usefor:25065
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D ACTION:draft-spencer-usefor-son-of-1036-00.txt
Date: Mon, 11 May 2009 11:44:01 GMT
Lines: 27
Sender: [email-masked]

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

>I do not have much to say.  Having skimmed through it, the only nits I see
>are typos (missing double spaces after full dots in the first two pages --
>status of this memo, copyright and abstract).
>I also see ". [RFC1036]" (p. 5, 16, 32, 58, 76) without a double space
>and ".([RFC 977]" (page 34) without spaces at all.

>I also noted in 6.5, page 42 "retrospect, , and".

>I very probably have missed other things (not having read the whole draft).

OK, those look like Nits to fix in AUTH48.

I think I shall probably submit it to the RFC Editor tomorrow if I hear
nothing further.

-- 
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: "Usefor WG" <[email-masked]>
Subject: Re: Tr: Injection-Info
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 09 May 2009 14:18:58 -0700
Sender: [email-masked]

Russ Allbery <[email-masked]> writes:
> Julien =C9LIE <[email-masked]> writes:

>> And Injection-Date: a sub-field of Injection-Info: (but maybe it was
>> done this way because it was easier to parse in order to obtain the
>> date?).

> We were trying to avoid the current situation where there are
> something like five different trace fields that different bits of
> software fills out.  Since you rarely need access to that information,
> it seemed better to collapse it into one field that one could parse
> when needed.

Oh, sorry, I completely failed on that question.  *heh*

Injection-Date is separate because it has a protocol purpose on transit
servers and the like.  So it's the exact opposite of what I just wrote
above -- it *is* needed regularly, and hence it's in a separate field.

--=20

To: "Usefor WG" <[email-masked]>
Subject: Re: Tr: Injection-Info
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 09 May 2009 13:58:29 -0700
Sender: [email-masked]

Julien =C9LIE <[email-masked]> writes:

> Just for your information (from news.software.nntp).
>
> It is true that
>    "Injection-Info: nowhere;posting-host=3Dlocalhost:::1"
> is not pretty to read and "posting-host" could have been
> shortened to "host"...

I disagree on the name shortening; host is ambiguous about whether it
means the posting host or the injecting host.  I do agree that in
retrospect, given the IPv6 address format, colon is an unfortunate
separator, but I think it's probably too late to change it now and it's
not ambiguous, just weird-looking.

> And Injection-Date: a sub-field of Injection-Info: (but maybe it was
> done this way because it was easier to parse in order to obtain the
> date?).

We were trying to avoid the current situation where there are something
like five different trace fields that different bits of software fills
out.  Since you rarely need access to that information, it seemed better
to collapse it into one field that one could parse when needed.

--=20

From: =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Tr: Injection-Info
Date: Sat, 9 May 2009 19:15:53 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Just for your information (from news.software.nntp).

It is true that
    "Injection-Info: nowhere;posting-host=localhost:::1"
is not pretty to read and "posting-host" could have been
shortened to "host"...

And Injection-Date: a sub-field of Injection-Info: (but maybe
it was done this way because it was easier to parse in order
to obtain the date?).

Julien

----- Message d'origine ----- 
De : "D. Stussy" <[email-masked]>
Groupes de discussion : news.software.nntp
Envoyé : mercredi 29 avril 2009 00:55
Objet : Re: Injection-Info

> "Russ Allbery" <[email-masked]> wrote in message
> news:[email-masked]...
>> http://www.eyrie.org/~eagle/usefor/drafts/draft-ietf-usefor-usefor-12.txt
>> has the specification.  (You can also get that I-D from a bunch of other
>> places, including direct from the IETF, of course.)
>
> Q:  Why is "Injection-Date" a separate header and not a sub-field of
> "Injection-Info"?
>
> Also, under "Injection-Info" syntax:
>
> host-value      =  dot-atom-text / IPv4address / IPv6address /
>                      (dot-atom-text ":" ( IPv4address / IPv6address ))
>
> If specifying both a hostname (as "dot-atom-text") and an IP address, why
> not make the IP address a CWFS comment?  I really don't like that colon as
> IPv6 address literals may start with a double-colon, and the effective
> triple-colon would look ugly.  (OK, so maybe it shouldn't happen except for
> localhost since IPv4-mapped and IPv4-compatible IPv6 addresses shouldn't be
> sources, but the syntax doesn't forbid such.)
>
> e.g.  "Injection-Info: nowhere;posting-host=localhost:::1"
> vs.   "Injection-Info: nowhere;posting-host=localhost (::1)"
>
> BNF:  "/", not "|" in specifying an option (choose one of)?  Hmmmm.
>
> In the "Injection-Info" parameters, do we really have to say "posting-host"
> instead of just "host", and "posting-account" instead of just "account" (or
> "acct")?  Isn't that understood from the header itself?
>
> ------
> Another thought:  If "Supersedes" must not exist with "Control" functions,
> why not make the supersedes function itself a control function (i.e.
> "supersedes" becomes a verb)?  Won't that will prevent the problem?  This
> way, it also parallels the "cancel" operation (if that's still to be
> supported).  For backwards compatibility only, allow the separate header
> (possibly having a server rewrite any "Supersedes: <data>" header into
> "Control: supersedes <data>", thus also removing any other "Control:"
> header).

From: =?iso-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
To: <[email-masked]>
Subject: Re: ISSUE 1583 status
Date: Sat, 9 May 2009 09:17:58 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Hi Russ,

> Existing checkgroups implementations will completely ignore the scope
> syntax and process the checkgroups anyway.  The backward compatibility
> issue is that we have to be sure that nothing bad happens when they do
> that.  I don't remember the exact details, but I think we decided that
> was why it was hard to do anything better than what we have here.

OK, thanks.

It is true that we currently have:
    checkgroups:[email-masked]:cn.bbs.*:verify-cn.bbs.admin.announce
so including "cn.bbs" in this checkgroups will not be honoured.  Only
the checkgroups for "cn.*" can currently act upon "cn.bbs".

-- 
Julien ÉLIE

« Le travail est l'opium du peuple et
  je ne veux pas mourir drogué. » (Boris Vian) 

To: <[email-masked]>
Subject: Re: ISSUE 1583 status
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Fri, 08 May 2009 15:28:11 -0700
Sender: [email-masked]

Julien =C9LIE <[email-masked]> writes:

>> The first issue is that there's no method in the checkgroups syntax
>> to delegate control over a newsgroup whose name matches the
>> subhierarchy.  I think we agreed that, yes, this is the case, and
>> there's nothing we can really do about it at this stage and while
>> still remaining backwards-compatible.
>
> Yet, checkgroups scope is new with USEPRO; it is not mentioned in RFC
> 1036 or its son.  So what is not backwards-compatible with it?  It is
> a new notion.  Unless I missed something?

Existing checkgroups implementations will completely ignore the scope
syntax and process the checkgroups anyway.  The backward compatibility
issue is that we have to be sure that nothing bad happens when they do
that.  I don't remember the exact details, but I think we decided that
was why it was hard to do anything better than what we have here.

--=20

From: =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Re: I-D ACTION:draft-spencer-usefor-son-of-1036-00.txt
Date: Fri, 8 May 2009 20:57:11 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Hi Harald,

>> RFC 2822 (5322) does not allow "-0500 (EST)"; it is directly "(EST)",
>> though obsolete.
>
> actually (EST) is considered a comment in 2822/5322, so it's perfectly legitimate.

Oh, indeed, it is the famous CFWS (Comment Folding White Space).  Thanks
for your indication.

-- 
Julien ÉLIE

« Boire du café empêche de dormir. Par contre, dormir empêche de boire
  du café. » (Philippe Geluck) 

Date: Fri, 08 May 2009 16:41:40 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: =?windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
CC: Usefor WG <[email-masked]>
Subject: Re: I-D ACTION:draft-spencer-usefor-son-of-1036-00.txt
Sender: [email-masked]

Julien ÉLIE skrev:
>
>
> It is amusing to see in the example 4.7:
>
>    Date: Mon, 17 Jan 1994 11:14:55 -0500 (EST)
>
> I thought there was a problem but I saw this syntax is valid and
> defined in "Son of 1036":
>
>      timezone      = "UT" / "GMT"
>                    / ( "+" / "-" ) hh mm [ space "(" zone-name ")" ]
>
> RFC 2822 (5322) does not allow "-0500 (EST)"; it is directly "(EST)",
> though obsolete.
actually (EST) is considered a comment in 2822/5322, so it's perfectly 
legitimate.

From: =?iso-8859-1?Q?Julien_=C9LIE?= <[email-masked]>
To: <[email-masked]>
Subject: Re: ISSUE 1583 status (was: Re: January: open issues on USEPRO)
Date: Fri, 8 May 2009 12:12:11 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Hi Russ,

>>> 1583 USEPRO LC 5.2.3: Checkgroups control messages
>>>    Open. There may be multiple issues here.
>>>    No discussion with "1583" in the subject.
>
> The first issue is that there's no method in the checkgroups syntax to
> delegate control over a newsgroup whose name matches the subhierarchy.  I
> think we agreed that, yes, this is the case, and there's nothing we can
> really do about it at this stage and while still remaining
> backwards-compatible.

Yet, checkgroups scope is new with USEPRO; it is not mentioned in RFC 1036
or its son.  So what is not backwards-compatible with it?
It is a new notion.  Unless I missed something?

> I'm a little worried about this provision,
> since after long periods of time and a change of hierarchy administration
> it can be potentially difficult to uncover the previous serial number.
> But I don't see a good alternative that preserves the serial number
> semantics.
>
> The fourth issue is whether there should be a mechanism to reset the
> serial number.  I think we decided that we weren't going to specify one.

A possibility would have been to do it in the headers of a new checkgroups
(specifying it resets the previous serial number).  This way, no missed
"reset article".

-- 
Julien ÉLIE

« Boire du café empêche de dormir. Par contre, dormir empêche de boire
  du café. » (Philippe Geluck) 

From: =?Windows-1252?Q?Julien_=C9LIE?= <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Re: I-D ACTION:draft-spencer-usefor-son-of-1036-00.txt
Date: Fri, 8 May 2009 12:02:16 +0200
Organization: TrigoFACILE -- http://www.trigofacile.com/
Sender: [email-masked]

Hi Charles,

> http://www.imc.org/ietf-usefor/drafts/draft-spencer-usefor-son-of-1036-00.txt.
>
> The intention it to leave it here for a few days so as to let people on
> this list spot any nits in it. Then it will be submitted to the RFC-Editor
> as an Historic RFC which can then be properly referred to from our two
> main USEFPR and USEPRO documents (which are currently in AUTH 48).

Thanks for that work!
It is very useful to have such an historic RFC (which defines sendsys,
whogets, version, with archaeological notes on A-News, etc.).  Besides,
"Son of 1036" was a must-have!

I do not have much to say.  Having skimmed through it, the only nits I see
are typos (missing double spaces after full dots in the first two pages --
status of this memo, copyright and abstract).
I also see ". [RFC1036]" (p. 5, 16, 32, 58, 76) without a double space
and ".([RFC 977]" (page 34) without spaces at all.

I also noted in 6.5, page 42 "retrospect, , and".

I very probably have missed other things (not having read the whole draft).

It is amusing to see in the example 4.7:

    Date: Mon, 17 Jan 1994 11:14:55 -0500 (EST)

I thought there was a problem but I saw this syntax is valid and
defined in "Son of 1036":

      timezone      = "UT" / "GMT"
                    / ( "+" / "-" ) hh mm [ space "(" zone-name ")" ]

RFC 2822 (5322) does not allow "-0500 (EST)"; it is directly "(EST)",
though obsolete.

The part on transmission formats (rnews batches and encoded batches)
is not dealt with by USEFOR.  Is it totally dropped by the working group?
(Not relevant, like UUCP?)

Incidentally, the preface is pretty clear!  A great work!

-- 
Julien ÉLIE

« Boire du café empêche de dormir. Par contre, dormir empêche de boire
  du café. » (Philippe Geluck) 

Date: Thu, 7 May 2009 14:18:12 +0100 (BST)
From: Charles Lindsey <[email-masked]>
To: "Usefor WG" <[email-masked]>
Subject: Fwd: I-D ACTION:draft-spencer-usefor-son-of-1036-00.txt
Sender: [email-masked]

I am forwarding this to the Usefor WG because the drafts editor did not
spot that it belonged here. I have also put it up at
http://www.imc.org/ietf-usefor/drafts/draft-spencer-usefor-son-of-1036-00.txt.
I have been working with Henry Spencer on it over the past couple of
weeks.

The intention it to leave it here for a few days so as to let people on
this list spot any nits in it. Then it will be submitted to the RFC-Editor
as an Historic RFC which can then be properly referred to from our two
main USEFPR and USEPRO documents (which are currently in AUTH 48).

>From: [email-masked]
>To: [email-masked]
>Subject: I-D ACTION:draft-spencer-usefor-son-of-1036-00.txt 
>Content-Type: Multipart/Mixed; Boundary="NextPart"
>Mime-Version: 1.0
>Message-Id: <[email-masked]>
>Date: Mon,  4 May 2009 16:15:02 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: "Son of 1036":  News Article Format and Transmission
	Author(s)	: H. Spencer
	Filename	: draft-spencer-usefor-son-of-1036-00.txt
	Pages		: 91
	Date		: 2009-5-3
	
   By the early 1990s it had become clear that RFC 1036, the then
   specification for the Interchange of USENET Messages, was badly in
   need of repair. This "INTERNET DRAFT to be", though never formally
   published at that time, was widely circulated and became the de facto
   standard for implementors of News Servers and User Agents, rapidly
   acquiring the nickname "Son of 1036". Indeed, under that name, it
   could fairly be described as the best-known Internet Draft (n)ever
   published, and it formed the starting point for the recently adopted
   Proposed Standards for Netnews.

   It is being published now in order to provide the Historical
   Background out of which those standards have grown. Present-day
   implementors should be aware that it is NOT NOW APPROPRIATE for use
   in current implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-spencer-usefor-son-of-1036-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--NextPart
Content-Type: Message/External-body;
	name="draft-spencer-usefor-son-of-1036-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

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