draft-ietf-usefor-usepro-13.txt   draft-ietf-usefor-usepro-14.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 December 14, 2008 Intended status: Standards Track March 3, 2009
Expires: June 17, 2009 Expires: September 4, 2009
Netnews Architecture and Protocols Netnews Architecture and Protocols
draft-ietf-usefor-usepro-13 draft-ietf-usefor-usepro-14
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 17, 2009. This Internet-Draft will expire on September 4, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 4, line 4 skipping to change at page 4, line 4
4.1. application/news-transmission . . . . . . . . . . . . . . 32 4.1. application/news-transmission . . . . . . . . . . . . . . 32
4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 33 4.2. application/news-groupinfo . . . . . . . . . . . . . . . . 33
4.3. application/news-checkgroups . . . . . . . . . . . . . . . 35 4.3. application/news-checkgroups . . . . . . . . . . . . . . . 35
5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 38 5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Authentication and Authorization . . . . . . . . . . . . . 38 5.1. Authentication and Authorization . . . . . . . . . . . . . 38
5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 39 5.2. Group Control Messages . . . . . . . . . . . . . . . . . . 39
5.2.1. The newgroup Control Message . . . . . . . . . . . . . 39 5.2.1. The newgroup Control Message . . . . . . . . . . . . . 39
5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 41 5.2.2. The rmgroup Control Message . . . . . . . . . . . . . 41
5.2.3. The checkgroups Control Message . . . . . . . . . . . 41 5.2.3. The checkgroups Control Message . . . . . . . . . . . 41
5.3. The cancel Control Message . . . . . . . . . . . . . . . . 43 5.3. The cancel Control Message . . . . . . . . . . . . . . . . 43
5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 43 5.4. The Supersedes Header Field . . . . . . . . . . . . . . . 44
5.5. The ihave and sendme Control Messages . . . . . . . . . . 44 5.5. The ihave and sendme Control Messages . . . . . . . . . . 44
5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 45 5.6. Obsolete Control Messages . . . . . . . . . . . . . . . . 45
6. Security Considerations . . . . . . . . . . . . . . . . . . . 46 6. Security Considerations . . . . . . . . . . . . . . . . . . . 46
6.1. Compromise of System Integrity . . . . . . . . . . . . . . 46 6.1. Compromise of System Integrity . . . . . . . . . . . . . . 46
6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 47 6.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 47
6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.3. Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 48
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Normative References . . . . . . . . . . . . . . . . . . . 50 8.1. Normative References . . . . . . . . . . . . . . . . . . . 50
8.2. Informative References . . . . . . . . . . . . . . . . . . 50 8.2. Informative References . . . . . . . . . . . . . . . . . . 50
Appendix A. Changes to the Existing Protocols . . . . . . . . . . 52 Appendix A. Changes to the Existing Protocols . . . . . . . . . . 52
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 53 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 55
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 41, line 23 skipping to change at page 41, line 23
Subject: cmsg newgroup example.admin.info moderated Subject: cmsg newgroup example.admin.info moderated
Approved: admin@noc.example Approved: admin@noc.example
Control: newgroup example.admin.info moderated Control: newgroup example.admin.info moderated
Message-ID: <ng-example.admin.info-20020227@noc.example> Message-ID: <ng-example.admin.info-20020227@noc.example>
MIME-Version: 1.0 MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nxtprt" Content-Type: multipart/mixed; boundary="nxtprt"
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
This is a MIME control message. This is a MIME control message.
--nxtprt --nxtprt
Content-Type: application/news-groupinfo Content-Type: application/news-groupinfo; charset=us-ascii
For your newsgroups file: For your newsgroups file:
example.admin.info About the example.* groups (Moderated) example.admin.info About the example.* groups (Moderated)
--nxtprt --nxtprt
Content-Type: text/plain Content-Type: text/plain; charset=us-ascii
A moderated newsgroup for announcements about new newsgroups in A moderated newsgroup for announcements about new newsgroups in
the example.* hierarchy. the example.* hierarchy.
--nxtprt-- --nxtprt--
5.2.2. The rmgroup Control Message 5.2.2. The rmgroup Control Message
The rmgroup control message requests the specified group be removed The rmgroup control message requests the specified group be removed
from a news server's list of valid groups. The syntax of its Control from a news server's list of valid groups. The syntax of its Control
skipping to change at page 42, line 30 skipping to change at page 42, line 30
argument is given, it applies to all hierarchies for which group argument is given, it applies to all hierarchies for which group
statements appear in the body of the message. Since much existing statements appear in the body of the message. Since much existing
software does not honor the <chkscope> argument, the body of the software does not honor the <chkscope> argument, the body of the
checkgroups control message MUST NOT contain group statements for checkgroups control message MUST NOT contain group statements for
newsgroups outside the intended scope and SHOULD contain a correct newsgroups outside the intended scope and SHOULD contain a correct
newsgroup list even for sub-hierarchies excluded with "!" <chkscope> newsgroup list even for sub-hierarchies excluded with "!" <chkscope>
terms. News servers, however, MUST honor <chkscope> as specified terms. News servers, however, MUST honor <chkscope> as specified
here. here.
The <chksernr> argument may be any positive integer. If present, it The <chksernr> argument may be any positive integer. If present, it
MUST increase with every change to the newsgroup list and MUST NOT MUST increase with every change to the newsgroup list, MUST NOT ever
ever decrease. If provided, news servers SHOULD remember the decrease, and MUST be included in all subsequent checkgroups control
<chksernr> value of the previous checkgroups control message honored messages with the same scope. If provided, news servers SHOULD
for a particular hierarchy or sub-hierarchy and decline to honor any remember the <chksernr> value of the previous checkgroups control
subsequent checkgroups control message for the same hierarchy or sub- message honored for a particular hierarchy or sub-hierarchy and
hierarchy with a smaller <chksernr> value. decline to honor any subsequent checkgroups control message for the
same hierarchy or sub-hierarchy with a smaller <chksernr> value or
with no <chksernr> value.
There is no upper limit on the length of <chksernr> other than the
limitation on the length of header fields. Implementations may
therefore want to do comparisons by zero-padding the shorter of two
<chksernr> values on the left and then doing a string comparison
rather than assuming <chksernr> can be manipulated as a number.
For example, the following Control header field For example, the following Control header field
Control: checkgroups de !de.alt #248 Control: checkgroups de !de.alt #2009021301
indicates the body of the message will list every newsgroup in the indicates the body of the message will list every newsgroup in the
de.* hierarchy, excepting the de.alt.* sub-hierarchy, and should not de.* hierarchy, excepting the de.alt.* sub-hierarchy, and should not
be honored if a checkgroups control message with a serial number be honored if a checkgroups control message with a serial number
greater than 248 was previously honored. greater than 2009021301 was previously honored. The serial number in
this example was formed from the date in YYYYMMDD format followed by
a two-digit sequence number within that date.
The body of the message is an entity of type application/ The body of the message is an entity of type application/
news-checkgroups. It SHOULD be declared as such with appropriate news-checkgroups. It SHOULD be declared as such with appropriate
MIME headers, but news servers SHOULD interpret checkgroups messages MIME headers, but news servers SHOULD interpret checkgroups messages
that lack the appropriate MIME headers as if the body were of type that lack the appropriate MIME headers as if the body were of type
application/news-checkgroups for backward compatibility. application/news-checkgroups for backward compatibility.
5.3. The cancel Control Message 5.3. The cancel Control Message
The cancel control message requests that a target article be The cancel control message requests that a target article be
skipping to change at page 55, line 4 skipping to change at line 2195
Charles H. Lindsey Charles H. Lindsey
5 Clerewood Avenue 5 Clerewood Avenue
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
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 12 change blocks. 
20 lines changed or deleted 38 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/