Commit in docs/usefor (usepro.xml)
[email protected] Mon, 25 May 2009 16:52:25 -0700 (PDT)
| Newsgroups | gmane.ietf.usenet.format |
|---|---|
| Message-ID | <[email protected]> |
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 <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, <newsgroup-name>, and
@@ -1843,7 +1824,8 @@
header field starting with the string "cmsg " 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 <newsgroup-name>
+ header field as ambiguous. Likewise, the presence of a
+ <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>