draft-ietf-usefor-usepro-07.txt   draft-ietf-usefor-usepro-08.txt 
Usenet Format Working Group R. Allbery, Ed. Usenet Format Working Group R. Allbery, Ed.
Internet-Draft Stanford University Internet-Draft Stanford University
Obsoletes: 1036 (if approved) C. Lindsey Obsoletes: 1036 (if approved) C. Lindsey
Intended status: Standards Track University of Manchester Intended status: Standards Track University of Manchester
Expires: July 7, 2007 January 3, 2007 Expires: January 2, 2008 July 1, 2007
Netnews Architecture and Protocols Netnews Architecture and Protocols
draft-ietf-usefor-usepro-07 draft-ietf-usefor-usepro-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 7, 2007. This Internet-Draft will expire on January 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines the architecture of Netnews systems and This document defines the architecture of Netnews systems and
specifies the correct manipulation and interpretation of Netnews specifies the correct manipulation and interpretation of Netnews
articles by software which originates, distributes, stores, and articles by software which originates, distributes, stores, and
displays them. It also specifies the requirements that must be met displays them. It also specifies the requirements that must be met
by any protocol used to transport and serve Netnews articles. by any protocol used to transport and serve Netnews articles.
Internet Draft Comments Internet Draft Comments
skipping to change at page 3, line 32 skipping to change at page 3, line 32
3.2.1. Constructing the Path Header Field . . . . . . . . . . 10 3.2.1. Constructing the Path Header Field . . . . . . . . . . 10
3.2.2. Path Header Field Example . . . . . . . . . . . . . . 11 3.2.2. Path Header Field Example . . . . . . . . . . . . . . 11
3.3. Duties of a Posting Agent . . . . . . . . . . . . . . . . 12 3.3. Duties of a Posting Agent . . . . . . . . . . . . . . . . 12
3.3.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Reinjection of Articles . . . . . . . . . . . . . . . 13 3.3.2. Reinjection of Articles . . . . . . . . . . . . . . . 13
3.3.3. Followups . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. Followups . . . . . . . . . . . . . . . . . . . . . . 13
3.3.4. Construction of the References Header Field . . . . . 14 3.3.4. Construction of the References Header Field . . . . . 14
3.4. Duties of an Injecting Agent . . . . . . . . . . . . . . . 15 3.4. Duties of an Injecting Agent . . . . . . . . . . . . . . . 15
3.4.1. Forwarding Messages to a Moderator . . . . . . . . . . 17 3.4.1. Forwarding Messages to a Moderator . . . . . . . . . . 17
3.5. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 18 3.5. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 18
3.6. Duties of a Serving Agent . . . . . . . . . . . . . . . . 19 3.6. Duties of a Serving Agent . . . . . . . . . . . . . . . . 20
3.7. Duties of a Reading Agent . . . . . . . . . . . . . . . . 21 3.7. Duties of a Reading Agent . . . . . . . . . . . . . . . . 21
3.8. Duties of a Moderator . . . . . . . . . . . . . . . . . . 21 3.8. Duties of a Moderator . . . . . . . . . . . . . . . . . . 21
3.9. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 22 3.9. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 23
3.9.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 23 3.9.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 24
3.9.2. Duties of an Incoming Gateway . . . . . . . . . . . . 24 3.9.2. Duties of an Incoming Gateway . . . . . . . . . . . . 24
3.9.3. Gateway Example . . . . . . . . . . . . . . . . . . . 26 3.9.3. Gateway Example . . . . . . . . . . . . . . . . . . . 26
4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. application/news-transmission . . . . . . . . . . . . . . 28 4.1. application/news-transmission . . . . . . . . . . . . . . 28
4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 29 4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 29
4.3. application/news-checkgroups . . . . . . . . . . . . . . . 30 4.3. application/news-checkgroups . . . . . . . . . . . . . . . 30
5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 32 5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 32
5.1. Authentication and Authorization . . . . . . . . . . . . . 32 5.1. Authentication and Authorization . . . . . . . . . . . . . 32
5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 33 5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 33
5.2.1. The newgroup Control Message . . . . . . . . . . . . . 33 5.2.1. The newgroup Control Message . . . . . . . . . . . . . 33
skipping to change at page 10, line 39 skipping to change at page 10, line 39
2. An injecting agent SHOULD prepend the <path-diagnostic> 2. An injecting agent SHOULD prepend the <path-diagnostic>
"!.POSTED", optionally followed by "." and the FQDN or IP address "!.POSTED", optionally followed by "." and the FQDN or IP address
of the source, to the Path header field content. of the source, to the Path header field content.
3. A relaying or serving agent SHOULD prepend a <path-diagnostic> to 3. A relaying or serving agent SHOULD prepend a <path-diagnostic> to
the Path header field content, where the <path-diagnostic> is the Path header field content, where the <path-diagnostic> is
chosen as follows: chosen as follows:
* If the expected <path-identity> of the source of the article * If the expected <path-identity> of the source of the article
matches the leftmost <path-identity> of the Path header matches the leftmost <path-identity> of the Path header
field's content, use "!" (<diag-match>). field's content, use "!" (<diag-match>), resulting in two
consecutive "!"s.
* If the expected <path-identity> of the source of the article * If the expected <path-identity> of the source of the article
does not match, use "!.MISMATCH." followed by the expected does not match, use "!.MISMATCH." followed by the expected
<path-identity> of the source or its IP address. <path-identity> of the source or its IP address.
* If the relaying or serving agent is not willing or able to * If the relaying or serving agent is not willing or able to
check the <path-identity>, use "!.SEEN." followed by the FQDN, check the <path-identity>, use "!.SEEN." followed by the FQDN,
IP address, or expected <path-identity> of the source. IP address, or expected <path-identity> of the source.
4. The agent MUST then prepend its own <path-identity> to the Path Be aware that [RFC1036] did not include <path-diagnostic>.
header field content. Implementations which predate this specification will add only
single "!" characters between <path-identity> strings.
5. The agent MAY then prepend additional <path-identity>s for itself 4. The agent MAY then prepend to the Path header field content "!"
to the Path header field content, following each <path-identity> or "!!" followed by an additional <path-identity> for itself
so added with either "!!" or "!". This is permitted for agents other than its primary one. Using "!!", and thereby adding a
that have multiple <path-identity>s (such as during a transition <diag-match> since the <path-identity> clearly is verified, is
from one to another). Each of these <path-identity>s MUST meet RECOMMENDED. This step may be repeated any number of times.
the requirements set out in Section 3.2. This is permitted for agents that have multiple <path-identity>s
(such as during a transition from one to another). Each of these
<path-identity>s MUST meet the requirements set out in
Section 3.2.
5. Finally, the agent MUST prepend its primary <path-identity> to
the Path header field content. The primary <path-identity> is
the <path-identity> it normally advertises to its peers for their
use in generating <path-diagnostic>s as described above.
Any agent which modifies the Path header field MAY fold it by Any agent which modifies the Path header field MAY fold it by
inserting FWS immediately after any <path-identity> or <diag-other> inserting FWS immediately after any <path-identity> or <diag-other>
it added (see section 3.1.5 of [USEFOR] for allowable locations for it added (see section 3.1.5 of [USEFOR] for allowable locations for
FWS). FWS).
3.2.2. Path Header Field Example 3.2.2. Path Header Field Example
Here is an example of a Path header field created following the rules Here is an example of a Path header field created following the rules
for injecting and relaying agents. for injecting and relaying agents.
skipping to change at page 11, line 49 skipping to change at page 12, line 10
old.site.example relayed it to a news server using the <path- old.site.example relayed it to a news server using the <path-
identity> of bar.isp.example and claiming (by using the "!!" <path- identity> of bar.isp.example and claiming (by using the "!!" <path-
delimiter>) to have verified that it came from old.site.example. delimiter>) to have verified that it came from old.site.example.
bar.isp.example relayed it to foo-news which, not being convinced bar.isp.example relayed it to foo-news which, not being convinced
that it truly came from bar.isp.example, inserted the <diag-keyword> that it truly came from bar.isp.example, inserted the <diag-keyword>
"MISMATCH" and then stated that it received the article from the IPv6 "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 address [2001:DB8:0:0:8:800:200C:417A]. (This is not to say that
bar.isp.example was not a correct <path-identity> for that source but bar.isp.example was not a correct <path-identity> for that source but
simply that that identity did not match the expectations of foo-news. simply that that identity did not match the expectations of foo-
news.)
foo-news then passed the article to foo.isp.example, which declined foo-news then passed the article to foo.isp.example, which declined
to validate its <path-identity> and instead appended the <diag- to validate its <path-identity> and instead appended the <diag-
keyword> "SEEN" to indicate it knows the source of the article as keyword> "SEEN" to indicate it knows the source of the article as
isp.example. This may be either an expected <path-identity> or the isp.example. This may be either an expected <path-identity> or the
FQDN of the system from which it received the article. Presumably FQDN of the system from which it received the article. Presumably
foo.isp.example is a serving agent that then delivered the article to foo.isp.example is a serving agent that then delivered the article to
a reading agent. a reading agent.
baz.isp.example, bar.isp.example, and foo-news folded the Path header baz.isp.example, bar.isp.example, and foo-news folded the Path header
skipping to change at page 16, line 33 skipping to change at page 16, line 42
5. The Message-ID and Date header fields with appropriate contents 5. The Message-ID and Date header fields with appropriate contents
MUST be added when not present in the proto-article. MUST be added when not present in the proto-article.
6. The injecting agent MUST NOT alter the body of the article in 6. The injecting agent MUST NOT alter the body of the article in
any way (including any change of Content-Transfer-Encoding). It any way (including any change of Content-Transfer-Encoding). It
MAY add other header fields not already provided by the poster, MAY add other header fields not already provided by the poster,
but injecting agents are encouraged to use the Injection-Info but injecting agents are encouraged to use the Injection-Info
header for such information and to minimize the addition of header for such information and to minimize the addition of
other headers. It SHOULD NOT alter, delete, or reorder any other headers. It SHOULD NOT alter, delete, or reorder any
existing header field except the Path header. existing header field except the Path header field. It MUST NOT
alter or delete any existing Message-ID header field.
7. If the Newsgroups header contains one or more moderated groups 7. If the Newsgroups header contains one or more moderated groups
and the proto-article does not contain an Approved header field, and the proto-article does not contain an Approved header field,
the injecting agent MUST either forward it to a moderator as the injecting agent MUST either forward it to a moderator as
specified in Section 3.4.1 or, if that is not possible, reject specified in Section 3.4.1 or, if that is not possible, reject
it. This forwarding MUST be done after adding the Message-ID it. This forwarding MUST be done after adding the Message-ID
and Date headers if required, and before adding the Injection- and Date headers if required, and before adding the Injection-
Info and Injection-Date headers. Info and Injection-Date headers.
8. Otherwise, a Path header field with a <tail-entry> MUST be added 8. Otherwise, a Path header field with a <tail-entry> MUST be added
skipping to change at page 18, line 23 skipping to change at page 18, line 33
Injector-Info headers, relaying agents SHOULD accept articles only Injector-Info headers, relaying agents SHOULD accept articles only
from trusted agents. from trusted agents.
An article SHOULD NOT be relayed unless the sending agent has been An article SHOULD NOT be relayed unless the sending agent has been
configured to supply and the receiving agent to receive at least one configured to supply and the receiving agent to receive at least one
of the <newsgroup-name>s in its Newsgroups header field and at least of the <newsgroup-name>s in its Newsgroups header field and at least
one of the <dist-name>s in its Distribution header field (if one of the <dist-name>s in its Distribution header field (if
present). Exceptionally, control messages creating or removing present). Exceptionally, control messages creating or removing
newsgroups (newgroup or rmgroup control messages, for example) SHOULD newsgroups (newgroup or rmgroup control messages, for example) SHOULD
be relayed if the affected group appears in its Newsgroups header be relayed if the affected group appears in its Newsgroups header
field and and the sending agent and receiving relaying agents are field and both the sending and receiving relaying agents are
both configured to relay a newsgroup of that name (whether or not configured to relay a newsgroup of that name (whether or not such a
such a newsgroup exists). newsgroup exists).
In order to avoid unnecessary relaying attempts, an article SHOULD In order to avoid unnecessary relaying attempts, an article SHOULD
NOT be relayed if the <path-identity> of the receiving agent (or some NOT be relayed if the <path-identity> of the receiving agent (or some
known alias thereof) appears as a <path-identity> (excluding within known alias thereof) appears as a <path-identity> (excluding within
the <tail-entry> or following a "POSTED" <diag-keyword>) in its Path the <tail-entry> or following a "POSTED" <diag-keyword>) in its Path
header field. header field.
A relaying agent processes an article as follows: A relaying agent processes an article as follows:
1. It MUST reject any article without a Newsgroups header field or 1. It MUST reject any article without a Newsgroups header field or
skipping to change at page 19, line 23 skipping to change at page 19, line 31
control message or Supersedes header field. control message or Supersedes header field.
6. It MAY reject any article without an Approved header field posted 6. It MAY reject any article without an Approved header field posted
to a newsgroup known to be moderated. This practice is strongly to a newsgroup known to be moderated. This practice is strongly
encouraged but the information necessary to do so is not required encouraged but the information necessary to do so is not required
to be maintained by a relaying agent. to be maintained by a relaying agent.
7. It MUST update the Path header field as described in 7. It MUST update the Path header field as described in
Section 3.2.1. Section 3.2.1.
8. It MAY delete any Xref header field present and MAY add a new 8. It MAY delete any Xref header field already present. It MAY add
Xref header field with any valid content. The Xref header field a new Xref header field for its own use (but recall that [USEFOR]
is not used by relaying agents, but relaying agents that are also permits at most one such header field).
serving agents may generate Xref header fields for their own
internal purposes.
9. Finally, it passes the article on to other relaying and serving 9. Finally, it passes the article on to other relaying and serving
agents to which it is configured to send articles. agents to which it is configured to send articles.
Relaying agents SHOULD, where possible in the underlying transport, Relaying agents SHOULD, where possible in the underlying transport,
inform the agent that passed the article to the relaying agent if the inform the agent that passed the article to the relaying agent if the
article was rejected. Relaying agents MUST NOT inform any other article was rejected. Relaying agents MUST NOT inform any other
external entity of the rejection of an article unless that external external entity of the rejection of an article unless that external
entity has explicitly requested that it be informed of such errors. entity has explicitly requested that it be informed of such errors.
skipping to change at page 20, line 46 skipping to change at page 21, line 8
5. It MUST reject any article without an Approved header field 5. It MUST reject any article without an Approved header field
posted to any newsgroup listed as moderated. posted to any newsgroup listed as moderated.
6. It MUST update the Path header field as described in 6. It MUST update the Path header field as described in
Section 3.2.1. Section 3.2.1.
7. It MUST (except when specially configured to preserve the 7. It MUST (except when specially configured to preserve the
<article-locator>s set by the sending site) remove any Xref <article-locator>s set by the sending site) remove any Xref
header field from each article. It then MAY (and usually will) header field from each article. It then MAY (and usually will)
generate a fresh Xref header field. add a new Xref header field (but recall that [USEFOR] permits at
most one such header field).
8. Finally, it stores the article and makes it available for reading 8. Finally, it stores the article and makes it available for reading
agents. agents.
Serving agents MUST NOT create new newsgroups simply because an Serving agents MUST NOT create new newsgroups simply because an
unrecognized <newsgroup-name> occurs in a Newsgroups header field. unrecognized <newsgroup-name> occurs in a Newsgroups header field.
Newsgroups are normally created via control messages (Section 5.2.1). Newsgroups are normally created via control messages (Section 5.2.1).
Serving agents MUST NOT alter, delete, or rearrange any part of an Serving agents MUST NOT alter, delete, or rearrange any part of an
article except for the Path and Xref header fields. They MUST NOT article except for the Path and Xref header fields. They MUST NOT
skipping to change at page 29, line 46 skipping to change at page 29, line 46
groupinfo-body = [ newsgroups-tag CRLF ] groupinfo-body = [ newsgroups-tag CRLF ]
newsgroups-line CRLF newsgroups-line CRLF
newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP
%x6E.65.77.73.67.72.6F.75.70.73 SP %x6E.65.77.73.67.72.6F.75.70.73 SP
%x66.69.6C.65.3A %x66.69.6C.65.3A
; case sensitive ; case sensitive
; "For your newsgroups file:" ; "For your newsgroups file:"
newsgroups-line = newsgroup-name newsgroups-line = newsgroup-name
[ 1*HTAB newsgroup-description ] [ 1*HTAB newsgroup-description ]
[ 1*WSP moderation-flag ] [ *WSP moderation-flag ]
newsgroup-description newsgroup-description
= eightbit-utext *( *WSP eightbit-utext ) = eightbit-utext *( *WSP eightbit-utext )
moderation-flag = %x28.4D.6F.64.65.72.61.74.65.64.29 moderation-flag = SP "(" %4D.6F.64.65.72.61.74.65.64 ")"
; case sensitive "(Moderated)" ; SPACE + case sensitive "(Moderated)"
eightbit-utext = utext / %d127-255 eightbit-utext = utext / %d127-255
This unusual format is backward-compatible with the scanning of the This unusual format is backward-compatible with the scanning of the
body of newgroup control messages for descriptions done by Netnews body of newgroup control messages for descriptions done by Netnews
implementations that predate this specification. Although optional, implementations that predate this specification. Although optional,
the <newsgroups-tag> SHOULD be included for backward compatibility. the <newsgroups-tag> SHOULD be included for backward compatibility.
The <newsgroup-description> MUST NOT contain any occurrence of the The <newsgroup-description> MUST NOT contain any occurrence of the
string "(Moderated)" within it. Moderated newsgroups MUST be marked string "(Moderated)" within it. Moderated newsgroups MUST be marked
by appending the case sensitive text " (Moderated)" at the end. by appending the case sensitive text " (Moderated)" at the end.
While a charset parameter is defined for this media type, most While a charset parameter is defined for this media type, most
existing software does not understand MIME header fields or correctly existing software does not understand MIME header fields or correctly
handle descriptions in a variety of charsets. Using a charset of US- handle descriptions in a variety of charsets. Using a charset of US-
ASCII where possible is therefore RECOMMENDED; if not possible, UTF-8 ASCII where possible is therefore RECOMMENDED; if not possible, UTF-8
[RFC3629] SHOULD be used. Regardless of the charset used, the [RFC3629] SHOULD be used. Regardless of the charset used, the
constraints of the above grammar MUST be met and the <newsgroup-name> constraints of the above grammar MUST be met and the <newsgroup-name>
MUST be represented using the same octets as would be used with a MUST be represented in that charset using the same octets as would be
charset of US-ASCII. used with a charset of US-ASCII.
4.3. application/news-checkgroups 4.3. application/news-checkgroups
The application/news-checkgroups media type contains a list of The application/news-checkgroups media type contains a list of
newsgroups within a hierarchy or hierarchies, including their newsgroups within a hierarchy or hierarchies, including their
descriptions and moderation status. It is primarily for use with the descriptions and moderation status. It is primarily for use with the
checkgroups control message (see Section 5.2.3). checkgroups control message (see Section 5.2.3).
The MIME media type definition of application/news-checkgroups is: The MIME media type definition of application/news-checkgroups is:
skipping to change at page 38, line 17 skipping to change at page 38, line 17
The ihave and sendme control messages implement a predecessor of the The ihave and sendme control messages implement a predecessor of the
NNTP [RFC3977] protocol. They are largely obsolete on the Internet NNTP [RFC3977] protocol. They are largely obsolete on the Internet
but still see use in conjunction with some transport protocols such but still see use in conjunction with some transport protocols such
as UUCP. News servers are not required to support them. as UUCP. News servers are not required to support them.
ihave and sendme control messages share similar syntax for their ihave and sendme control messages share similar syntax for their
Control header fields and bodies: Control header fields and bodies:
control-command =/ Ihave-command control-command =/ Ihave-command
Ihave-command = "ihave" Ihave-arguments Ihave-command = "ihave" Ihave-arguments
Ihave-arguments = 1*WSP relayer-name Ihave-arguments = 1*WSP *( msg-id 1*WSP ) relayer-name
/ 1*( 1*WSP msg-id ) [ 1*WSP relayer-name ]
control-command =/ Sendme-command control-command =/ Sendme-command
Sendme-command = "sendme" Sendme-arguments Sendme-command = "sendme" Sendme-arguments
Sendme-arguments = Ihave-arguments Sendme-arguments = Ihave-arguments
relayer-name = path-identity ; see 3.1.5 of [USEFOR] relayer-name = path-identity ; see 3.1.5 of [USEFOR]
ihave-body = *( msg-id CRLF ) ihave-body = *( msg-id CRLF )
sendme-body = ihave-body sendme-body = ihave-body
The body of the article consists of a list of <msg-id>s, one per The body of the article consists of a list of <msg-id>s, one per
line. The message identifiers SHOULD be put in the body of the line. The message identifiers SHOULD be put in the body of the
article, not in the Control header field, but news servers MAY article, not in the Control header field, but news servers MAY
recognize and process message identifiers in the Control header field recognize and process message identifiers in the Control header field
for backward compatibility. Message identifiers MUST NOT be put in for backward compatibility. Message identifiers MUST NOT be put in
the Control header field if they are present in the body of the the Control header field if they are present in the body of the
control message. control message.
The ihave message states that the named relaying agent has received The ihave message states that the named relaying agent has received
articles with the specified message identifiers, which may be of articles with the specified message identifiers, which may be of
interest to the relaying agents receiving the ihave message. The interest to the relaying agents receiving the ihave message. The
sendme message requests that the agent receiving it send the articles sendme message requests that the agent receiving it send the articles
having the specified message identifiers to the named relaying agent. having the specified message identifiers to the named relaying agent.
If <relayer-name> is not given, it is determined from the origin of Contrary to [RFC1036], the relayer-name MUST be given as the last
the control message. argument in the Control header field.
Upon receipt of the sendme message (and a decision to honor it), the Upon receipt of the sendme message (and a decision to honor it), the
receiving agent sends the article or articles requested. The receiving agent sends the article or articles requested. The
mechanism for this transmission is unspecified by this document and mechanism for this transmission is unspecified by this document and
is arranged between the sites involved. is arranged between the sites involved.
These control messages are normally sent as point-to-point articles These control messages are normally sent as point-to-point articles
between two sites and not then sent on to other sites. Newsgroups between two sites and not then sent on to other sites. Newsgroups
beginning with "to." are reserved for such point-to-point beginning with "to." are reserved for such point-to-point
communications and are formed by prepending "to." to a <relayer-name> communications and are formed by prepending "to." to a <relayer-name>
skipping to change at page 46, line 45 skipping to change at page 46, line 45
o Two new optional parameters are added to the checkgroups control o Two new optional parameters are added to the checkgroups control
message. message.
o The message/news media type is declared obsolete. o The message/news media type is declared obsolete.
o Cancel control messages are no longer required to have From and o Cancel control messages are no longer required to have From and
Sender header fields matching those of the target message, as this Sender header fields matching those of the target message, as this
requirement added no real security. requirement added no real security.
o The relayer-name parameter in the Control header field of ihave
and sendme control messages is now required.
In addition, many protocol steps and article verification In addition, many protocol steps and article verification
requirements unmentioned or left ambiguous by [RFC1036] but widely requirements unmentioned or left ambiguous by [RFC1036] but widely
implemented by Netnews servers have been standardized and specified implemented by Netnews servers have been standardized and specified
in detail. in detail.
Appendix B. Acknowledgements Appendix B. Acknowledgements
This document is the result of a ten year effort and the number of This document is the result of a ten year effort and the number of
people that have contributed to its content are too numerous to people that have contributed to its content are too numerous to
mention individually. Many thanks go out to all past and present mention individually. Many thanks go out to all past and present
skipping to change at page 49, line 7 skipping to change at page 49, line 7
Heald Green Heald Green
Cheadle Cheadle
Cheshire SK8 3JU Cheshire SK8 3JU
United Kingdom United Kingdom
Phone: +44 161 436 6131 Phone: +44 161 436 6131
Email: chl@clerew.man.ac.uk Email: chl@clerew.man.ac.uk
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 22 change blocks. 
41 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/