draft-ietf-usefor-usepro-11.txt   draft-ietf-usefor-usepro-12.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: February 23, 2009 August 22, 2008 Expires: February 28, 2009 August 27, 2008
Netnews Architecture and Protocols Netnews Architecture and Protocols
draft-ietf-usefor-usepro-11 draft-ietf-usefor-usepro-12
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 February 23, 2009. This Internet-Draft will expire on February 28, 2009.
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 18 skipping to change at page 3, line 18
Working Group at ietf-usefor@imc.org. Working Group at ietf-usefor@imc.org.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Duties of Agents . . . . . . . . . . . . . . . . . . . . . . . 8 3. Duties of Agents . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. General Principles . . . . . . . . . . . . . . . . . . . . 8 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 9
3.2. The Path Header Field . . . . . . . . . . . . . . . . . . 9 3.2. The Path Header Field . . . . . . . . . . . . . . . . . . 10
3.2.1. Constructing the Path Header Field . . . . . . . . . . 10 3.2.1. Constructing the Path Header Field . . . . . . . . . . 11
3.2.2. Path Header Field Example . . . . . . . . . . . . . . 11 3.2.2. Path Header Field Example . . . . . . . . . . . . . . 12
3.3. Article History and Duplicate Suppression . . . . . . . . 12 3.3. Article History and Duplicate Suppression . . . . . . . . 13
3.4. Duties of a Posting Agent . . . . . . . . . . . . . . . . 13 3.4. Duties of a Posting Agent . . . . . . . . . . . . . . . . 14
3.4.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 14 3.4.1. Proto-articles . . . . . . . . . . . . . . . . . . . . 15
3.4.2. Multiple Injection of Articles . . . . . . . . . . . . 14 3.4.2. Multiple Injection of Articles . . . . . . . . . . . . 15
3.4.3. Followups . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Followups . . . . . . . . . . . . . . . . . . . . . . 16
3.4.4. Construction of the References Header Field . . . . . 16 3.4.4. Construction of the References Header Field . . . . . 17
3.5. Duties of an Injecting Agent . . . . . . . . . . . . . . . 17 3.5. Duties of an Injecting Agent . . . . . . . . . . . . . . . 18
3.5.1. Forwarding Messages to a Moderator . . . . . . . . . . 19 3.5.1. Forwarding Messages to a Moderator . . . . . . . . . . 20
3.6. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 20 3.6. Duties of a Relaying Agent . . . . . . . . . . . . . . . . 21
3.7. Duties of a Serving Agent . . . . . . . . . . . . . . . . 22 3.7. Duties of a Serving Agent . . . . . . . . . . . . . . . . 23
3.8. Duties of a Reading Agent . . . . . . . . . . . . . . . . 23 3.8. Duties of a Reading Agent . . . . . . . . . . . . . . . . 24
3.9. Duties of a Moderator . . . . . . . . . . . . . . . . . . 23 3.9. Duties of a Moderator . . . . . . . . . . . . . . . . . . 24
3.10. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 25 3.10. Duties of a Gateway . . . . . . . . . . . . . . . . . . . 26
3.10.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 26 3.10.1. Duties of an Outgoing Gateway . . . . . . . . . . . . 27
3.10.2. Duties of an Incoming Gateway . . . . . . . . . . . . 27 3.10.2. Duties of an Incoming Gateway . . . . . . . . . . . . 28
3.10.3. Gateway Example . . . . . . . . . . . . . . . . . . . 29 3.10.3. Gateway Example . . . . . . . . . . . . . . . . . . . 30
4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 30 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. application/news-transmission . . . . . . . . . . . . . . 30 4.1. application/news-transmission . . . . . . . . . . . . . . 31
4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 31 4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 32
4.3. application/news-checkgroups . . . . . . . . . . . . . . . 32 4.3. application/news-checkgroups . . . . . . . . . . . . . . . 34
5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 34 5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 37
5.1. Authentication and Authorization . . . . . . . . . . . . . 34 5.1. Authentication and Authorization . . . . . . . . . . . . . 37
5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 35 5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 38
5.2.1. The newgroup Control Message . . . . . . . . . . . . . 35 5.2.1. The newgroup Control Message . . . . . . . . . . . . . 38
5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 37 5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 40
5.2.3. The checkgroups Control Message . . . . . . . . . . . 37 5.2.3. The checkgroups Control Message . . . . . . . . . . . 40
5.3. The cancel Control Message . . . . . . . . . . . . . . . . 39 5.3. The cancel Control Message . . . . . . . . . . . . . . . . 42
5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 39 5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 42
5.5. The ihave and sendme Control Messages . . . . . . . . . . 40 5.5. The ihave and sendme Control Messages . . . . . . . . . . 43
5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 41 5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 44
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 45
6.1. Compromise of System Integrity . . . . . . . . . . . . . . 42 6.1. Compromise of System Integrity . . . . . . . . . . . . . . 45
6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 43 6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 46
6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 47
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Normative References . . . . . . . . . . . . . . . . . . . 46 8.1. Normative References . . . . . . . . . . . . . . . . . . . 49
8.2. Informative References . . . . . . . . . . . . . . . . . . 46 8.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Changes to the Existing Protocols . . . . . . . . . . 48 Appendix A. Changes to the Existing Protocols . . . . . . . . . . 51
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 49 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . . . . 54
1. Introduction 1. Introduction
1.1. Basic Concepts 1.1. Basic Concepts
"Netnews" is a set of protocols for generating, storing and "Netnews" is a set of protocols for generating, storing and
retrieving news "articles" whose format is defined in [USEFOR], and retrieving news "articles" whose format is defined in [USEFOR], and
for exchanging them amongst a readership that is potentially widely for exchanging them amongst a readership that is potentially widely
distributed. It is organized around "newsgroups", with the distributed. It is organized around "newsgroups", with the
expectation that each reader will be able to see all articles posted expectation that each reader will be able to see all articles posted
skipping to change at page 5, line 48 skipping to change at page 5, line 48
1.3. Requirements Notation 1.3. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.4. Syntax Notation 1.4. Syntax Notation
Syntax defined in this document uses the Augmented Backus-Naur Form Syntax defined in this document uses the Augmented Backus-Naur Form
(ABNF) notation (including the Core Rules) defined in [RFC4234] and (ABNF) notation (including the Core Rules) defined in [RFC5234] and
constructs defined in [USEFOR] and [RFC2822]. constructs defined in [USEFOR] and [RFC2822].
The ABNF rules defined elsewhere and used in this document are:
CRLF = <see [RFC5234] appendix B.1>
DIGIT = <see [RFC5234] appendix B.1>
HTAB = <see [RFC5234] appendix B.1>
SP = <see [RFC5234] appendix B.1>
WSP = <see [RFC5234] appendix B.1>
argument = <see [USEFOR] section 3.2.3>
article-locator = <see [USEFOR] section 3.2.14>
component = <see [USEFOR] section 3.1.4>
control-command = <see [USEFOR] section 3.2.3>
diag-keyword = <see [USEFOR] section 3.1.5>
diag-match = <see [USEFOR] section 3.1.5>
diag-other = <see [USEFOR] section 3.1.5>
dist-name = <see [USEFOR] section 3.2.4>
msg-id = <see [USEFOR] section 3.1.3>
newsgroup-name = <see [USEFOR] section 3.1.4>
path-diagnostic = <see [USEFOR] section 3.1.5>
path-identity = <see [USEFOR] section 3.1.5>
path-nodot = <see [USEFOR] section 3.1.5>
tail-entry = <see [USEFOR] section 3.1.5>
verb = <see [USEFOR] section 3.2.3>
display-name = <see [RFC2822] section 3.4>
local-part = <see [RFC2822] section 3.4.1>
mailbox = <see [RFC2822] section 3.4>
utext = <see [RFC2822] section 3.2.6>
1.5. Definitions 1.5. Definitions
Any term used in this document that is defined in Section 1.5 of Any term used in this document that is defined in Section 1.5 of
[USEFOR] is used with the definition given there. In addition, the [USEFOR] is used with the definition given there. In addition, the
following terms will be used: following terms will be used:
A "hierarchy" is the set of all newsgroups whose names share a first A "hierarchy" is the set of all newsgroups whose names share a first
<component> (as defined in Section 3.1.4 of [USEFOR]). A "sub- <component> (as defined in Section 3.1.4 of [USEFOR]). A "sub-
hierarchy" is the set of all newsgroups whose names share several hierarchy" is the set of all newsgroups whose names share several
initial components. initial components.
skipping to change at page 11, line 50 skipping to change at page 12, line 50
The article was relayed to the relaying agent known, at least to The article was relayed to the relaying agent known, at least to
old.site.example, as "barbaz". old.site.example, as "barbaz".
barbaz relayed it to old.site.example, which does not support <diag- barbaz relayed it to old.site.example, which does not support <diag-
keyword> and therefore used the old "!" delimiter. This indicates keyword> and therefore used the old "!" delimiter. This indicates
that the identity of "barbaz" was not verified and may have been that the identity of "barbaz" was not verified and may have been
forged. forged.
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- simply that that identity did not match the expectations of foo-
news.) 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
skipping to change at page 30, line 14 skipping to change at page 31, line 14
4. Media Types 4. Media Types
This document defines several media types, which shall be registered This document defines several media types, which shall be registered
with IANA as provided for in [RFC4288]. with IANA as provided for in [RFC4288].
The media type message/news, as previously registered with IANA, is The media type message/news, as previously registered with IANA, is
hereby declared obsolete. It was never widely implemented, and its hereby declared obsolete. It was never widely implemented, and its
default treatment as application/octet-stream by agents that did not default treatment as application/octet-stream by agents that did not
recognize it was counter-productive. The media type message/rfc822 recognize it was counter-productive. The media type message/rfc822
SHOULD be used in its place. (defined in [RFC2046], section 5.2.1) SHOULD be used in its place.
The updated MIME media type definition of message/news is:
MIME type name: message
MIME subtype name: news
Required parameters: none
Optional parameters: charset, compare message/rfc822
Encoding considerations: compare message/rfc822 (RFC 2046)
Security considerations: OBSOLETE, use message/rfc822.
Interoperability considerations:
Rarely used; and therefore often
handled as application/octet-stream.
Disposition should by default be inline.
Published specification: [SON-OF-1036], RFCXXXX
Applications that use this media type:
Some old mail and news user agents.
Intended usage: OBSOLETE
Author: Henry Spencer
Change controller: IETF
4.1. application/news-transmission 4.1. application/news-transmission
The media type application/news-transmission is intended for the The media type application/news-transmission is intended for the
encapsulation of complete news articles where the intention is that encapsulation of complete news articles where the intention is that
the recipient should then inject them into Netnews. This application the recipient should then inject them into Netnews. This application
type provides one of the methods for mailing articles to moderators type provides one of the methods for mailing articles to moderators
(see Section 3.5.1) and may be used to convey messages to an (see Section 3.5.1) and may be used to convey messages to an
injecting agent. This encapsulation removes the need to transform an injecting agent. This encapsulation removes the need to transform an
email message into a Netnews proto-article and provides a way to send email message into a Netnews proto-article and provides a way to send
skipping to change at page 30, line 43 skipping to change at page 32, line 20
Optional parameters: One and only one of "usage=moderate", Optional parameters: One and only one of "usage=moderate",
"usage=inject", or "usage=relay". "usage=inject", or "usage=relay".
Encoding considerations: A transfer-encoding different from that Encoding considerations: A transfer-encoding different from that
of the article transmitted MAY be of the article transmitted MAY be
supplied to ensure correct transmission supplied to ensure correct transmission
over some 7bit transport medium. over some 7bit transport medium.
Security considerations: A news article may be a control message, Security considerations: A news article may be a control message,
which if processed could have effects on which if processed could have effects on
the recipient host's system beyond just the recipient host's system beyond just
storage of the article. storage of the article.
Published specification: This specification. Published specification: RFCXXXX
Body part: A complete proto-article ready for Body part: A complete proto-article ready for
injection into Netnews or an article injection into Netnews or an article
being relayed to another agent. being relayed to another agent.
Applications that use this media type:
Injecting agents, Netnews moderators.
Intended usage: COMMON
Change controller: IETF
usage=moderate indicates the article is intended for a moderator, usage=moderate indicates the article is intended for a moderator,
usage=inject for an injecting agent, and usage=relay for a relaying usage=inject for an injecting agent, and usage=relay for a relaying
agent. The entity receiving the article may only implement one type agent. The entity receiving the article may only implement one type
of agent, in which case the parameter MAY be omitted. of agent, in which case the parameter MAY be omitted.
Contrary to the prior registration of this media type, article Contrary to the prior registration of this media type, article
batches are not permitted as a body part. Multiple messages or a batches are not permitted as a body part. Multiple messages or a
message with multiple application/news-transmission parts may be used message with multiple application/news-transmission parts may be used
instead. instead.
skipping to change at page 31, line 29 skipping to change at page 33, line 17
MIME type name: application MIME type name: application
MIME subtype name: news-groupinfo MIME subtype name: news-groupinfo
Required parameters: none Required parameters: none
Optional parameters: charset, which MUST be a charset Optional parameters: charset, which MUST be a charset
registered for use with MIME text types registered for use with MIME text types
and has the same syntax as the parameter and has the same syntax as the parameter
defined for text/plain [RFC2046]. defined for text/plain [RFC2046].
Specifies the charset of the body part. Specifies the charset of the body part.
If not given, the charset defaults to If not given, the charset defaults to
US-ASCII [ASCII]. US-ASCII [ASCII].
Disposition: by default, inline
Encoding considerations: 7bit or 8bit MUST be used to maintain Encoding considerations: 7bit or 8bit MUST be used to maintain
compatibility. compatibility.
Security considerations: None. Security considerations: None.
Published specification: This specification. Interoperability considerations:
Disposition should by default be inline.
Applications that use this media type:
Control message issuers, relaying
agents, serving agents.
Published specification: RFCXXXX
Intended usage: COMMON
Change controller: IETF
The content of the application/news-groupinfo body part is defined The content of the application/news-groupinfo body part is defined
as: as:
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 ]
[ *WSP moderation-flag ] [ *WSP moderation-flag ]
newsgroup-description newsgroup-description
= eightbit-utext *( *WSP eightbit-utext ) = eightbit-utext *( *WSP eightbit-utext )
moderation-flag = SP "(" %4D.6F.64.65.72.61.74.65.64 ")" moderation-flag = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")"
; SPACE + 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
skipping to change at page 33, line 17 skipping to change at page 35, line 17
MIME type name: application MIME type name: application
MIME subtype name: news-checkgroups MIME subtype name: news-checkgroups
Required parameters: none Required parameters: none
Optional parameters: charset, which MUST be a charset Optional parameters: charset, which MUST be a charset
registered for use with MIME text types registered for use with MIME text types
and has the same syntax as the parameter and has the same syntax as the parameter
defined for text/plain [RFC2046]. defined for text/plain [RFC2046].
Specifies the charset of the body part. Specifies the charset of the body part.
If not given, the charset defaults to If not given, the charset defaults to
US-ASCII [ASCII]. US-ASCII [ASCII].
Disposition: by default, inline
Encoding considerations: 7bit or 8bit MUST be used to maintain Encoding considerations: 7bit or 8bit MUST be used to maintain
compatibility. compatibility.
Security considerations: This media type provides only a means Security considerations: This media type provides only a means
for conveying a list of newsgroups and for conveying a list of newsgroups and
does not provide any information does not provide any information
indicating whether the sender is indicating whether the sender is
authorized to state which newsgroups authorized to state which newsgroups
should exist within a hierarchy. Such should exist within a hierarchy. Such
authorization must be accomplished by authorization must be accomplished by
other means. other means.
Published specification: This specification. Interoperability considerations:
Disposition should by default be inline.
Applications that use this media type:
Control message issuers, relaying
agents, serving agents.
Published specification: RFCXXXX
Intended usage: COMMON
Change controller: IETF
The content of the application/news-groupinfo body part is defined The content of the application/news-groupinfo body part is defined
as: as:
checkgroups-body = *( valid-group CRLF ) checkgroups-body = *( valid-group CRLF )
valid-group = newsgroups-line ; see 4.2 valid-group = newsgroups-line ; see 4.2
The same restrictions on charset, <newsgroup-name>, and <newsgroup- The same restrictions on charset, <newsgroup-name>, and <newsgroup-
description> apply for this media type as for application/ description> apply for this media type as for application/
news-groupinfo. news-groupinfo.
skipping to change at page 44, line 29 skipping to change at page 47, line 29
enforced by the protocol. enforced by the protocol.
The flooding algorithm used by Netnews transports such as NNTP The flooding algorithm used by Netnews transports such as NNTP
[RFC3977] is extremely good at finding any path by which articles can [RFC3977] is extremely good at finding any path by which articles can
leave a subnet with supposedly restrictive boundaries, and leave a subnet with supposedly restrictive boundaries, and
substantial administrative effort is required to avoid this. substantial administrative effort is required to avoid this.
Organizations wishing to control such leakage are advised to Organizations wishing to control such leakage are advised to
designate a small number of gateways to handle all news exchange with designate a small number of gateways to handle all news exchange with
the outside world. the outside world.
The sendme control message Section 5.5, insofar as it is still used, The sendme control message (Section 5.5), insofar as it is still
can be used to request articles the requester should not have access used, can be used to request articles the requester should not have
to. access to.
7. IANA Considerations 7. IANA Considerations
IANA is requested to register the following media types, described IANA is requested to register the following media types, described
elsewhere in this document, for use with the Content-Type header elsewhere in this document, for use with the Content-Type header
field, in the IETF tree in accordance with the procedures set out in field, in the IETF tree in accordance with the procedures set out in
[RFC4288]. [RFC4288].
application/news-transmission (4.1) application/news-transmission (4.1)
application/news-groupinfo (4.2) application/news-groupinfo (4.2)
application/news-checkgroups (4.3) application/news-checkgroups (4.3)
application/news-transmission is a change to a previous registration. application/news-transmission is a change to a previous registration.
IANA is also requested to change the status of the message/news media IANA is also requested to change the status of the message/news media
type to "OBSOLETE". message/rfc822 should be used instead. type to "OBSOLETE". message/rfc822 should be used instead. An
updated template is included in Section 4.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ASCII] American National Standard for Information Systems, "Coded [ASCII] American National Standard for Information Systems, "Coded
Character Sets - 7-Bit American National Standard Code for Character Sets - 7-Bit American National Standard Code for
Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986. Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
skipping to change at page 46, line 26 skipping to change at page 49, line 26
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[USEFOR] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews [USEFOR] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
Article Format". Article Format", draft-ietf-usefor-usefor-12 (work in
progress),
<http://tools.ietf.org/html/draft-ietf-usefor-usefor-12>.
8.2. Informative References 8.2. Informative References
[RFC0976] Horton, M., "UUCP mail interchange format standard", [RFC0976] Horton, M., "UUCP mail interchange format standard",
RFC 976, February 1986. RFC 976, February 1986.
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987. USENET messages", RFC 1036, December 1987.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
skipping to change at page 47, line 8 skipping to change at page 50, line 9
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004. Notification", RFC 3798, May 2004.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006. RFC 3977, October 2006.
[USEAGE] Lindsey, C., "Usenet Best Practice". [SON-OF-1036]
Spencer, H., "News Article Format and Transmission",
June 1994.
[USEAGE] Lindsey, C., "Usenet Best Practice",
draft-ietf-usefor-useage-01 (work in progress),
March 2005,
<http://tools.ietf.org/html/draft-ietf-usefor-useage-01>.
Appendix A. Changes to the Existing Protocols Appendix A. Changes to the Existing Protocols
This document prescribes many changes, clarifications, and new This document prescribes many changes, clarifications, and new
features since the protocol described in [RFC1036]. Most notably: features since the protocol described in [RFC1036]. Most notably:
o A new, backward-compatible Path header field format that permits o A new, backward-compatible Path header field format that permits
standardized embedding of additional trace and authentication standardized embedding of additional trace and authentication
information is now RECOMMENDED. See Section 3.5 and Section 3.6. information is now RECOMMENDED. See Section 3.2. Folding of the
Folding of the Path header is permitted. Path header is permitted.
o Trimming of the References header field is REQUIRED and a o Trimming of the References header field is REQUIRED and a
mechanism for doing so is defined. mechanism for doing so is defined.
o Addition of the new Injection-Date header field is required for o Addition of the new Injection-Date header field is required in
some circumstances for posting agents (Section 3.4.2) and
injecting agents (Section 3.5) and MUST be used by news servers injecting agents (Section 3.5) and MUST be used by news servers
for date checks (Section 3.6). Injecting agents are strongly for date checks (Section 3.6). Injecting agents are also strongly
encouraged to put all local trace information in the new encouraged to put all local trace information in the new
Injection-Info header field. Injection-Info header field.
o A new media type is defined for transmitting Netnews articles o A new media type is defined for transmitting Netnews articles
through other media (Section 4.1), and moderators SHOULD prepare through other media (Section 4.1), and moderators SHOULD prepare
to receive submissions in that format (Section 3.5.1). to receive submissions in that format (Section 3.5.1).
o Certain control messages (Section 5.6) are declared obsolete, and o Certain control messages (Section 5.6) are declared obsolete, and
the special significance of "cmsg" at the start of a Subject the special significance of "cmsg" at the start of a Subject
header field is removed. header field is removed.
skipping to change at page 49, line 13 skipping to change at page 52, line 13
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
members of the USEFOR Working Group of the Internet Engineering Task members of the USEFOR Working Group of the Internet Engineering Task
Force (IETF) and the accompanying mailing list. Force (IETF) and the accompanying mailing list.
Special thanks are due to Henry Spencer, whose Son-of-1036 draft Special thanks are due to Henry Spencer, whose [SON-OF-1036] draft
served as the initial basis for this document. served as the initial basis for this document.
Authors' Addresses Authors' Addresses
Russ Allbery (editor) Russ Allbery (editor)
Stanford University Stanford University
P.O. Box 20066 P.O. Box 20066
Stanford, CA 94309 Stanford, CA 94309
US US
 End of changes. 26 change blocks. 
75 lines changed or deleted 151 lines changed or added

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