draft-ietf-nntpext-base-24.txt   draft-ietf-nntpext-base-25.txt 
NNTP C. Feather NNTP C. Feather
Internet-Draft Thus plc Internet-Draft Thus plc
Expires: March 4, 2005 September 3, 2004 Expires: August 14, 2005 February 10, 2005
Network News Transfer Protocol Network News Transfer Protocol
draft-ietf-nntpext-base-24 draft-ietf-nntpext-base-25
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
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 March 4, 2005. This Internet-Draft will expire on August 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
The Network News Transfer Protocol (NNTP) has been in use in the The Network News Transfer Protocol (NNTP) has been in use in the
Internet for a decade and remains one of the most popular protocols Internet for a decade and remains one of the most popular protocols
(by volume) in use today. This document is a replacement for RFC 977 (by volume) in use today. This document is a replacement for RFC 977
and officially updates the protocol specification. It clarifies some and officially updates the protocol specification. It clarifies some
vagueness in RFC 977, includes some new base functionality, and vagueness in RFC 977, includes some new base functionality, and
provides a specific mechanism to add standardized extensions to NNTP. provides a specific mechanism to add standardized extensions to NNTP.
skipping to change at page 2, line 4 skipping to change at page 2, line 6
Abstract Abstract
The Network News Transfer Protocol (NNTP) has been in use in the The Network News Transfer Protocol (NNTP) has been in use in the
Internet for a decade and remains one of the most popular protocols Internet for a decade and remains one of the most popular protocols
(by volume) in use today. This document is a replacement for RFC 977 (by volume) in use today. This document is a replacement for RFC 977
and officially updates the protocol specification. It clarifies some and officially updates the protocol specification. It clarifies some
vagueness in RFC 977, includes some new base functionality, and vagueness in RFC 977, includes some new base functionality, and
provides a specific mechanism to add standardized extensions to NNTP. provides a specific mechanism to add standardized extensions to NNTP.
Administration Administration
This document is a product of the NNTP Working Group, chaired by Russ This document is a product of the NNTP Working Group, chaired by Russ
Allbery and Ned Freed. Allbery and Ned Freed.
This is draft 25.
Author's Note Author's Note
This document is written in XML using an NNTP-specific DTD. Custom This document is written in XML using an NNTP-specific DTD. Custom
software is used to convert this to RFC 2629 [RFC2629] format, and software is used to convert this to RFC 2629 [RFC2629] format, and
then the public "xml2rfc" package to further reduce this to text, then the public "xml2rfc" package to further reduce this to text,
nroff source, and HTML. nroff source, and HTML.
No perl was used in producing this document. No perl was used in producing this document.
Rights Rights
UNIX is a registered trademark of The Open Group. UNIX is a registered trademark of The Open Group.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 8 3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Commands and Responses . . . . . . . . . . . . . . . . . 8 3.1 Commands and Responses . . . . . . . . . . . . . . . . . 9
3.2 Response Codes . . . . . . . . . . . . . . . . . . . . . 10 3.2 Response Codes . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Generic Response Codes . . . . . . . . . . . . . . . 11 3.2.1 Generic Response Codes . . . . . . . . . . . . . . . 12
3.2.1.1 Examples . . . . . . . . . . . . . . . . . . . . 13 3.2.1.1 Examples . . . . . . . . . . . . . . . . . . . . 14
3.3 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 Capabilities and Extensions . . . . . . . . . . . . . . 15
3.3.1 Examples . . . . . . . . . . . . . . . . . . . . . . 15 3.3.1 Capability descriptions . . . . . . . . . . . . . . 16
3.4 Articles . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.2 Standard capabilities . . . . . . . . . . . . . . . 16
4. The WILDMAT format . . . . . . . . . . . . . . . . . . . . . 18 3.3.3 Extensions . . . . . . . . . . . . . . . . . . . . . 18
4.1 Wildmat syntax . . . . . . . . . . . . . . . . . . . . . 18 3.3.4 Initial IANA register . . . . . . . . . . . . . . . 19
4.2 Wildmat semantics . . . . . . . . . . . . . . . . . . . 18 3.4 Mandatory and Optional Commands . . . . . . . . . . . . 20
4.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . 19 3.4.1 Reading and Transit Servers . . . . . . . . . . . . 21
4.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.2 Mode switching . . . . . . . . . . . . . . . . . . . 22
5. Session administration commands . . . . . . . . . . . . . . 21 3.5 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 23
5.1 Initial Connection . . . . . . . . . . . . . . . . . . . 21 3.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . 24
5.2 MODE READER . . . . . . . . . . . . . . . . . . . . . . 22 3.6 Articles . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 LIST EXTENSIONS . . . . . . . . . . . . . . . . . . . . 24 4. The WILDMAT format . . . . . . . . . . . . . . . . . . . . . 26
5.4 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.1 Wildmat syntax . . . . . . . . . . . . . . . . . . . . . 26
6. Article posting and retrieval . . . . . . . . . . . . . . . 28 4.2 Wildmat semantics . . . . . . . . . . . . . . . . . . . 26
6.1 Group and article selection . . . . . . . . . . . . . . 28 4.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.1 GROUP . . . . . . . . . . . . . . . . . . . . . . . 28 4.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.2 LAST . . . . . . . . . . . . . . . . . . . . . . . . 31 5. Session administration commands . . . . . . . . . . . . . . 28
6.1.3 NEXT . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1 Initial Connection . . . . . . . . . . . . . . . . . . . 28
6.2 Retrieval of articles and article sections . . . . . . . 33 5.2 CAPABILITIES . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1 ARTICLE . . . . . . . . . . . . . . . . . . . . . . 34 5.3 MODE READER . . . . . . . . . . . . . . . . . . . . . . 31
6.2.2 HEAD . . . . . . . . . . . . . . . . . . . . . . . . 37 5.4 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.3 BODY . . . . . . . . . . . . . . . . . . . . . . . . 38 6. Article posting and retrieval . . . . . . . . . . . . . . . 35
6.2.4 STAT . . . . . . . . . . . . . . . . . . . . . . . . 40 6.1 Group and article selection . . . . . . . . . . . . . . 35
6.3 Article posting . . . . . . . . . . . . . . . . . . . . 42 6.1.1 GROUP . . . . . . . . . . . . . . . . . . . . . . . 35
6.3.1 POST . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.2 LISTGROUP . . . . . . . . . . . . . . . . . . . . . 38
6.3.2 IHAVE . . . . . . . . . . . . . . . . . . . . . . . 44 6.1.3 LAST . . . . . . . . . . . . . . . . . . . . . . . . 39
7. Information commands . . . . . . . . . . . . . . . . . . . . 48 6.1.4 NEXT . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1 DATE . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2 Retrieval of articles and article sections . . . . . . . 42
7.2 HELP . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2.1 ARTICLE . . . . . . . . . . . . . . . . . . . . . . 42
7.3 NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . 49 6.2.2 HEAD . . . . . . . . . . . . . . . . . . . . . . . . 45
7.4 NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2.3 BODY . . . . . . . . . . . . . . . . . . . . . . . . 47
7.5 Time . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2.4 STAT . . . . . . . . . . . . . . . . . . . . . . . . 48
7.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . 52 6.3 Article posting . . . . . . . . . . . . . . . . . . . . 51
7.6 The LIST commands . . . . . . . . . . . . . . . . . . . 52 6.3.1 POST . . . . . . . . . . . . . . . . . . . . . . . . 51
7.6.1 LIST ACTIVE . . . . . . . . . . . . . . . . . . . . 52 6.3.2 IHAVE . . . . . . . . . . . . . . . . . . . . . . . 53
7.6.2 LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . 54 7. Information commands . . . . . . . . . . . . . . . . . . . . 56
7.6.3 LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . 56 7.1 DATE . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.6.4 LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . 56 7.2 HELP . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.6.5 LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . 58 7.3 NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . 57
8. Framework for NNTP extensions . . . . . . . . . . . . . . . 60 7.4 NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . 58
8.1 Initial IANA registry . . . . . . . . . . . . . . . . . 62 7.5 Time . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.2 Standard extensions . . . . . . . . . . . . . . . . . . 62 7.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . 60
8.3 The LISTGROUP extension . . . . . . . . . . . . . . . . 62 7.6 The LIST commands . . . . . . . . . . . . . . . . . . . 60
8.3.1 LISTGROUP . . . . . . . . . . . . . . . . . . . . . 62 7.6.1 LIST . . . . . . . . . . . . . . . . . . . . . . . . 61
8.4 Article metadata . . . . . . . . . . . . . . . . . . . . 64 7.6.2 Standard LIST keywords . . . . . . . . . . . . . . . 63
8.4.1 The :bytes metadata item . . . . . . . . . . . . . . 65 7.6.3 LIST ACTIVE . . . . . . . . . . . . . . . . . . . . 63
8.4.2 The :lines metadata item . . . . . . . . . . . . . . 65 7.6.4 LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . 65
8.5 The OVER extension . . . . . . . . . . . . . . . . . . . 65 7.6.5 LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . 66
8.5.1 OVER . . . . . . . . . . . . . . . . . . . . . . . . 66 7.6.6 LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . 66
8.5.2 LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . 70 8. Article field access commands . . . . . . . . . . . . . . . 68
8.6 The HDR extension . . . . . . . . . . . . . . . . . . . 72 8.1 Article metadata . . . . . . . . . . . . . . . . . . . . 68
8.6.1 HDR . . . . . . . . . . . . . . . . . . . . . . . . 72 8.1.1 The :bytes metadata item . . . . . . . . . . . . . . 68
8.6.2 LIST HEADERS . . . . . . . . . . . . . . . . . . . . 76 8.1.2 The :lines metadata item . . . . . . . . . . . . . . 69
9. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . . . 79 8.2 Database consistency . . . . . . . . . . . . . . . . . . 69
9.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . 79 8.3 OVER . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.2 Command continuation . . . . . . . . . . . . . . . . . . 81 8.4 LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . 74
9.3 Responses . . . . . . . . . . . . . . . . . . . . . . . 81 8.5 HDR . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.3.1 Generic responses . . . . . . . . . . . . . . . . . 81 8.6 LIST HEADERS . . . . . . . . . . . . . . . . . . . . . . 79
9.3.2 Initial response line contents . . . . . . . . . . . 82 9. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . . . 83
9.3.3 Multi-line response contents . . . . . . . . . . . . 82 9.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . 83
9.4 LIST EXTENSIONS responses . . . . . . . . . . . . . . . 84 9.2 Command continuation . . . . . . . . . . . . . . . . . . 85
9.5 Articles . . . . . . . . . . . . . . . . . . . . . . . . 84 9.3 Responses . . . . . . . . . . . . . . . . . . . . . . . 85
9.6 General non-terminals . . . . . . . . . . . . . . . . . 84 9.3.1 Generic responses . . . . . . . . . . . . . . . . . 85
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 87 9.3.2 Initial response line contents . . . . . . . . . . . 86
11. Security Considerations . . . . . . . . . . . . . . . . . 88 9.3.3 Multi-line response contents . . . . . . . . . . . . 87
11.1 Personal and Proprietary Information . . . . . . . . . . 88 9.4 Capability lines . . . . . . . . . . . . . . . . . . . . 88
11.2 Abuse of Server Log Information . . . . . . . . . . . . 88 9.5 LIST variants . . . . . . . . . . . . . . . . . . . . . 88
11.3 Weak Authentication and Access Control . . . . . . . . . 88 9.6 Articles . . . . . . . . . . . . . . . . . . . . . . . . 89
11.4 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 89 9.7 General non-terminals . . . . . . . . . . . . . . . . . 90
11.5 UTF-8 issues . . . . . . . . . . . . . . . . . . . . . . 89 9.8 Extensions and Validation . . . . . . . . . . . . . . . 91
11.6 Caching of LIST EXTENSIONS results . . . . . . . . . . . 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 93
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 92 11. Security Considerations . . . . . . . . . . . . . . . . . 94
13. References . . . . . . . . . . . . . . . . . . . . . . . . 94 11.1 Personal and Proprietary Information . . . . . . . . . . 94
13.1 Normative References . . . . . . . . . . . . . . . . . . . 94 11.2 Abuse of Server Log Information . . . . . . . . . . . . 94
13.2 Informative References . . . . . . . . . . . . . . . . . . 94 11.3 Weak Authentication and Access Control . . . . . . . . . 94
Author's Address . . . . . . . . . . . . . . . . . . . . . . 95 11.4 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 95
A. Future Directions . . . . . . . . . . . . . . . . . . . . . 96 11.5 UTF-8 issues . . . . . . . . . . . . . . . . . . . . . . 95
B. Interaction with other specifications . . . . . . . . . . . 97 11.6 Caching of capability lists . . . . . . . . . . . . . . 96
B.1 Header folding . . . . . . . . . . . . . . . . . . . . . 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 98
B.2 Message-IDs . . . . . . . . . . . . . . . . . . . . . . 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . 100
B.3 Article posting . . . . . . . . . . . . . . . . . . . . 98 13.1 Normative References . . . . . . . . . . . . . . . . . . 100
C. Summary of Response Codes . . . . . . . . . . . . . . . . . 100 13.2 Informative References . . . . . . . . . . . . . . . . . 100
D. Formal specification of the standard extensions . . . . . . 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . 101
D.1 The LISTGROUP extension . . . . . . . . . . . . . . . . 104 A. Interaction with other specifications . . . . . . . . . . . 102
D.2 The OVER extension . . . . . . . . . . . . . . . . . . . 104 A.1 Header folding . . . . . . . . . . . . . . . . . . . . . 102
D.3 The HDR extension . . . . . . . . . . . . . . . . . . . 105 A.2 Message-IDs . . . . . . . . . . . . . . . . . . . . . . 102
Intellectual Property and Copyright Statements . . . . . . . 106 A.3 Article posting . . . . . . . . . . . . . . . . . . . . 103
B. Summary of Commands . . . . . . . . . . . . . . . . . . . . 105
C. Summary of Response Codes . . . . . . . . . . . . . . . . . 108
Intellectual Property and Copyright Statements . . . . . . . 112
1. Introduction 1. Introduction
This document specifies the Network News Transfer Protocol (NNTP), This document specifies the Network News Transfer Protocol (NNTP),
which is used for the distribution, inquiry, retrieval, and posting which is used for the distribution, inquiry, retrieval, and posting
of Netnews articles using a reliable stream-based mechanism. For of Netnews articles using a reliable stream-based mechanism. For
news reading clients, NNTP enables retrieval of news articles that news reading clients, NNTP enables retrieval of news articles that
are stored in a central database, giving subscribers the ability to are stored in a central database, giving subscribers the ability to
select only those articles they wish to read. select only those articles they wish to read.
The Netnews model provides for indexing, cross-referencing, and The Netnews model provides for indexing, cross-referencing, and
expiration of aged messages. For server-to-server interaction, NNTP expiration of aged messages. NNTP is designed for efficient
is designed for efficient transmission of Netnews articles over a transmission of Netnews articles over a reliable full duplex
reliable full duplex communication channel. communication channel.
Every attempt is made to ensure that the protocol specification in Every attempt is made to ensure that the protocol specification in
this document is compatible with the version specified in RFC 977 this document is compatible with the version specified in RFC 977
[RFC977]. However, this version does not support the ill-defined [RFC977]. However, this version does not support the ill-defined
SLAVE command and permits four digit years to be specified in the SLAVE command and permits four digit years to be specified in the
NEWNEWS and NEWGROUPS commands. It changes the default character set NEWNEWS and NEWGROUPS commands. It changes the default character set
to UTF-8 [RFC3629] instead of US-ASCII [ANSI1986] (note that US-ASCII to UTF-8 [RFC3629] instead of US-ASCII [ANSI1986] (note that US-ASCII
is a subset of UTF-8). It now requires all articles to have a is a subset of UTF-8). It now requires all articles to have a
message-id, eliminating the "<0>" placeholder used in RFC 977 in some message-id, eliminating the "<0>" placeholder used in RFC 977 in some
responses. It also extends the newsgroup name matching capabilities responses. It also extends the newsgroup name matching capabilities
skipping to change at page 6, line 19 skipping to change at page 7, line 19
UPPERCASE indicates literal text to be included in the UPPERCASE indicates literal text to be included in the
command; command;
lowercase indicates a token described elsewhere; lowercase indicates a token described elsewhere;
[brackets] indicate that the argument is optional; [brackets] indicate that the argument is optional;
ellipsis... indicates that the argument may be repeated any ellipsis... indicates that the argument may be repeated any
number of times (it must occur at least once); number of times (it must occur at least once);
vertical|bar indicates a choice of two mutually exclusive vertical|bar indicates a choice of two mutually exclusive
arguments (exactly one must be provided). arguments (exactly one must be provided).
The name "message-id" for a command or response argument indicates The name "message-id" for a command or response argument indicates
that it is the message-id of an article as described in Section 3.4, that it is the message-id of an article as described in Section 3.6,
including the angle brackets. including the angle brackets.
The name "wildmat" for an argument indicates that it is a wildmat as The name "wildmat" for an argument indicates that it is a wildmat as
defined in Section 4. If the argument does not meet the requirements defined in Section 4. If the argument does not meet the requirements
of that section (for example, if it does not fit the grammar of of that section (for example, if it does not fit the grammar of
Section 4.1) the NNTP server MAY place some interpretation on it (not Section 4.1) the NNTP server MAY place some interpretation on it (not
specified by this document) or otherwise MUST treat it as a syntax specified by this document) or otherwise MUST treat it as a syntax
error. error.
Responses for each command will be described in tables listing the Responses for each command will be described in tables listing the
skipping to change at page 6, line 43 skipping to change at page 7, line 43
The terms "NUL", "TAB", "LF", "CR, and "space" refer to the octets The terms "NUL", "TAB", "LF", "CR, and "space" refer to the octets
%x00, %x09, %x0A, %x0D, and %x20 respectively (that is, the octets %x00, %x09, %x0A, %x0D, and %x20 respectively (that is, the octets
with those codes in US-ASCII [ANSI1986] and thus UTF-8 [RFC3629]). with those codes in US-ASCII [ANSI1986] and thus UTF-8 [RFC3629]).
The term "CRLF" or "CRLF pair" means the sequence CR immediately The term "CRLF" or "CRLF pair" means the sequence CR immediately
followed by LF (that is, %x0D.0A). A "printable US-ASCII character" followed by LF (that is, %x0D.0A). A "printable US-ASCII character"
is an octet in the range %x21-7E. Quoted characters refer to the is an octet in the range %x21-7E. Quoted characters refer to the
octets with those codes in US-ASCII (so "." and "<" refer to %x2E and octets with those codes in US-ASCII (so "." and "<" refer to %x2E and
%x3C) and will always be printable US-ASCII characters; similarly, %x3C) and will always be printable US-ASCII characters; similarly,
"digit" refers to the octets %x30-39. "digit" refers to the octets %x30-39.
A "keyword" MUST consist only of US-ASCII letters, digits, and the
characters dot (".") and dash ("-"), and must begin with a letter.
Keywords MUST be at least three characters and MUST NOT exceed 12
characters.
Examples in this document are not normative but serve to illustrate Examples in this document are not normative but serve to illustrate
usages, arguments, and responses. In the examples, a "[C]" will be usages, arguments, and responses. In the examples, a "[C]" will be
used to represent the client host and a "[S]" will be used to used to represent the client host and a "[S]" will be used to
represent the server host. Most of the examples do not rely on a represent the server host. Most of the examples do not rely on a
particular server state. In some cases, however, they do assume that particular server state. In some cases, however, they do assume that
the current selected newsgroup (see the GROUP command (Section the current selected newsgroup (see the GROUP command
6.1.1)) is invalid; when so, this is indicated at the start of the (Section 6.1.1)) is invalid; when so, this is indicated at the start
example. Examples may use commands (or other names) not defined in of the example. Examples may use commands or other keywords not
this specification (such as an XENCRYPT command). These will be used defined in this specification (such as an XENCRYPT command). These
to illustrate some point and do not imply that any such command is will be used to illustrate some point and do not imply that any such
defined elsewhere or needs to exist in any particular implementation. command is defined elsewhere or needs to exist in any particular
implementation.
Terms which might be read as specifying details of a client or server Terms which might be read as specifying details of a client or server
implementation, such as "database", are used simply to ease implementation, such as "database", are used simply to ease
description. Providing that implementations conform to the protocol description. Providing that implementations conform to the protocol
and format specifications in this document, no specific technique is and format specifications in this document, no specific technique is
mandated. mandated.
3. Basic Concepts 3. Basic Concepts
3.1 Commands and Responses 3.1 Commands and Responses
NNTP operates over any reliable data stream 8-bit-wide channel. NNTP operates over any reliable data stream 8-bit-wide channel.
Initially, the server host starts the NNTP service by listening on a Initially, the server host starts the NNTP service by listening on a
TCP port; when running over TCP/IP, the official port for the NNTP TCP port. When a client host wishes to make use of the service, it
service is 119. When a client host wishes to make use of the MUST establish a TCP connection with the server host by connecting to
service, it MUST establish a TCP connection with the server host by that host on the same port on which the server is listening. When
connecting to that host on the same port on which the server is the connection is established, the NNTP server host MUST send a
listening. When the connection is established, the NNTP server host greeting. The client host and server host then exchange commands and
MUST send a greeting. The client host and server host then exchange responses (respectively) until the connection is closed or aborted.
commands and responses (respectively) until the connection is closed
or aborted.
The character set for all NNTP commands is UTF-8 [RFC3629]. Commands The character set for all NNTP commands is UTF-8 [RFC3629]. Commands
in NNTP MUST consist of a keyword, which MAY be followed by one or in NNTP MUST consist of a keyword, which MAY be followed by one or
more arguments. A CRLF pair MUST terminate all commands. Multiple more arguments. A CRLF pair MUST terminate all commands. Multiple
commands MUST NOT be on the same line. Keywords MUST consist of commands MUST NOT be on the same line. Unless otherwise noted
printable US-ASCII characters. Unless otherwise noted elsewhere in elsewhere in this document, arguments SHOULD consist of printable
this document, arguments SHOULD consist of printable US-ASCII US-ASCII characters. Keywords and arguments MUST be each separated
characters. Keywords and arguments MUST be each separated by one or by one or more space or TAB characters. Command lines MUST NOT
more space or TAB characters. Keywords MUST be at least three
characters and MUST NOT exceed 12 characters. Command lines MUST NOT
exceed 512 octets, which includes the terminating CRLF pair. The exceed 512 octets, which includes the terminating CRLF pair. The
arguments MUST NOT exceed 497 octets. A server MAY relax these arguments MUST NOT exceed 497 octets. A server MAY relax these
limits for commands defined in an extension. limits for commands defined in an extension.
Where this specification permits UTF-8 characters outside the range Where this specification permits UTF-8 characters outside the range
U+0000 to U+007F, implementations MUST NOT use the Byte Order Mark U+0000 to U+007F, implementations MUST NOT use the Byte Order Mark
(U+FEFF, encoding %xEF.BB.BF), and MUST use the Word Joiner (U+2060, (U+FEFF, encoding %xEF.BB.BF), and MUST use the Word Joiner (U+2060,
encoding %xE2.91.A0) for the meaning Zero Width No-Break Space, in encoding %xE2.91.A0) for the meaning Zero Width No-Break Space, in
command lines and the initial lines of responses, and SHOULD apply command lines and the initial lines of responses, and SHOULD apply
these same principles throughout. these same principles throughout.
skipping to change at page 9, line 8 skipping to change at page 10, line 5
commands in this specification are LIST and MODE. Note that such commands in this specification are LIST and MODE. Note that such
variants are sometimes referred to as if they were commands in their variants are sometimes referred to as if they were commands in their
own right: "the LIST ACTIVE" command should be read as shorthand for own right: "the LIST ACTIVE" command should be read as shorthand for
"the ACTIVE variant of the LIST command". "the ACTIVE variant of the LIST command".
Keywords are case-insensitive; the case of keywords for commands MUST Keywords are case-insensitive; the case of keywords for commands MUST
be ignored by the server. Command and response arguments are case- be ignored by the server. Command and response arguments are case-
or language-specific only when stated, either in this document or in or language-specific only when stated, either in this document or in
other relevant specifications. other relevant specifications.
An NNTP server MUST implement all the commands in this specification
except for those marked as optional and those in extensions.
Each response MUST start with a three-digit response code that is Each response MUST start with a three-digit response code that is
sufficient to distinguish all responses. Certain valid responses are sufficient to distinguish all responses. Certain valid responses are
defined to be multi-line; for all others, the response is contained defined to be multi-line; for all others, the response is contained
in a single line. The first or only line of the response MUST NOT in a single line. The first or only line of the response MUST NOT
exceed 512 octets, which includes the response code and the exceed 512 octets, which includes the response code and the
terminating CRLF pair; an extension MAY specify a greater maximum for terminating CRLF pair; an extension MAY specify a greater maximum for
commands that it defines, but not for any other command. commands that it defines, but not for any other command.
All multi-line responses MUST adhere to the following format: All multi-line responses MUST adhere to the following format:
1. The response consists of a sequence of one or more "lines", each 1. The response consists of a sequence of one or more "lines", each
skipping to change at page 10, line 48 skipping to change at page 11, line 41
x3x - Distribution functions x3x - Distribution functions
x4x - Posting x4x - Posting
x8x - Reserved for authentication and privacy extensions x8x - Reserved for authentication and privacy extensions
x9x - Reserved for private use (non-standard extensions) x9x - Reserved for private use (non-standard extensions)
Certain responses contain arguments such as numbers and names in Certain responses contain arguments such as numbers and names in
addition to the status indicator. In those cases, to simplify addition to the status indicator. In those cases, to simplify
interpretation by the client the number and type of such arguments is interpretation by the client the number and type of such arguments is
fixed for each response code, as is whether or not the code fixed for each response code, as is whether or not the code
introduces a multi-line response. Any extension MUST follow this introduces a multi-line response. Any extension MUST follow this
principle as well, but note that, for historical reasons, the 211 principle as well. Note that, for historical reasons, the 211
response code is an exception to this in that the response may be response code is an exception to this in that the response may be
multi-line or not depending on the command (GROUP or LISTGROUP) that multi-line or not depending on the command (GROUP or LISTGROUP) that
generated it. In all other cases, the client MUST only use the generated it. In all other cases, the client MUST only use the
status indicator itself to determine the nature of the response. The status indicator itself to determine the nature of the response. The
exact response codes that can be returned by any given command are exact response codes that can be returned by any given command are
detailed in the description of that command. detailed in the description of that command.
Arguments MUST be separated from the numeric status indicator and Arguments MUST be separated from the numeric status indicator and
from each other by a single space. All numeric arguments MUST be in from each other by a single space. All numeric arguments MUST be in
base 10 (decimal) format, and MAY have leading zeros. String base 10 (decimal) format, and MAY have leading zeros. String
skipping to change at page 11, line 39 skipping to change at page 12, line 32
If a client receives an unexpected response, it SHOULD use the first If a client receives an unexpected response, it SHOULD use the first
digit of the response to determine the result. For example, an digit of the response to determine the result. For example, an
unexpected 2xx should be taken as success and an unexpected 4xx or unexpected 2xx should be taken as success and an unexpected 4xx or
5xx as failure. 5xx as failure.
Response codes not specified in this document MAY be used for any Response codes not specified in this document MAY be used for any
installation-specific additional commands also not specified. These installation-specific additional commands also not specified. These
SHOULD be chosen to fit the pattern of x9x specified above. SHOULD be chosen to fit the pattern of x9x specified above.
Neither this document nor any registered extension (see Section 8) Neither this document nor any registered extension (see
will specify any response codes of the x9x pattern. (Implementers of Section 3.3.3) will specify any response codes of the x9x pattern.
extensions are accordingly cautioned not to use such responses for (Implementers of extensions are accordingly cautioned not to use such
extensions that may subsequently be submitted for registration.) responses for extensions that may subsequently be submitted for
registration.)
3.2.1 Generic Response Codes 3.2.1 Generic Response Codes
The server MUST respond to any command with the appropriate one of The server MUST respond to any command with the appropriate one of
the following generic responses if it represents the situation. the following generic responses if it represents the situation.
If the command is not recognized, or it is an optional command or If the command is not recognized, or it is an optional command that
extension that is not implemented by the server, the response code is not implemented by the server, the response code 500 MUST be
500 MUST be returned. returned.
If there is a syntax error in the arguments of a recognized command, If there is a syntax error in the arguments of a recognized command,
including the case where more arguments are provided than the command including the case where more arguments are provided than the command
specifies or the command line is longer than the server accepts, the specifies or the command line is longer than the server accepts, the
response code 501 MUST be returned. The line MUST NOT be truncated response code 501 MUST be returned. The line MUST NOT be truncated
or split and then interpreted. Note that where a command has or split and then interpreted. Note that where a command has
variants depending on a second keyword (e.g. LIST ACTIVE and LIST variants depending on a second keyword (e.g. LIST ACTIVE and LIST
NEWSGROUPS), then 501 MUST be used when the base command is NEWSGROUPS), then 501 MUST be used when the base command is
implemented but the requested variant is not, and 500 MUST be used implemented but the requested variant is not, and 500 MUST be used
only when the base command itself is not implemented. only when the base command itself is not implemented.
skipping to change at page 12, line 26 skipping to change at page 13, line 20
string [RFC3548] (there are no such arguments in this specification, string [RFC3548] (there are no such arguments in this specification,
but there may be in extensions) and is not validly encoded, the but there may be in extensions) and is not validly encoded, the
response code 504 MUST be returned. response code 504 MUST be returned.
If the server experiences an internal fault or problem that means it If the server experiences an internal fault or problem that means it
is unable to carry out the command (for example, a necessary file is is unable to carry out the command (for example, a necessary file is
missing or a necessary service could not be contacted), the response missing or a necessary service could not be contacted), the response
code 403 MUST be returned. If the server recognizes the command but code 403 MUST be returned. If the server recognizes the command but
does not provide an optional feature (for example because it does not does not provide an optional feature (for example because it does not
store the required information), or only handles a subset of store the required information), or only handles a subset of
legitimate cases (see the HDR command (Section 8.6.1) for an legitimate cases (see the HDR command (Section 8.5) for an example),
example), the response code 503 MUST be returned. Note that where a the response code 503 MUST be returned.
command is optional (e.g. LIST ACTIVE.TIMES) and is not provided by
a server, this MAY be treated as an unimplemented command (response
code 500 or 501 as appropriate) or as a working command where the
information is not available (response code 503).
If the client is not authorized to use the specified facility when If the client is not authorized to use the specified facility when
the server is in its current state, then the appropriate one of the the server is in its current state, then the appropriate one of the
following response codes MUST be used. following response codes MUST be used.
502: it is necessary to terminate the connection and start a new one 502: it is necessary to terminate the connection and start a new one
with the appropriate authority before the command can be used. with the appropriate authority before the command can be used.
Note that the server MUST NOT close the TCP connection immediately Historically, some mode-switching servers (see Section 3.4.1) have
after a 502 response except at the initial connection (Section used this response to indicate that this command will become
5.1) and with the MODE READER (Section 5.2) command. See also the available after the MODE READER (Section 5.3) command is used, but
latter command for historical usage of this response. this usage is not conforming to this specification and MUST NOT be
used. Note that the server MUST NOT close the TCP connection
immediately after a 502 response except at the initial connection
(Section 5.1) and with the MODE READER command.
480: the client must authenticate itself to the server (that is, 480: the client must authenticate itself to the server (that is,
provide information as to the identity of the client) before the provide information as to the identity of the client) before the
facility can be used on this connection. This will involve the facility can be used on this connection. This will involve the
use of an authentication extension such as [NNTP-AUTH]. use of an authentication extension such as [NNTP-AUTH].
483: the client must negotiate appropriate privacy protection on the 483: the client must negotiate appropriate privacy protection on the
connection. This will involve the use of a privacy extension such connection. This will involve the use of a privacy extension such
as [NNTP-TLS]. as [NNTP-TLS].
401: the client must change the state of the connection in some other 401: the client must change the state of the connection in some other
manner. The first argument of the response MUST be the manner. The first argument of the response MUST be the capability
extension-label (see Section 8) of the extension (which may be a label (see Section 5.2) of the facility (usually an extension,
private extension) that provides the necessary mechanism, or which may be a private extension) that provides the necessary
"MODE-READER" if it is necessary to use the MODE READER (Section mechanism. The server MUST NOT use this response code except as
5.2) command. specified by the definition of the capability in question.
If the server has to terminate the connection for some reason, it If the server has to terminate the connection for some reason, it
MUST give a 400 response code to the next command and then MUST give a 400 response code to the next command and then
immediately close the TCP connection. immediately close the TCP connection. Following a 400 response,
clients SHOULD NOT simply reconnect immediately and retry the same
actions. Rather, a client SHOULD either use an exponentially
increasing delay between retries (e.g. double the waiting time after
each 400 response) or present any associated text to the user for
them to decide whether and when to retry.
The client MUST be prepared to receive any of these responses for any The client MUST be prepared to receive any of these responses for any
command (except, of course, that the server MUST NOT generate a 500 command (except, of course, that the server MUST NOT generate a 500
response code for mandatory commands). response code for mandatory commands).
3.2.1.1 Examples 3.2.1.1 Examples
Example of an unknown command: Example of an unknown command:
[C] MAIL [C] MAIL
[S] 500 Unknown command [S] 500 Unknown command
Example of an unsupported extension: Example of an unsupported command:
[C] LIST EXTENSIONS [C] CAPABILITIES
[S] 202 Extensions supported: [S] 101 Capability list:
[S] LISTGROUP [S] VERSION 2
[S] READER LISTGROUP
[S] LIST ACTIVE NEWSGROUPS
[S] . [S] .
[C] OVER [C] OVER
[S] 500 Unknown command [S] 500 Unknown command
Example of an unsupported variant: Example of an unsupported variant:
[C] MODE POSTER [C] MODE POSTER
[S] 501 Unknown MODE option [S] 501 Unknown MODE option
Example of a syntax error: Example of a syntax error:
[C] ARTICLE a.message.id@no.angle.brackets [C] ARTICLE a.message.id@no.angle.brackets
skipping to change at page 14, line 4 skipping to change at page 15, line 5
[C] LIST ACTIVE u[ks].* [C] LIST ACTIVE u[ks].*
[S] 501 Syntax error [S] 501 Syntax error
Example of a base64-encoding error (the second argument is meant to Example of a base64-encoding error (the second argument is meant to
be base64-encoded): be base64-encoded):
[C] XENCRYPT RSA abcd=efg [C] XENCRYPT RSA abcd=efg
[S] 504 Base64 encoding error [S] 504 Base64 encoding error
Example of an attempt to access a facility not available to this Example of an attempt to access a facility not available to this
connection: connection:
[C] MODE READER [C] MODE READER
[S] 200 Reader mode, posting permitted [S] 200 Reader mode, posting permitted
[C] IHAVE <i.am.an.article.you.will.want@example.com> [C] IHAVE <i.am.an.article.you.will.want@example.com>
[S] 502 Permission denied [S] 500 Permission denied
Example of an attempt to access a facility requiring authentication: Example of an attempt to access a facility requiring authentication:
[C] GROUP secret.group [C] GROUP secret.group
[S] 480 Permission denied [S] 480 Permission denied
followed by a successful attempt following such authentication: followed by a successful attempt following such authentication:
[C] XSECRET fred flintstone [C] XSECRET fred flintstone
[S] 290 Password for fred accepted [S] 290 Password for fred accepted
[C] GROUP secret.group [C] GROUP secret.group
[S] 211 5 1 20 secret.group selected [S] 211 5 1 20 secret.group selected
skipping to change at page 14, line 45 skipping to change at page 15, line 45
Example of a temporary failure: Example of a temporary failure:
[C] GROUP archive.local [C] GROUP archive.local
[S] 403 Archive server temporarily offline [S] 403 Archive server temporarily offline
Example of the server needing to close down immediately: Example of the server needing to close down immediately:
[C] ARTICLE 123 [C] ARTICLE 123
[S] 400 Power supply failed, running on UPS [S] 400 Power supply failed, running on UPS
[Server closes connection.] [Server closes connection.]
3.3 Pipelining 3.3 Capabilities and Extensions
Not all NNTP servers provide exactly the same facilities, both
because this specification allows variation and because servers may
provide extensions. A set of facilities that are related are called
a "capability". This specification provides a way to determine what
capabilities are available, includes a list of standard capabilities,
and includes a mechanism (the extension mechanism) for defining new
capabilities.
3.3.1 Capability descriptions
A client can determine the available capabilities of the server by
using the CAPABILITIES command (Section 5.2). This returns a
capability list, which is a list of capability lines. Each line
describes one available capability.
Each capability line consists of one or more tokens, which MUST be
separated by one or more space or TAB characters. A token is a
string of 1 or more printable UTF-8 characters (that is, either
printable US-ASCII characters or any UTF-8 sequence outside the
US-ASCII range, but not space or TAB). Unless stated otherwise,
tokens are case-insensitive. Each capability line consists of:
o The capability label, which is a keyword indicating the
capability. A capability label may be defined by this
specification or a successor, or may be defined by an extension.
o The label is then followed by zero or more tokens, which are
arguments of the capability. The form and meaning of these tokens
is specific to each capability.
The server MUST ensure that the capability list accurately reflects
the capabilities (including extensions) currently available. If a
capability is only available with the server in a certain state (for
example, only after authentication), the list MUST only include the
capability label when in that state. Similarly, if only some of the
commands in an extension will be available, or if the behaviour of
the extension will change in some other manner, according to the
state of the server, this MUST be indicated by different arguments in
the capability line.
Note that a capability line can only begin with a letter. Lines
beginning with other characters are reserved for future versions of
this specification. In order to inter-work with such versions,
clients MUST be prepared to receive lines beginning with other
characters and MUST ignore any they do not understand.
3.3.2 Standard capabilities
The following capabilities are defined by this specification.
VERSION
This capability MUST be advertised by all servers and MUST be the
first capability in the capability list; it indicates the
version(s) of NNTP that the server supports. There must be at
least one argument; each argument is a decimal number and MUST NOT
have a leading zero. Version numbers are assigned only in RFCs
which update or replace this specification; servers MUST NOT
create their own version numbers.
The version number of this specification is 2.
IHAVE
This capability indicates that the server implements the IHAVE
command.
READER
This capability indicates that the server implements the various
commands useful for reading clients. If and only if the LISTGROUP
command is implemented, there MUST be a single argument LISTGROUP.
If and only if posting is permitted using the POST command, there
MUST be a single argument POST. (These arguments may appear in
either order.)
LIST
This capability indicates that the server implements at least one
variant of the LIST command. There MUST be one argument for each
variant of the LIST command supported by the server, giving the
keyword for that variant.
HDR
This capability indicates that the server implements the header
access commands (HDR and LIST HEADERS).
OVER
This capability indicates that the server implements the overview
access commands (OVER and LIST OVERVIEW.FMT). If and only if the
server supports the message-id form of the OVER command, there
must be a single argument MSGID.
IMPLEMENTATION
This capability MAY be provided by a server. If so, the arguments
SHOULD be used to provide information such as the server software
name and version number. The client MUST NOT use this line to
determine capabilities of the server. (While servers often
provide this information in the initial greeting, clients need to
guess whether this is the case; this capability makes it clear
what the information is.)
MODE-READER
This capability indicates that the server is mode-switching
(Section 3.4.2) and the MODE READER command needs to be used to
enable the READER capability.
3.3.3 Extensions
Although NNTP is widely and robustly deployed, some parts of the
Internet community might wish to extend the NNTP service. It must be
emphasized that any extension to NNTP should not be considered
lightly. NNTP's strength comes primarily from its simplicity.
Experience with many protocols has shown that:
Protocols with few options tend towards ubiquity, whilst protocols
with many options tend towards obscurity.
This means that each and every extension, regardless of its benefits,
must be carefully scrutinized with respect to its implementation,
deployment, and interoperability costs. In many cases, the cost of
extending the NNTP service will likely outweigh the benefit.
An extension is a package of associated facilities, often but not
always including one or more new commands. Each extension MUST
define at least one new capability label (this will often, but need
not, be the name of one of these new commands). While any additional
capability information can normally be specified using arguments to
that label, an extension MAY define more than one capability label.
However, this SHOULD be limited to exceptional circumstances.
An extension is either a private extension or else its capabilities
are included in the IANA registry of capabilities (see Section 3.3.4)
and it is defined in an RFC (in which case it is a "registered
extension"). Such RFCs either must be on the standards track or must
define an IESG-approved experimental protocol.
The definition of an extension must include:
o a descriptive name for the extension;
o the capability label or labels defined by the extension; the
capability label of a registered extension MUST NOT begin with
"X";
o the syntax, values, and meanings of any arguments for each
capability label defined by the extension;
o any new NNTP commands associated with the extension - the names of
commands associated with registered extensions MUST NOT begin with
"X";
o the syntax and possible values of arguments associated with the
new NNTP commands;
o the response codes and possible values of arguments for the
responses of the new NNTP commands;
o any new arguments the extension associates with any other
pre-existing NNTP commands;
o any increase in the maximum length of commands and initial
response lines over the value specified in this document;
o a specific statement about the effect on pipelining this extension
may have (if any);
o a specific statement about the circumstances when use of this
extension can alter the contents of the capabilities list (other
than the new capability labels it defines);
o the circumstances under which the extension can cause any
pre-existing command to produce a 401, 480, or 483 response;
o how the use of MODE READER on a mode-switching server interacts
with the extension;
o how support for the extension affects the behaviour of a server
and NNTP client in any other manner not outlined above;
o formal syntax as described in Section 9.8.
A private extension MAY or MAY NOT be included in the capabilities
list. If it is, the capability label MUST begin with "X". A server
MAY provide additional keywords - for new commands and also for new
variants of existing commands - as part of a private extension. To
avoid the risk of a clash with a future registered extension, these
keywords SHOULD begin with "X".
If the server advertises a capability defined by a registered
extension, it MUST implement the extension so as to fully conform
with the specification (for example, it MUST implement all of the
commands that the extension describes as mandatory). If it does not
implement the extension as specified, it MUST NOT list the extension
in the capabilities list under its registered name; in this case it
MAY, but SHOULD NOT, provide a private extension (not listed, or
listed with a different name) that implements part of the extension
or implements the commands of the extension with a different meaning.
A server MUST NOT send different response codes to basic NNTP
commands documented here or commands documented in registered
extensions in response to the availability or use of a private
extension.
3.3.4 Initial IANA register
IANA is requested to maintain a registry of NNTP capability labels.
All capability labels in the registry MUST be keywords and MUST NOT
begin with X.
The initial contents of the registry consists of these entries:
+--------------------+-------------------------+--------------------+
| Label | Meaning | Definition |
+--------------------+-------------------------+--------------------+
| AUTHINFO | Authentication | [NNTP-AUTH] |
| | | |
| HDR | Batched header | Section 3.3.2, |
| | retrieval | Section 8.5, and |
| | | Section 8.6 |
| | | |
| IHAVE | IHAVE command available | Section 3.3.2 and |
| | | Section 6.3.2 |
| | | |
| IMPLEMENTATION | Server | Section 3.3.2 |
| | implementation-specific | |
| | information | |
| | | |
| LIST | LIST command variants | Section 3.3.2 and |
| | | Section 7.6.1 |
| | | |
| MODE-READER | Mode-switching server | Section 3.4.2 |
| | and MODE READER command | |
| | available | |
| | | |
| OVER | Overview support | Section 3.3.2, |
| | | Section 8.3, and |
| | | Section 8.4 |
| | | |
| READER | Reader commands | Section 3.3.2 |
| | available | |
| | | |
| SASL | Supported SASL | [NNTP-AUTH] |
| | mechanisms | |
| | | |
| STARTTLS | Transport layer | [NNTP-TLS] |
| | security | |
| | | |
| STREAMING | Streaming feeds | [NNTP-STREAM] |
| | | |
| VERSION | Supported NNTP versions | Section 3.3.2 |
+--------------------+-------------------------+--------------------+
3.4 Mandatory and Optional Commands
For a number of reasons, not all the commands in this specification
are mandatory. However, it is equally undesirable for every command
to be optional, since this means that a client will have no idea what
facilities are available. Therefore, as a compromise, some of the
commands in this specification are mandatory - they must be supported
by all servers - while the remainder are not. The latter are then
subdivided into groups, each indicated by a single capability label.
o If the label is included in the capability list returned by the
server, the server MUST support all commands in that group.
o If the label is not included, the server MAY support none or some
of the commands, but SHOULD NOT support all of them. In general,
there will be no way for a client to determine which commands are
supported without trying them.
The groups have been chosen to provide useful functionality, and
therefore server authors are discouraged from implementing only part
of a group.
The description of each command will either indicate that it is
mandatory, or will give, using the term "indicating capability", the
capability label indicating whether or not the group including this
command is available.
Where a server does not implement a command, it MUST always generate
a 500 generic response code (or a 501 generic response code in the
case of a variant of a command depending on a second keyword where
the base command is recognised). Otherwise the command MUST be fully
implemented as specified; a server MUST NOT only partially implement
any of the commands in this specification. (Client authors should
note that some servers, not conforming to this specification, will
return a 502 generic response code to some commands that are not
implemented.)
Note: some commands have cases that require other commands to be used
first. If the former command is implemented but the latter is not,
the former MUST still generate the relevant specific response code.
For example, if ARTICLE (Section 6.2.1) is implemented but GROUP
(Section 6.1.1) is not, the correct response to "ARTICLE 1234"
remains 412.
3.4.1 Reading and Transit Servers
NNTP is traditionally used in two different ways. The first use is
"reading", where the client fetches articles from a large store
maintained by the server for immediate or later presentation to a
user, and sends articles created by that user back to the server (an
action called "posting") to be stored and distributed to other stores
and users. The second use is for the bulk transfer of articles from
one store to another. Since the hosts doing this transfer tend to be
peers in a network that transmit articles among one another, rather
than end-user systems, this process is called "peering" or "transit"
(even so, one host is still the client and the other is the server).
In practice these two uses are so different that some server
implementations are optimised for reading or for transit and, as a
result, do not offer the other facility or only offer limited
features. Other implementations are more general and offer both.
This specification allows for this by grouping the relevant commands
accordingly: the IHAVE command is designed for transit, while the
commands indicated by the READER capability are designed for reading
clients.
Except as an effect of the MODE READER (Section 5.3) command on a
mode-switching server, once a server advertises either or both of the
IHAVE or READER capabilities, it MUST NOT cease to advertise them
later in the session.
A server MAY provide different modes of behaviour (transit, reader,
or a combination) to different client connections and MAY use
external information, such as the IP address of the client, to
determine which mode to provide to any given connection.
The official TCP port for the NNTP service is 119. However, if a
host wishes to offer separate servers for transit and reading
clients, port 433 SHOULD be used for the transit server and 119 for
the reading server.
3.4.2 Mode switching
An implementation MAY, but SHOULD NOT, provide both transit and
reader facilities on the same server but require the client to select
which it wishes to use. Such an arrangement is called a
"mode-switching" server.
A mode-switching server has two modes:
o Transit mode, which applies after the initial connection:
* it MUST advertise the MODE-READER capability;
* it MUST NOT advertise the READER capability.
However, the server MAY cease to advertise the MODE-READER
capability after the client uses any command except CAPABILITIES.
o Reading mode, after a successful MODE READER (Section 5.3)
command:
* it MUST not advertise the MODE-READER capability;
* it MUST advertise the READER capability;
* it MAY NOT advertise the IHAVE capability even if it was
advertising it in transit mode.
A client SHOULD only issue a MODE READER command to a server if it is
advertising the MODE-READER capability. If the server does not
support CAPABILITIES (and therefore does not conform to this
specification), the client MAY use the following heuristic:
o if the client wishes to use any "reader" commands, it SHOULD use
the MODE READER command immediately after the initial connection;
o otherwise it SHOULD NOT use the MODE READER command.
In each case it should be prepared for some commands to be
unavailable that would have been available if it had made the other
choice.
3.5 Pipelining
NNTP is designed to operate over a reliable bi-directional connection NNTP is designed to operate over a reliable bi-directional connection
such as TCP. Therefore, if a command does not depend on the response such as TCP. Therefore, if a command does not depend on the response
to the previous one, it should not matter if it is sent before that to the previous one, it should not matter if it is sent before that
response is received. Doing this is called "pipelining". However, response is received. Doing this is called "pipelining". However,
certain server implementations throw away all text received from the certain server implementations throw away all text received from the
client following certain commands before sending their response. If client following certain commands before sending their response. If
this happens, pipelining will be affected because one or more this happens, pipelining will be affected because one or more
commands will have been ignored or misinterpreted, and the client commands will have been ignored or misinterpreted, and the client
will be matching the wrong responses to each command. Since there will be matching the wrong responses to each command. Since there
skipping to change at page 15, line 37 skipping to change at page 24, line 6
of the greeting. of the greeting.
If the client uses blocking system calls to send commands, it MUST If the client uses blocking system calls to send commands, it MUST
ensure that the amount of text sent in pipelining does not cause a ensure that the amount of text sent in pipelining does not cause a
deadlock between transmission and reception. The amount of text deadlock between transmission and reception. The amount of text
involved will depend on window sizes in the transmission layer, and involved will depend on window sizes in the transmission layer, and
is typically 4k octets for TCP. (Since the server only sends data in is typically 4k octets for TCP. (Since the server only sends data in
response to commands from the client, the converse problem does not response to commands from the client, the converse problem does not
occur.) occur.)
3.3.1 Examples 3.5.1 Examples
Example of correct use of pipelining: Example of correct use of pipelining:
[C] GROUP misc.test [C] GROUP misc.test
[C] STAT [C] STAT
[C] NEXT [C] NEXT
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[S] 223 3000234 <45223423@example.com> retrieved [S] 223 3000234 <45223423@example.com> retrieved
[S] 223 3000237 <668929@example.org> retrieved [S] 223 3000237 <668929@example.org> retrieved
Example of incorrect use of pipelining (the MODE READER command may Example of incorrect use of pipelining (the MODE READER command may
not be pipelined): not be pipelined):
[C] GROUP misc.test
[C] MODE READER [C] MODE READER
[C] DATE [C] DATE
[C] NEXT [C] NEXT
[S] 211 1234 3000234 3002322 misc.test
[S] 200 Server ready, posting allowed [S] 200 Server ready, posting allowed
[S] 223 3000237 <668929@example.org> retrieved [S] 223 3000237 <668929@example.org> retrieved
The DATE command has been thrown away by the server and so there is The DATE command has been thrown away by the server and so there is
no 111 response to match it. no 111 response to match it.
3.4 Articles 3.6 Articles
NNTP is intended to transfer articles between clients and servers. NNTP is intended to transfer articles between clients and servers.
For the purposes of this specification, articles are required to For the purposes of this specification, articles are required to
conform to the rules in this section and clients and servers MUST conform to the rules in this section and clients and servers MUST
correctly process any article received from the other that does so. correctly process any article received from the other that does so.
Note that this requirement applies only to the contents of Note that this requirement applies only to the contents of
communications over NNTP; it does not prevent the client or server communications over NNTP; it does not prevent the client or server
from subsequently rejecting an article for reasons of local policy. from subsequently rejecting an article for reasons of local policy.
Also see Appendix B for further restrictions on the format of Also see Appendix A for further restrictions on the format of
articles in some uses of NNTP. articles in some uses of NNTP.
An article consists of two parts: the headers and the body. They are An article consists of two parts: the headers and the body. They are
separated by a single empty line, or in other words by two separated by a single empty line, or in other words by two
consecutive CRLF pairs (if there is more than one empty line, the consecutive CRLF pairs (if there is more than one empty line, the
second and subsequent ones are part of the body). In order to meet second and subsequent ones are part of the body). In order to meet
the general requirements of NNTP, an article MUST NOT include the the general requirements of NNTP, an article MUST NOT include the
octet NUL, MUST NOT contain the octets LF and CR other than as part octet NUL, MUST NOT contain the octets LF and CR other than as part
of a CRLF pair, and MUST end with a CRLF pair. This specification of a CRLF pair, and MUST end with a CRLF pair. This specification
puts no further restrictions on the body; in particular, it MAY be puts no further restrictions on the body; in particular, it MAY be
skipping to change at page 17, line 10 skipping to change at page 25, line 25
the colon that follows the header name, and SHOULD include at least the colon that follows the header name, and SHOULD include at least
one octet other than %x09 or %x20 between CRLF pairs. However, if an one octet other than %x09 or %x20 between CRLF pairs. However, if an
article has been received from elsewhere with one of these, clients article has been received from elsewhere with one of these, clients
and servers MAY transfer it to the other without re-folding it. and servers MAY transfer it to the other without re-folding it.
The content of a header SHOULD be in UTF-8. However, if a server The content of a header SHOULD be in UTF-8. However, if a server
receives an article from elsewhere that uses octets in the range 128 receives an article from elsewhere that uses octets in the range 128
to 255 in some other manner, it MAY pass it to a client without to 255 in some other manner, it MAY pass it to a client without
modification. Therefore clients MUST be prepared to receive such modification. Therefore clients MUST be prepared to receive such
headers and also data derived from them (e.g. in the responses from headers and also data derived from them (e.g. in the responses from
the OVER extension (Section 8.5)) and MUST NOT assume that they are the OVER (Section 8.3) command) and MUST NOT assume that they are
always UTF-8. How the client will then process those headers, always UTF-8. How the client will then process those headers,
including identifying the encoding used, is outside the scope of this including identifying the encoding used, is outside the scope of this
document. document.
Each article MUST have a unique message-id; two articles offered by Each article MUST have a unique message-id; two articles offered by
an NNTP server MUST NOT have the same message-id. For the purposes an NNTP server MUST NOT have the same message-id. For the purposes
of this specification, message-ids are opaque strings that MUST meet of this specification, message-ids are opaque strings that MUST meet
the following requirements: the following requirements:
o A message-id MUST begin with "<" and end with ">", and MUST NOT o A message-id MUST begin with "<" and end with ">", and MUST NOT
contain the latter except at the end. contain the latter except at the end.
o A message-id MUST be between 3 and 250 octets in length. o A message-id MUST be between 3 and 250 octets in length.
o A message-id MUST NOT contain octets other than printable US-ASCII o A message-id MUST NOT contain octets other than printable US-ASCII
characters. characters.
Two message-ids are the same if and only if they consist of the same Two message-ids are the same if and only if they consist of the same
sequence of octets. sequence of octets.
This specification does not describe how the message-id of an article This specification does not describe how the message-id of an article
is determined. If the server does not have any way to determine a is determined. If the server does not have any way to determine a
message-id from the article itself, it MUST synthesize one (this message-id from the article itself, it MUST synthesize one (this
specification does not require the article to be changed as a specification does not require the article to be changed as a
result). See also Appendix B.2. result). See also Appendix A.2.
4. The WILDMAT format 4. The WILDMAT format
The WILDMAT format described here is based on the version first The WILDMAT format described here is based on the version first
developed by Rich Salz [SALZ1992], which in turn was derived from the developed by Rich Salz [SALZ1992], which in turn was derived from the
format used in the UNIX "find" command to articulate file names. It format used in the UNIX "find" command to articulate file names. It
was developed to provide a uniform mechanism for matching patterns in was developed to provide a uniform mechanism for matching patterns in
the same manner that the UNIX shell matches filenames. the same manner that the UNIX shell matches filenames.
4.1 Wildmat syntax 4.1 Wildmat syntax
A wildmat is described by the following ABNF [RFC2234] syntax (note A wildmat is described by the following ABNF [RFC2234] syntax, which
that this syntax contains ambiguities and special cases described at is an extract of that in Section 9.7.
the end):
wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) wildmat = wildmat-pattern *("," ["!"] wildmat-pattern)
wildmat-pattern = 1*wildmat-item wildmat-pattern = 1*wildmat-item
; must not begin with "!" if not immediately preceded by "!"
wildmat-item = wildmat-exact / wildmat-wild wildmat-item = wildmat-exact / wildmat-wild
wildmat-exact = %x21-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / wildmat-exact = %x21-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E /
UTF8-non-ascii ; exclude * , ? [ \ ] UTF8-non-ascii ; exclude * , ? [ \ ]
wildmat-wild = "*" / "?" wildmat-wild = "*" / "?"
UTF8-non-ascii is defined in Section 9.
This syntax must be interpreted subject to the following rule:
Where a wildmat-pattern is not immediately preceded by "!", it shall
not begin with a "!".
Note: the characters \ , [ and ] are not allowed in wildmats, while * Note: the characters \ , [ and ] are not allowed in wildmats, while *
and ? are always wildcards. This should not be a problem since these and ? are always wildcards. This should not be a problem since these
characters cannot occur in newsgroup names, which is the only current characters cannot occur in newsgroup names, which is the only current
use of wildmats. Backslash is commonly used to suppress the special use of wildmats. Backslash is commonly used to suppress the special
meaning of characters while brackets are used to introduce sets. meaning of characters while brackets are used to introduce sets.
However, these usages are not universal and interpretation of these However, these usages are not universal and interpretation of these
characters in the context of UTF-8 strings is both potentially characters in the context of UTF-8 strings is both potentially
complex and differs from existing practice, so they were omitted from complex and differs from existing practice, so they were omitted from
this specification. A future extension to this specification may this specification. A future extension to this specification may
provide semantics for these characters. provide semantics for these characters.
4.2 Wildmat semantics 4.2 Wildmat semantics
A wildmat is tested against a string, and either matches or does not A wildmat is tested against a string, and either matches or does not
match. To do this, each constituent wildmat-pattern is matched match. To do this, each constituent <wildmat-pattern> is matched
against the string and the rightmost pattern that matches is against the string and the rightmost pattern that matches is
identified. If that wildmat-pattern is not preceded with "!", the identified. If that <wildmat-pattern> is not preceded with "!", the
whole wildmat matches. If it is preceded by "!", or if no whole wildmat matches. If it is preceded by "!", or if no
wildmat-pattern matches, the whole wildmat does not match. <wildmat-pattern> matches, the whole wildmat does not match.
For example, consider the wildmat "a*,!*b,*c*": For example, consider the wildmat "a*,!*b,*c*":
the string "aaa" matches because the rightmost match is with "a*" the string "aaa" matches because the rightmost match is with "a*"
the string "abb" does not match because the rightmost match is the string "abb" does not match because the rightmost match is
with "*b" with "*b"
the string "ccb" matches because the rightmost match is with "*c*" the string "ccb" matches because the rightmost match is with "*c*"
the string "xxx" does not match because no wildmat-pattern matches the string "xxx" does not match because no <wildmat-pattern>
matches
A wildmat-pattern matches a string if the string can be broken into A <wildmat-pattern> matches a string if the string can be broken into
components, each of which matches the corresponding wildmat-item in components, each of which matches the corresponding <wildmat-item> in
the pattern; the matches must be in the same order, and the whole the pattern; the matches must be in the same order, and the whole
string must be used in the match. The pattern is "anchored"; that string must be used in the match. The pattern is "anchored"; that
is, the first and last characters in the string must match the first is, the first and last characters in the string must match the first
and last item respectively (unless that item is an asterisk matching and last item respectively (unless that item is an asterisk matching
zero characters). zero characters).
A wildmat-exact matches the same character (which may be more than A <wildmat-exact> matches the same character (which may be more than
one octet in UTF-8). one octet in UTF-8).
"?" matches exactly one character (which may be more than one octet). "?" matches exactly one character (which may be more than one octet).
"*" matches zero or more characters. It can match an empty string, "*" matches zero or more characters. It can match an empty string,
but it cannot match a subsequence of a UTF-8 sequence that is not but it cannot match a subsequence of a UTF-8 sequence that is not
aligned to the character boundaries. aligned to the character boundaries.
4.3 Extensions 4.3 Extensions
skipping to change at page 21, line 11 skipping to change at page 28, line 11
??a* any string with "a" as its third character ??a* any string with "a" as its third character
*a? any string with "a" as its penultimate character *a? any string with "a" as its penultimate character
*a?? any string with "a" as its antepenultimate character *a?? any string with "a" as its antepenultimate character
5. Session administration commands 5. Session administration commands
5.1 Initial Connection 5.1 Initial Connection
5.1.1 Usage 5.1.1 Usage
This command MUST NOT be pipelined.
Responses Responses
200 Service available, posting allowed [1] 200 Service available, posting allowed [1]
201 Service available, posting prohibited [1] 201 Service available, posting prohibited [1]
400 Service temporarily unavailable [1][2] 400 Service temporarily unavailable [1][2]
502 Service permanently unavailable [1][2] 502 Service permanently unavailable [1][2]
[1] These are the only valid response codes for the initial greeting; [1] These are the only valid response codes for the initial greeting;
the server MUST not return any other generic response code. the server MUST not return any other generic response code.
[2] Following a 400 or 502 response the server MUST immediately close [2] Following a 400 or 502 response the server MUST immediately close
the connection. the connection.
skipping to change at page 21, line 44 skipping to change at page 28, line 45
Otherwise the server MUST present a 400 or 502 greeting code and then Otherwise the server MUST present a 400 or 502 greeting code and then
immediately close the connection. 400 SHOULD be used if the issue is immediately close the connection. 400 SHOULD be used if the issue is
only temporary (for example, because of load) and the client can only temporary (for example, because of load) and the client can
expect to be able to connect successfully at some point in the future expect to be able to connect successfully at some point in the future
without making any changes. 502 MUST be used if the client is not without making any changes. 502 MUST be used if the client is not
permitted under any circumstances to interact with the server, and permitted under any circumstances to interact with the server, and
MAY be used if the server has insufficient information to determine MAY be used if the server has insufficient information to determine
whether the issue is temporary or permanent. whether the issue is temporary or permanent.
Note: the distinction between the 200 and 201 response codes has
turned out in practice to be insufficient; for example, some servers
do not allow posting until the client has authenticated, while other
clients assume that a 201 response means that posting will never be
possible even after authentication. Therefore clients SHOULD use the
CAPABILITIES command (Section 5.2) rather than rely on this response.
5.1.3 Examples 5.1.3 Examples
Example of a normal connection from an authorized client which then Example of a normal connection from an authorized client which then
terminates the session (see Section 5.4): terminates the session (see Section 5.4):
[Initial TCP connection set-up completed.] [Initial TCP connection set-up completed.]
[S] 200 NNTP Service Ready, posting permitted [S] 200 NNTP Service Ready, posting permitted
[C] QUIT [C] QUIT
[S] 205 NNTP Service exits normally [S] 205 NNTP Service exits normally
[Server closes connection.] [Server closes connection.]
Example of a normal connection from an authorized client that is not Example of a normal connection from an authorized client that is not
permitted to post; it also immediately terminates the session: permitted to post; it also immediately terminates the session:
[Initial TCP connection set-up completed.] [Initial TCP connection set-up completed.]
[S] 201 NNTP Service Ready, posting prohibited [S] 201 NNTP Service Ready, posting prohibited
[C] QUIT [C] QUIT
[S] 205 NNTP Service exits normally [S] 205 NNTP Service exits normally
[Server closes connection.] [Server closes connection.]
Example of a normal connection from an unauthorized client: Example of a normal connection from an unauthorized client:
[Initial TCP connection set-up completed.] [Initial TCP connection set-up completed.]
skipping to change at page 22, line 23 skipping to change at page 29, line 34
[Initial TCP connection set-up completed.] [Initial TCP connection set-up completed.]
[S] 502 NNTP Service permanently unavailable [S] 502 NNTP Service permanently unavailable
[Server closes connection.] [Server closes connection.]
Example of a connection from a client where the server is unable to Example of a connection from a client where the server is unable to
provide service: provide service:
[Initial TCP connection set-up completed.] [Initial TCP connection set-up completed.]
[S] 400 NNTP Service temporarily unavailable [S] 400 NNTP Service temporarily unavailable
[Server closes connection.] [Server closes connection.]
5.2 MODE READER 5.2 CAPABILITIES
5.2.1 Usage 5.2.1 Usage
This command MUST NOT be pipelined. This command is mandatory.
Syntax Syntax
MODE READER CAPABILITIES [keyword]
Responses Responses
200 Posting allowed 101 Capability list follows (multiline)
201 Posting prohibited Parameters
400 Service temporarily unavailable [1] keyword = additional feature, see description
502 Service permanently unavailable [1]
[1] Following a 400 or 502 response the server MUST immediately close
the connection.
5.2.2 Description 5.2.2 Description
MODE READER SHOULD be sent by any client that intends to use any The CAPABILITIES command allows a client to determine the
command in this specification (including Section 8) other than IHAVE, capabilities of the server at any given time.
HEAD, STAT, LIST ACTIVE, or LIST EXTENSIONS; other extensions MAY
also require MODE READER to be used. Servers MAY require that this
command be issued before any commands other than the above are sent
and MAY reject such commands until after a MODE READER command has
been sent. Such rejections SHOULD use response code 401 with
argument "MODE-READER", but for historical reasons response code 502
MAY be used, even though this situation does not meet the conditions
for that response.
Once MODE READER is sent, IHAVE (and any related extensions) MAY no
longer be permitted, even if it were permitted before the MODE READER
command. The results of LIST EXTENSIONS MAY be different following a
MODE READER command than prior to the issuing of that command.
The server MUST return a response using the same codes as the initial
greeting (as described in Section 5.1.1) to indicate its ability to
provide reading service to the client. Note that the response need
not be the same as the one presented during the initial greeting.
Servers are encouraged to not require this command even though
clients SHOULD send it when appropriate. It is present to support
some news architectures that switch between modes based on whether a
given connection is a peer-to-peer connection with another server or
a news reading client.
5.2.3 Examples This command MAY be issued at any time; the server MUST NOT require
it to be issued in order to make use of any capability. The response
generated by this command MAY change during a session because of
other state information (which in turn may be changed by the effects
of other commands or by external events). An NNTP client is only
able to get the current and correct information concerning available
capabilities at any point during a session by issuing a CAPABILITIES
command at that point of that session and processing the response.
Example of use of the MODE READER command by an authorized client The capability list is returned as a multi-line response following
which then terminates the session (see Section 5.4): the 101 response code. Each capability is described by a separate
[C] MODE READER capability line. The server MUST NOT list the same capability twice
[S] 200 NNTP Service Ready, posting permitted in the response, even with different arguments. Except that the
[C] QUIT VERSION capability MUST be the first line, the order in which the
[S] 205 NNTP Service exits normally capability lines appears is not significant; the server need not even
[Server closes connection.] consistently return the same order.
Example of use of the MODE READER command by an authorized client While some capabilities are likely to be always available or never
that is not permitted to post; it also immediately terminates the available, others - notably extensions - will appear and disappear
session: depending on server state changes within the session or external
[C] MODE READER events between sessions. An NNTP client MAY cache the results of
[S] 201 NNTP Service Ready, posting prohibited this command, but MUST NOT rely on the correctness of any cached
[C] QUIT results, whether from earlier in this session or from a previous
[S] 205 NNTP Service exits normally session, MUST cope gracefully with the cached status being out of
[Server closes connection.] date, and SHOULD (if caching results) provide a way to force the
cached information to be refreshed. Furthermore, a client MUST NOT
use cached results in relation to security, privacy, and
authentication extensions. See Section 11.6 for further discussion
of this topic.
Example of use of MODE READER by a client not authorized to receive The keyword argument is not used by this specification. It is
service from the server as a news reader: provided so that extensions or revisions to this specification can
[C] MODE READER include extra features for this command without requiring the
[S] 502 NNTP Service permanently unavailable CAPABILITIES command to be used twice (once to determine if the extra
[Server closes connection.] features are available and a second time to make use of them). If
the server does not recognise the argument (and it is a keyword), it
MUST respond with the 101 response code as if the argument had been
omitted. If an argument is provided that the server does recognise,
it MAY use the 101 response code or MAY use some other response code
(which will be defined in the specification of that feature). If the
argument is not a keyword, the 501 generic response code MUST be
returned. The server MUST NOT generate any other response code to
the CAPABILITIES command.
Example of a connection from any client where the server is 5.2.3 Examples
temporarily unable to provide news reader service:
[C] MODE READER
[S] 400 NNTP Service temporarily unavailable
[Server closes connection.]
Example of a facility that requires MODE READER before use, using the Example of a minimal response (a read-only server):
preferred response: [C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] GROUP misc.test Example of a response from a server that has a range of facilities
[S] 401 MODE-READER currently in peering mode and also describes itself:
[C] MODE READER [C] CAPABILITIES
[S] 200 NNTP Service Ready, posting permitted [S] 101 Capability list:
[C] GROUP misc.test [S] VERSION 2
[S] 211 1234 3000234 3002322 misc.test [S] READER
[S] IHAVE
[S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES OVERVIEW.FMT
[S] IMPLEMENTATION INN 4.2 2004-12-25
[S] OVER MSGID
[S] STREAMING
[S] XSECRET
[S] .
Example of a facility that requires MODE READER before use, using the Example of a server that supports more than one version of NNTP:
historical but deprecated response: [C] CAPABILITIES
[C] GROUP misc.test [S] 101 Capability list:
[S] 502 Not available in peering mode [S] VERSION 2 3
[C] MODE READER [S] READER
[S] 200 NNTP Service Ready, posting permitted [S] LIST ACTIVE NEWSGROUPS
[C] GROUP misc.test [S] .
[S] 211 1234 3000234 3002322 misc.test
Example of a facility that cannot be used after MODE READER: Example of a client attempting to use a feature of the CAPABILITIES
[C] IHAVE <i.am.an.article.you.have@example.com> command that the server does not support:
[S] 435 Duplicate [C] CAPABILITIES AUTOUPDATE
[C] MODE READER [S] 101 Capability list:
[S] 200 Reader mode, posting permitted [S] VERSION 2
[C] IHAVE <i.am.an.article.you.have@example.com> [S] READER LISTGROUP
[S] 502 Permission denied [S] IHAVE
[S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS
[S] OVER MSGID
[S] HDR
[S] .
5.3 LIST EXTENSIONS 5.3 MODE READER
5.3.1 Usage 5.3.1 Usage
This command is optional. Indicating capability: MODE-READER
This command MUST NOT be pipelined.
Syntax Syntax
LIST EXTENSIONS MODE READER
Responses Responses
202 Extension list follows (multiline) 200 Posting allowed
402 Server has no extensions 201 Posting prohibited
502 Reading service permanently unavailable [1]
[1] Following a 502 response the server MUST immediately close the
connection.
5.3.2 Description 5.3.2 Description
The LIST EXTENSIONS command allows a client to determine which The MODE READER command instructs a mode-switching server to switch
extensions are supported by the server at any given time. See modes, as described in Section 3.4.2.
Section 8 for further discussion of extensions.
This command MUST be implemented by any server that implements any
registered extension, and is optional otherwise. A server MUST NOT
generate the generic response 401, 480, 483, or 502 (all of which
indicate "not permitted") to this command.
This command MAY be issued at anytime during a session. It is not
required that the client issues this command before attempting to
make use of any extension. The response generated by this command
MAY change during a session because of other state information (which
in turn may be changed by the effects of other commands). An NNTP
client is only able to get the current and correct information
concerning available extensions at any point during a session by
issuing a LIST EXTENSIONS command at that point of that session and
processing the response, and the server MUST ensure that those
extensions currently listed in the returned information are
available. Therefore, if an extension (including those in Section 8)
is only available before or after a MODE READER command, the LIST
EXTENSIONS command MUST only include the extension in that situation.
Similarly, if only some of the commands in an extension will be
available, or if the behaviour of the extension will change in some
other manner, before or after a MODE READER command, this MUST be
indicated by different arguments to the extension-label in the
results of LIST EXTENSIONS in each situation.
While some extensions are likely to be always available or never
available, others will "appear" and "disappear" depending on server
state changes within the session or external events between sessions.
An NNTP client MAY cache the results of this command, but MUST NOT
rely on the correctness of any cached results, whether from earlier
in this session or from a previous session, MUST cope gracefully with
the cached status being out of date, and SHOULD (if caching results)
provide a way to force the cached information to be refreshed.
Furthermore, a client MUST NOT use cached results in relation to
security, privacy, and authentication extensions. See Section 11.6
for further discussion of this topic.
The list of extensions is returned as a multi-line response following
the 202 response code. Each extension is listed on a separate line;
the line MUST begin with an extension-label and optionally one or
more arguments (separated by one or more spaces). The
extension-label and the meaning of the arguments are specified as
part of the definition of the extension. The extension-label is a
string of 1 to 12 US-ASCII letters and MUST be in uppercase (that is,
%x41-5A). Arguments are strings of 1 or more printable UTF-8
characters (that is, either printable US-ASCII characters or any
UTF-8 sequence outside the US-ASCII range, but not space or TAB).
The server MUST NOT list the same extension twice in the response, If the server is mode-switching, it switches from its transit mode to
MUST list all supported registered extensions, and SHOULD list all its reader mode, indicating the fact by changing the capability list
supported private extensions. The order in which the extensions are accordingly, and then MUST return a 200 or 201 response with the same
listed is not significant. The server need not even consistently meaning as for the initial greeting (as described in Section 5.1.1);
return the same order. If the server does not support any note that the response need not be the same as the one presented
extensions, it MUST return an empty list. The 402 response code is during the initial greeting. The client MUST NOT issue MODE READER
documented for historic reasons only; clients SHOULD handle it more than once in a session or after any security or privacy commands
gracefully, but servers MUST NOT generate it. are issued. When the MODE READER command is issued, the server MAY
reset its state to that immediately after the initial connection
before switching mode.
Following a generic failure response, such as 403, an extension might If the server is not mode-switching, then:
still be available, and the client MAY attempt to use it. o If it advertises the READER capability, it MUST return a 200 or
201 response with the same meaning as for the initial greeting; in
this case the command MUST NOT affect the server state in any way.
o If it does not advertise the READER capability, it MUST return a
502 response and then immediately close the connection.
5.3.3 Examples 5.3.3 Examples
Example of a successful response: Example of use of the MODE READER command on a transit-only server
[C] LIST EXTENSIONS (which therefore does not providing reading facilities):
[S] 202 Extensions supported: [C] CAPABILITIES
[S] OVER MSGID [S] 101 Capability list:
[S] HDR [S] VERSION 2
[S] LISTGROUP [S] IHAVE
[S] . [S] .
The particular extensions shown here are simply examples of what [C] MODE READER
might be defined in other places, and no particular meaning should be [S] 502 Transit service only
attributed to them. [Server closes connection.]
Example where no extensions are available: Example of use of the MODE READER command on a server that provides
[C] LIST EXTENSIONS reading facilities:
[S] 202 Extensions supported: [C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER LISTGROUP
[S] LIST ACTIVE NEWSGROUPS
[S] . [S] .
[C] MODE READER
[S] 200 Reader mode, posting permitted
[C] IHAVE <i.am.an.article.you.have@example.com>
[S] 500 Permission denied
[C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test
Note that in both these situations the client SHOULD NOT use MODE
READER.
Example from a non-conforming server which indicates "no extensions Example of use of the MODE READER command on a mode-switching server:
available" using the 402 response code: [C] CAPABILITIES
[C] LIST EXTENSIONS [S] 101 Capability list:
[S] 402 Server has no extensions [S] VERSION 2
[S] IHAVE
[S] MODE-READER
[S] .
[C] MODE READER
[S] 200 Reader mode, posting permitted
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] LIST ACTIVE NEWSGROUPS
[S] STARTTLS
[S] .
In this case the server offers (but does not require) TLS privacy in
its reading mode but not its transit mode.
Example of use of the MODE READER command where the client is not
permitted to post:
[C] MODE READER
[S] 201 NNTP Service Ready, posting prohibited
5.4 QUIT 5.4 QUIT
5.4.1 Usage 5.4.1 Usage
This command is mandatory.
Syntax Syntax
QUIT QUIT
Responses Responses
205 Connection closing 205 Connection closing
5.4.2 Description 5.4.2 Description
The client uses the QUIT command to terminate the session. The The client uses the QUIT command to terminate the session. The
server MUST acknowledge the QUIT command and then close the server MUST acknowledge the QUIT command and then close the
connection to the client. This is the preferred method for a client connection to the client. This is the preferred method for a client
skipping to change at page 28, line 41 skipping to change at page 35, line 41
The following commands are used to set the "current selected The following commands are used to set the "current selected
newsgroup" and the "current article number", which are used by newsgroup" and the "current article number", which are used by
various commands. At the start of an NNTP session, both of these various commands. At the start of an NNTP session, both of these
values are set to the special value "invalid". values are set to the special value "invalid".
6.1.1 GROUP 6.1.1 GROUP
6.1.1.1 Usage 6.1.1.1 Usage
Indicating capability: READER
Syntax Syntax
GROUP group GROUP group
Responses Responses
211 number low high group Group successfully selected 211 number low high group Group successfully selected
411 No such newsgroup 411 No such newsgroup
Parameters Parameters
group = name of newsgroup group = name of newsgroup
number = estimated number of articles in the group number = estimated number of articles in the group
low = reported low water mark low = reported low water mark
high = reported high water mark high = reported high water mark
6.1.1.2 Description 6.1.1.2 Description
The required argument is the name of the newsgroup to be selected The required argument is the name of the newsgroup to be selected
(e.g. "news.software.b"). A list of valid newsgroups may be (e.g. "news.software.b"). A list of valid newsgroups may be
obtained by using the LIST ACTIVE command (see Section 7.6.1). obtained by using the LIST ACTIVE command (see Section 7.6.3).
The successful selection response will return the article numbers of The successful selection response will return the article numbers of
the first and last articles in the group at the moment of selection the first and last articles in the group at the moment of selection
(these numbers are referred to as the "reported low water mark" and (these numbers are referred to as the "reported low water mark" and
the "reported high water mark"), and an estimate of the number of the "reported high water mark"), and an estimate of the number of
articles in the group currently available. articles in the group currently available.
If the group is not empty, the estimate MUST be at least the actual If the group is not empty, the estimate MUST be at least the actual
number of articles available, and MUST be no greater than one more number of articles available, and MUST be no greater than one more
than the difference between the reported low and high water marks. than the difference between the reported low and high water marks.
skipping to change at page 30, line 22 skipping to change at page 37, line 22
decrease if an article is removed, and then increase again if it is decrease if an article is removed, and then increase again if it is
reinstated or if new articles arrive. reinstated or if new articles arrive.
When a valid group is selected by means of this command, the current When a valid group is selected by means of this command, the current
selected newsgroup MUST be set to that group and the current article selected newsgroup MUST be set to that group and the current article
number MUST be set to the first article in the group. If an empty number MUST be set to the first article in the group. If an empty
newsgroup is selected, the current article pointer is made invalid. newsgroup is selected, the current article pointer is made invalid.
If an invalid group is specified, the current selected newsgroup and If an invalid group is specified, the current selected newsgroup and
current article number MUST NOT be changed. current article number MUST NOT be changed.
The GROUP command (or the LISTGROUP command, if implemented) MUST be The GROUP or LISTGROUP command (see Section 6.1.2) MUST be used by a
used by a client and a successful response received before any other client and a successful response received before any other command is
command is used that depends on the value of the current selected used that depends on the value of the current selected newsgroup or
newsgroup or current article number. current article number.
If the group specified is not available on the server, a 411 response If the group specified is not available on the server, a 411 response
MUST be returned. MUST be returned.
6.1.1.3 Examples 6.1.1.3 Examples
Example for a group known to the server: Example for a group known to the server:
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
skipping to change at page 31, line 5 skipping to change at page 38, line 5
[S] 211 0 4000 3999 example.currently.empty.newsgroup [S] 211 0 4000 3999 example.currently.empty.newsgroup
Example of an empty group using an alternative response: Example of an empty group using an alternative response:
[C] GROUP example.currently.empty.newsgroup [C] GROUP example.currently.empty.newsgroup
[S] 211 0 0 0 example.currently.empty.newsgroup [S] 211 0 0 0 example.currently.empty.newsgroup
Example of an empty group using a different alternative response: Example of an empty group using a different alternative response:
[C] GROUP example.currently.empty.newsgroup [C] GROUP example.currently.empty.newsgroup
[S] 211 0 4000 4321 example.currently.empty.newsgroup [S] 211 0 4000 4321 example.currently.empty.newsgroup
6.1.2 LAST 6.1.2 LISTGROUP
6.1.2.1 Usage 6.1.2.1 Usage
Indicating capability: READER with argument LISTGROUP
Syntax
LISTGROUP [group]
Responses
211 number low high group Article numbers follow (multiline)
411 No such newsgroup
412 No newsgroup selected [1]
Parameters
group = name of newsgroup
number = estimated number of articles in the group
low = reported low water mark
high = reported high water mark
[1] The 412 response can only occur if no group has been specified.
6.1.2.2 Description
The LISTGROUP command is used to get a listing of all the article
numbers in a particular newsgroup. As a side effect, it also selects
the group in the same way as the GROUP command (see Section 6.1.1).
The optional argument is the name of the newsgroup to be selected
(e.g. "news.software.misc"). If no group is specified, the current
selected newsgroup is used.
On success, the list of article numbers is returned as a multi-line
response following the 211 response code (the arguments on the
initial response line are the same as for the GROUP command). The
list contains one number per line, is in numerical order, and lists
precisely those articles that exist in the group at the moment of
selection.
If the group specified is not available on the server, a 411 response
MUST be returned. If no group is specified and the current selected
newsgroup is invalid, a 412 response MUST be returned.
In all other aspects the LISTGROUP command behaves identically to the
GROUP command.
6.1.2.3 Examples
Example of LISTGROUP on an empty group:
[C] LISTGROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup list follows
[S] .
Example of LISTGROUP on a valid current selected newsgroup:
[C] GROUP misc.test
[S] 211 2000 3000234 3002322 misc.test
[C] LISTGROUP
[S] 211 2000 3000234 3002322 misc.test list follows
[S] 3000234
[S] 3000237
[S] 3000238
[S] 3000239
[S] 3002322
[S] .
Example of LISTGROUP failing because no group has been selected:
[Assumes current selected newsgroup is invalid.]
[C] LISTGROUP
[S] 412 no current group
[C] GROUP example.is.sob.bradner.or.barber
[S] 411 no such group
[C] LISTGROUP
[S] 412 no current group
6.1.3 LAST
6.1.3.1 Usage
Indicating capability: READER
Syntax Syntax
LAST LAST
Responses Responses
223 n message-id Article found 223 n message-id Article found
412 No newsgroup selected 412 No newsgroup selected
420 Current article number is invalid 420 Current article number is invalid
422 No previous article in this group 422 No previous article in this group
Parameters Parameters
n = article number n = article number
message-id = article message-id message-id = article message-id
6.1.2.2 Description 6.1.3.2 Description
If the current selected newsgroup is valid, the current article If the current selected newsgroup is valid, the current article
number MUST be set to the previous article in that newsgroup (that number MUST be set to the previous article in that newsgroup (that
is, the highest existing article number less than the current article is, the highest existing article number less than the current article
number). If successful, a response indicating the new current number). If successful, a response indicating the new current
article number and the message-id of that article MUST be returned. article number and the message-id of that article MUST be returned.
No article text is sent in response to this command. No article text is sent in response to this command.
There MAY be no previous article in the group, although the current There MAY be no previous article in the group, although the current
article number is not the reported low water mark. There MUST NOT be article number is not the reported low water mark. There MUST NOT be
skipping to change at page 31, line 45 skipping to change at page 40, line 18
LAST and NEXT commands MAY not be consistent over the life of a LAST and NEXT commands MAY not be consistent over the life of a
particular NNTP session. particular NNTP session.
If the current article number is already the first article of the If the current article number is already the first article of the
newsgroup, a 422 response MUST be returned. If the current article newsgroup, a 422 response MUST be returned. If the current article
number is invalid, a 420 response MUST be returned. If the current number is invalid, a 420 response MUST be returned. If the current
selected newsgroup is invalid, a 412 response MUST be returned. In selected newsgroup is invalid, a 412 response MUST be returned. In
all three cases the current selected newsgroup and current article all three cases the current selected newsgroup and current article
number MUST NOT be altered. number MUST NOT be altered.
6.1.2.3 Examples 6.1.3.3 Examples
Example of a successful article retrieval using LAST: Example of a successful article retrieval using LAST:
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] NEXT [C] NEXT
[S] 223 3000237 <668929@example.org> retrieved [S] 223 3000237 <668929@example.org> retrieved
[C] LAST [C] LAST
[S] 223 3000234 <45223423@example.com> retrieved [S] 223 3000234 <45223423@example.com> retrieved
Example of an attempt to retrieve an article without having selected Example of an attempt to retrieve an article without having selected
skipping to change at page 32, line 27 skipping to change at page 40, line 49
[C] LAST [C] LAST
[S] 422 No previous article to retrieve [S] 422 No previous article to retrieve
Example of an attempt to retrieve an article using the LAST command Example of an attempt to retrieve an article using the LAST command
when the current selected newsgroup is empty: when the current selected newsgroup is empty:
[C] GROUP example.empty.newsgroup [C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup
[C] LAST [C] LAST
[S] 420 No current article selected [S] 420 No current article selected
6.1.3 NEXT 6.1.4 NEXT
6.1.3.1 Usage 6.1.4.1 Usage
Indicating capability: READER
Syntax Syntax
NEXT NEXT
Responses Responses
223 n message-id Article found 223 n message-id Article found
412 No newsgroup selected 412 No newsgroup selected
420 Current article number is invalid 420 Current article number is invalid
421 No next article in this group 421 No next article in this group
Parameters Parameters
n = article number n = article number
message-id = article message-id message-id = article message-id
6.1.3.2 Description 6.1.4.2 Description
If the current selected newsgroup is valid, the current article If the current selected newsgroup is valid, the current article
number MUST be set to the next article in that newsgroup (that is, number MUST be set to the next article in that newsgroup (that is,
the lowest existing article number greater than the current article the lowest existing article number greater than the current article
number). If successful, a response indicating the new current number). If successful, a response indicating the new current
article number and the message-id of that article MUST be returned. article number and the message-id of that article MUST be returned.
No article text is sent in response to this command. No article text is sent in response to this command.
If the current article number is already the last article of the If the current article number is already the last article of the
newsgroup, a 421 response MUST be returned. In all other aspects newsgroup, a 421 response MUST be returned. In all other aspects
(apart, of course, from the lack of 422 response) this command is (apart, of course, from the lack of 422 response) this command is
identical to the LAST command (Section 6.1.2). identical to the LAST command (Section 6.1.3).
6.1.3.3 Examples 6.1.4.3 Examples
Example of a successful article retrieval using NEXT: Example of a successful article retrieval using NEXT:
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] NEXT [C] NEXT
[S] 223 3000237 <668929@example.org> retrieved [S] 223 3000237 <668929@example.org> retrieved
Example of an attempt to retrieve an article without having selected Example of an attempt to retrieve an article without having selected
a group (via the GROUP command) first: a group (via the GROUP command) first:
[Assumes current selected newsgroup is invalid.] [Assumes current selected newsgroup is invalid.]
skipping to change at page 33, line 45 skipping to change at page 42, line 21
[S] 211 0 0 0 example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup
[C] NEXT [C] NEXT
[S] 420 No current article selected [S] 420 No current article selected
6.2 Retrieval of articles and article sections 6.2 Retrieval of articles and article sections
The ARTICLE, BODY, HEAD, and STAT commands are very similar. They The ARTICLE, BODY, HEAD, and STAT commands are very similar. They
differ only in the parts of the article that are presented to the differ only in the parts of the article that are presented to the
client and in the successful response code. The ARTICLE command is client and in the successful response code. The ARTICLE command is
described here in full, while the other commands are described in described here in full, while the other commands are described in
terms of the differences. As specified in Section 3.4, an article terms of the differences. As specified in Section 3.6, an article
consists of two parts: the article headers and the article body. consists of two parts: the article headers and the article body.
When responding to one of these commands, the server MUST present the When responding to one of these commands, the server MUST present the
entire article or appropriate part and MUST NOT attempt to alter or entire article or appropriate part and MUST NOT attempt to alter or
translate it in any way. translate it in any way.
6.2.1 ARTICLE 6.2.1 ARTICLE
6.2.1.1 Usage 6.2.1.1 Usage
Indicating capability: READER
Syntax Syntax
ARTICLE message-id ARTICLE message-id
ARTICLE number ARTICLE number
ARTICLE ARTICLE
Responses Responses
First form (message-id specified) First form (message-id specified)
220 0|n message-id Article follows (multiline) 220 0|n message-id Article follows (multiline)
430 No article with that message-id 430 No article with that message-id
Second form (article number specified) Second form (article number specified)
220 n message-id Article follows (multiline) 220 n message-id Article follows (multiline)
skipping to change at page 37, line 9 skipping to change at page 45, line 31
selected newsgroup is empty: selected newsgroup is empty:
[C] GROUP example.empty.newsgroup [C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup
[C] ARTICLE [C] ARTICLE
[S] 420 No current article selected [S] 420 No current article selected
6.2.2 HEAD 6.2.2 HEAD
6.2.2.1 Usage 6.2.2.1 Usage
This command is mandatory.
Syntax Syntax
HEAD message-id HEAD message-id
HEAD number HEAD number
HEAD HEAD
Responses Responses
First form (message-id specified) First form (message-id specified)
221 0|n message-id Headers follow (multiline) 221 0|n message-id Headers follow (multiline)
430 No article with that message-id 430 No article with that message-id
Second form (article number specified) Second form (article number specified)
221 n message-id Headers follow (multiline) 221 n message-id Headers follow (multiline)
skipping to change at page 38, line 47 skipping to change at page 47, line 21
current selected newsgroup is empty: current selected newsgroup is empty:
[C] GROUP example.empty.newsgroup [C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup
[C] HEAD [C] HEAD
[S] 420 No current article selected [S] 420 No current article selected
6.2.3 BODY 6.2.3 BODY
6.2.3.1 Usage 6.2.3.1 Usage
Indicating capability: READER
Syntax Syntax
BODY message-id BODY message-id
BODY number BODY number
BODY BODY
Responses Responses
First form (message-id specified) First form (message-id specified)
222 0|n message-id Body follows (multiline) 222 0|n message-id Body follows (multiline)
430 No article with that message-id 430 No article with that message-id
Second form (article number specified) Second form (article number specified)
222 n message-id Body follows (multiline) 222 n message-id Body follows (multiline)
skipping to change at page 40, line 26 skipping to change at page 49, line 4
Example of an attempt to retrieve the body of an article when the Example of an attempt to retrieve the body of an article when the
current selected newsgroup is empty: current selected newsgroup is empty:
[C] GROUP example.empty.newsgroup [C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup
[C] BODY [C] BODY
[S] 420 No current article selected [S] 420 No current article selected
6.2.4 STAT 6.2.4 STAT
6.2.4.1 Usage 6.2.4.1 Usage
This command is mandatory.
Syntax Syntax
STAT message-id STAT message-id
STAT number STAT number
STAT STAT
Responses Responses
First form (message-id specified) First form (message-id specified)
223 0|n message-id Article exists 223 0|n message-id Article exists
430 No article with that message-id 430 No article with that message-id
Second form (article number specified) Second form (article number specified)
223 n message-id Article exists 223 n message-id Article exists
skipping to change at page 42, line 30 skipping to change at page 51, line 7
give the article number when the message-id is specified. The fourth give the article number when the message-id is specified. The fourth
STAT command shows that zero must be specified if the article isn't STAT command shows that zero must be specified if the article isn't
in the current selected group, the fifth shows that the number, if in the current selected group, the fifth shows that the number, if
provided, must be that relating to the current selected group, and provided, must be that relating to the current selected group, and
the last one shows that the current selected article is still not the last one shows that the current selected article is still not
changed by the use of STAT with a message-id even if it returns an changed by the use of STAT with a message-id even if it returns an
article number. article number.
6.3 Article posting 6.3 Article posting
Article posting is done in one of two modes: individual article Article posting is done in one of two ways: individual article
posting from news reading clients using POST, and article transfer posting from news reading clients using POST, and article transfer
from other news servers using IHAVE. from other news servers using IHAVE.
6.3.1 POST 6.3.1 POST
6.3.1.1 Usage 6.3.1.1 Usage
Indicating capability: READER with argument POST
This command MUST NOT be pipelined. This command MUST NOT be pipelined.
Syntax Syntax
POST POST
Responses Responses
Initial responses Initial responses
340 Send article to be posted 340 Send article to be posted
440 Posting not permitted 440 Posting not permitted
Subsequent responses Subsequent responses
240 Article received OK 240 Article received OK
441 Posting failed 441 Posting failed
6.3.1.2 Description 6.3.1.2 Description
If posting is allowed, a 340 response MUST be returned to indicate If posting is allowed, a 340 response MUST be returned to indicate
that the article to be posted should be sent. If posting is that the article to be posted should be sent. If posting is
prohibited for some installation-dependent reason, a 440 response prohibited for some installation-dependent reason, a 440 response
MUST be returned. MUST be returned.
If posting is permitted, the article MUST be in the format specified If posting is permitted, the article MUST be in the format specified
in Section 3.4 and MUST be sent by the client to the server in the in Section 3.6 and MUST be sent by the client to the server in the
manner specified (in Section 3.1) for multi-line responses (except manner specified (in Section 3.1) for multi-line responses (except
that there is no initial line containing a response code). Thus a that there is no initial line containing a response code). Thus a
single dot (".") on a line indicates the end of the text, and lines single dot (".") on a line indicates the end of the text, and lines
starting with a dot in the original text have that dot doubled during starting with a dot in the original text have that dot doubled during
transmission. transmission.
Following the presentation of the termination sequence by the client, Following the presentation of the termination sequence by the client,
the server MUST return a response indicating success or failure of the server MUST return a response indicating success or failure of
the article transfer. Note that response codes 340 and 440 are used the article transfer. Note that response codes 340 and 440 are used
in direct response to the POST command. Others are returned in direct response to the POST command. Others are returned
following the sending of the article. following the sending of the article.
A response of 240 SHOULD indicate that, barring unforeseen server A response of 240 SHOULD indicate that, barring unforeseen server
errors, the posted article will be made available on the server and/ errors, the posted article will be made available on the server
or transferred to other servers as appropriate, possibly following and/or transferred to other servers as appropriate, possibly
further processing. In other words, articles not wanted by the following further processing. In other words, articles not wanted by
server SHOULD be rejected with a 441 response and not accepted and the server SHOULD be rejected with a 441 response and not accepted
silently discarded. However, the client SHOULD NOT assume that the and silently discarded. However, the client SHOULD NOT assume that
article has been successfully transferred unless it receives an the article has been successfully transferred unless it receives an
affirmative response from the server, and SHOULD NOT assume that it affirmative response from the server, and SHOULD NOT assume that it
is being made available to other clients without explicitly checking is being made available to other clients without explicitly checking
(for example using the STAT command). (for example using the STAT command).
If the session is interrupted before the response is received, it is If the session is interrupted before the response is received, it is
possible that an affirmative response was sent but has been lost. possible that an affirmative response was sent but has been lost.
Therefore, in any subsequent session, the client SHOULD either check Therefore, in any subsequent session, the client SHOULD either check
whether the article was successfully posted before resending or whether the article was successfully posted before resending or
ensure that the server will allocate the same message-id to the new ensure that the server will allocate the same message-id to the new
attempt (see Appendix B.2) - the latter approach is preferred since attempt (see Appendix A.2) - the latter approach is preferred since
the article might not have been made available for reading yet (for the article might not have been made available for reading yet (for
example, it may have to go through a moderation process). example, it may have to go through a moderation process).
6.3.1.3 Examples 6.3.1.3 Examples
Example of a successful posting: Example of a successful posting:
[C] POST [C] POST
[S] 340 Input article; end with <CR-LF>.<CR-LF> [S] 340 Input article; end with <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net> [C] From: "Demo User" <nobody@example.net>
[C] Newsgroups: misc.test [C] Newsgroups: misc.test
skipping to change at page 44, line 21 skipping to change at page 52, line 46
[C] From: "Demo User" <nobody@example.net> [C] From: "Demo User" <nobody@example.net>
[C] Newsgroups: misc.test [C] Newsgroups: misc.test
[C] Subject: I am just a test article [C] Subject: I am just a test article
[C] Organization: An Example Net [C] Organization: An Example Net
[C] [C]
[C] This is just a test article. [C] This is just a test article.
[C] . [C] .
[S] 441 Posting failed [S] 441 Posting failed
Example of an attempt to post when posting is not allowed: Example of an attempt to post when posting is not allowed:
[C] MODE READER [Initial TCP connection set-up completed.]
[S] 201 NNTP Service Ready, posting prohibited [S] 201 NNTP Service Ready, posting prohibited
[C] POST [C] POST
[S] 440 Posting not permitted [S] 440 Posting not permitted
6.3.2 IHAVE 6.3.2 IHAVE
6.3.2.1 Usage 6.3.2.1 Usage
Indicating capability: IHAVE
This command MUST NOT be pipelined. This command MUST NOT be pipelined.
Syntax Syntax
IHAVE message-id IHAVE message-id
Responses Responses
Initial responses Initial responses
335 Send article to be transferred 335 Send article to be transferred
435 Article not wanted 435 Article not wanted
436 Transfer not possible; try again later 436 Transfer not possible; try again later
Subsequent responses Subsequent responses
235 Article transferred OK 235 Article transferred OK
skipping to change at page 48, line 16 skipping to change at page 56, line 16
This section lists other commands that may be used at any time This section lists other commands that may be used at any time
between the beginning of a session and its termination. Using these between the beginning of a session and its termination. Using these
commands does not alter any state information, but the response commands does not alter any state information, but the response
generated from their use may provide useful information to clients. generated from their use may provide useful information to clients.
7.1 DATE 7.1 DATE
7.1.1 Usage 7.1.1 Usage
Indicating capability: READER
Syntax Syntax
DATE DATE
Responses Responses
111 yyyymmddhhmmss server date and time 111 yyyymmddhhmmss server date and time
Parameters Parameters
yyyymmddHHmmss = Current UTC date and time on server yyyymmddHHmmss = Current UTC date and time on server
7.1.2 Description 7.1.2 Description
This command exists to help clients find out the current Coordinated This command exists to help clients find out the current Coordinated
Universal Time [TF.686-1] from the server's perspective. This Universal Time [TF.686-1] from the server's perspective. This
command SHOULD NOT be used as a substitute for NTP [RFC1305] but to command SHOULD NOT be used as a substitute for NTP [RFC1305] but to
provide information that might be useful when using the NEWNEWS provide information that might be useful when using the NEWNEWS
command (see Section 7.4). A system providing NNTP service SHOULD command (see Section 7.4).
The DATE command MUST return a timestamp from the same clock as is
used for determining article arrival and group creation times (see
Section 6). This clock SHOULD be monotonic, and adjustments SHOULD
be made by running it fast or slow compared to "real" time rather
than by making sudden jumps. A system providing NNTP service SHOULD
keep the system clock as accurate as possible, either with NTP or by keep the system clock as accurate as possible, either with NTP or by
some other method. some other method.
The server MUST return a 111 response specifying the date and time on The server MUST return a 111 response specifying the date and time on
the server in the form yyyymmddhhmmss. This date and time is in the server in the form yyyymmddhhmmss. This date and time is in
Coordinated Universal Time. Coordinated Universal Time.
7.1.3 Examples 7.1.3 Examples
[C] DATE [C] DATE
[S] 111 19990623135624 [S] 111 19990623135624
7.2 HELP 7.2 HELP
7.2.1 Usage 7.2.1 Usage
This command is mandatory.
Syntax Syntax
HELP HELP
Responses Responses
100 Help text follows (multiline) 100 Help text follows (multiline)
7.2.2 Description 7.2.2 Description
This command provides a short summary of commands that are understood This command provides a short summary of the commands that are
by this implementation of the server. The help text will be understood by this implementation of the server. The help text will
presented as a multiline response following the 100 response code. be presented as a multiline response following the 100 response code.
This text is not guaranteed to be in any particular format and MUST This text is not guaranteed to be in any particular format and MUST
NOT be used by clients as a replacement for the LIST EXTENSIONS NOT be used by clients as a replacement for the CAPABILITIES command
command described in Section 5.3 described in Section 5.2
7.2.3 Examples 7.2.3 Examples
[C] HELP [C] HELP
[S] 100 Help text follows [S] 100 Help text follows
[S] This is some help text. There is no specific [S] This is some help text. There is no specific
[S] formatting requirement for this test, though [S] formatting requirement for this test, though
[S] it is customary for it to list the valid commands [S] it is customary for it to list the valid commands
[S] and give a brief definition of what they do [S] and give a brief definition of what they do
[S] . [S] .
7.3 NEWGROUPS 7.3 NEWGROUPS
7.3.1 Usage 7.3.1 Usage
Indicating capability: READER
Syntax Syntax
NEWGROUPS date time [GMT] NEWGROUPS date time [GMT]
Responses Responses
231 List of new newsgroups follows (multiline) 231 List of new newsgroups follows (multiline)
Parameters Parameters
date = Date in yymmdd or yyyymmdd format date = Date in yymmdd or yyyymmdd format
time = Time in hhmmss format time = Time in hhmmss format
7.3.2 Description 7.3.2 Description
This command returns a list of newsgroups created on the server since This command returns a list of newsgroups created on the server since
the specified date and time. The results are in the same format as the specified date and time. The results are in the same format as
the LIST ACTIVE command (see Section 7.6.1). However, they MAY the LIST ACTIVE command (see Section 7.6.3). However, they MAY
include groups not available on the server (and so not returned by include groups not available on the server (and so not returned by
LIST ACTIVE) and MAY omit groups for which the creation date is not LIST ACTIVE) and MAY omit groups for which the creation date is not
available. The results SHOULD be consistent with those of the LIST available.
ACTIVE.TIMES command (Section 7.6.2), except that if the specified
date and time is earlier than the oldest entry in the latter then the
results of this command may include extra groups.
The date is specified as 6 or 8 digits in the format [xx]yymmdd, The date is specified as 6 or 8 digits in the format [xx]yymmdd,
where xx is the first two digits of the year (19-99), yy is the last where xx is the first two digits of the year (19-99), yy is the last
two digits of the year (00-99), mm is the month (01-12), and dd is two digits of the year (00-99), mm is the month (01-12), and dd is
the day of the month (01-31). Clients SHOULD specify all four digits the day of the month (01-31). Clients SHOULD specify all four digits
of the year. If the first two digits of the year are not specified of the year. If the first two digits of the year are not specified
(this is supported only for backwards compatibility), the year is to (this is supported only for backwards compatibility), the year is to
be taken from the current century if yy is smaller than or equal to be taken from the current century if yy is smaller than or equal to
the current year, otherwise the year is from the previous century. the current year, otherwise the year is from the previous century.
skipping to change at page 50, line 42 skipping to change at page 58, line 48
Example where there are no new groups: Example where there are no new groups:
[C] NEWGROUPS 19990624 000000 GMT [C] NEWGROUPS 19990624 000000 GMT
[S] 231 list of new newsgroups follows [S] 231 list of new newsgroups follows
[S] . [S] .
7.4 NEWNEWS 7.4 NEWNEWS
7.4.1 Usage 7.4.1 Usage
Indicating capability: READER
Syntax Syntax
NEWNEWS wildmat date time [GMT] NEWNEWS wildmat date time [GMT]
Responses Responses
230 List of new articles follows (multiline) 230 List of new articles follows (multiline)
Parameters Parameters
wildmat = Newsgroups of interest wildmat = Newsgroups of interest
date = Date in yymmdd or yyyymmdd format date = Date in yymmdd or yyyymmdd format
time = Time in hhmmss format time = Time in hhmmss format
7.4.2 Description 7.4.2 Description
skipping to change at page 51, line 45 skipping to change at page 60, line 5
[S] 230 list of new articles by message-id follows [S] 230 list of new articles by message-id follows
[S] . [S] .
7.5 Time 7.5 Time
As described in Section 6, each article has an arrival timestamp. As described in Section 6, each article has an arrival timestamp.
Each newsgroup also has a creation timestamp. These timestamps are Each newsgroup also has a creation timestamp. These timestamps are
used by the NEWNEWS and NEWGROUP commands to construct their used by the NEWNEWS and NEWGROUP commands to construct their
responses. responses.
The DATE command MUST return a timestamp from the same clock as is
used for determining article arrival and group creation times. This
clock SHOULD be monotonic, and adjustments SHOULD be made by running
it fast or slow compared to "real" time rather than by making sudden
jumps.
Clients can ensure that they do not have gaps in lists of articles or Clients can ensure that they do not have gaps in lists of articles or
groups by using the DATE command in the following manner: groups by using the DATE command in the following manner:
First session: First session:
Issue DATE command and record result Issue DATE command and record result
Issue NEWNEWS command using a previously chosen timestamp Issue NEWNEWS command using a previously chosen timestamp
Subsequent sessions: Subsequent sessions:
Issue DATE command and hold result in temporary storage Issue DATE command and hold result in temporary storage
Issue NEWNEWS command using timestamp saved from previous session Issue NEWNEWS command using timestamp saved from previous session
Overwrite saved timestamp with that currently in temporary storage Overwrite saved timestamp with that currently in temporary storage
In order to allow for minor errors, clients MAY want to adjust the In order to allow for minor errors, clients MAY want to adjust the
timestamp back by two or three minutes before using it in NEWNEWS. timestamp back by two or three minutes before using it in NEWNEWS.
skipping to change at page 52, line 41 skipping to change at page 60, line 43
[S] 230 list follows [S] 230 list follows
[S] <article.3@local.service> [S] <article.3@local.service>
[S] <article.4@local.service> [S] <article.4@local.service>
[S] <article.5@local.service> [S] <article.5@local.service>
[S] . [S] .
Note how <article.3@local.service> arrived in the 3 minute gap and so Note how <article.3@local.service> arrived in the 3 minute gap and so
is listed in both responses. is listed in both responses.
7.6 The LIST commands 7.6 The LIST commands
7.6.1 LIST ACTIVE The LIST family of commands all return information that is multi-line
and, in general, can be expected not to change during the session.
Often the information is related to newsgroups, in which case the
response has one line per newsgroup and a wildmat MAY be provided to
restrict the groups for which information is returned.
The set of available keywords (including those provided by
extensions) is given in the capability list with capability label
LIST.
7.6.1 LIST
7.6.1.1 Usage 7.6.1.1 Usage
Indicating capability: LIST
Syntax Syntax
LIST ACTIVE [wildmat] LIST [keyword [wildmat|argument]]
Responses Responses
215 Information follows (multiline) 215 Information follows (multiline)
Parameters Parameters
keyword = information requested [1]
argument = specific to keyword
wildmat = groups of interest wildmat = groups of interest
[1] If no keyword is provided, it defaults to ACTIVE.
7.6.1.2 Description 7.6.1.2 Description
The LIST ACTIVE command with no arguments returns a list of valid The LIST command allows the server to provide blocks of information
newsgroups and associated information. The server MUST include every to the client. This information may be global or may be related to
group that the client is permitted to select with the GROUP (Section newsgroups; in the latter case, the information may be returned
6.1.1) command. Each newsgroup is sent as a line of text in the either for all groups or only for those matching a wildmat. Each
following format: block of information is represented by a different keyword. The
group high low status command returns the specific information identified by the keyword.
where:
"group" is the name of the newsgroup;
"high" is the reported high water mark for the group;
"low" is the reported low water mark for the group;
"status" is the current status of the group on this server.
Each field in the line is separated from its neighbouring fields by
one or more spaces.
Note that an empty list is a possible valid response, and indicates If the information is available, it is returned as a multi-line
that there are currently no valid newsgroups. response following the 215 response code. The format of the
information depends on the keyword. The information MAY be affected
by the additional argument, but the format MUST NOT be.
If the information is based on newsgroups and the optional wildmat
argument is specified, the response is limited to only the groups (if
any) whose names match the wildmat and for which the information is
available.
Note that an empty list is a possible valid response; for a
newsgroup-based keyword, it indicates that there are no groups
meeting the above criteria.
If the keyword is not recognised, or if an argument is specified and
the keyword does not expect one, a 501 response code MUST BE
returned. If the keyword is recognised but the server does not
maintain the information, a 503 response code MUST BE returned.
The LIST command MUST NOT change the visible state of the server in
any way; that is, the behaviour of subsequent commands MUST NOT be
affected by whether the LIST command was issued or not. For example,
it MUST NOT make groups available that otherwise would not have been.
7.6.1.3 Examples
Example of LIST with the ACTIVE keyword:
[C] LIST ACTIVE
[S] 215 list of newsgroups follows
[S] misc.test 3002322 3000234 y
[S] comp.risks 442001 441099 m
[S] alt.rfc-writers.recovery 4 1 y
[S] tx.natives.recovery 89 56 y
[S] tx.natives.recovery.d 11 9 n
[S] .
Example of LIST with no keyword:
[C] LIST
[S] 215 list of newsgroups follows
[S] misc.test 3002322 3000234 y
[S] comp.risks 442001 441099 m
[S] alt.rfc-writers.recovery 4 1 y
[S] tx.natives.recovery 89 56 y
[S] tx.natives.recovery.d 11 9 n
[S] .
The output is identical to that of the previous example.
Example of LIST on a newsgroup-based keyword with and without
wildmat:
[C] LIST ACTIVE.TIMES
[S] 215 information follows
[S] misc.test 930445408 <creatme@isc.org>
[S] alt.rfc-writers.recovery 930562309 <m@example.com>
[S] tx.natives.recovery 930678923 <sob@academ.com>
[S] .
[C] LIST ACTIVE.TIMES tx.*
[S] 215 information follows
[S] tx.natives.recovery 930678923 <sob@academ.com>
[S] .
Example of LIST returning an error where the keyword is recognized
but the software does not maintain this information:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA
[S] .
[C] LIST XTRA.DATA
[S] 503 Data item not stored
Example of LIST where the keyword is not recognised:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA
[S] .
[C] LIST DISTRIB.PATS
[S] 501 Syntax Error
7.6.2 Standard LIST keywords
This specification defines the following LIST keywords:
+----------------------+----------------------+---------------------+
| Keyword | Definition | Status |
+----------------------+----------------------+---------------------+
| ACTIVE | Section 7.6.3 | Mandatory if the |
| | | READER capability |
| | | is advertised |
| | | |
| ACTIVE.TIMES | Section 7.6.4 | Optional |
| | | |
| DISTRIB.PATS | Section 7.6.5 | Optional |
| | | |
| HEADERS | Section 8.6 | Mandatory if the |
| | | HDR capability is |
| | | advertised |
| | | |
| NEWSGROUPS | Section 7.6.6 | Mandatory if the |
| | | READER capability |
| | | is advertised |
| | | |
| OVERVIEW.FMT | Section 8.4 | Mandatory if the |
| | | OVER capability is |
| | | advertised |
+----------------------+----------------------+---------------------+
Where one of these LIST keywords is supported by a server, it MUST
have the meaning given in the following sub-sections.
7.6.3 LIST ACTIVE
This keyword MUST be supported by servers advertising the READER
capability.
LIST ACTIVE returns a list of valid newsgroups and associated
information. If no wildmat is specified, the server MUST include
every group that the client is permitted to select with the GROUP
(Section 6.1.1) command. Each line of this list consists of four
fields separated from each other by one or more spaces:
o the name of the newsgroup;
o the reported high water mark for the group;
o the reported low water mark for the group;
o the current status of the group on this server.
The reported high and low water marks are as described in the GROUP The reported high and low water marks are as described in the GROUP
command (see Section 6.1.1). command (see Section 6.1.1).
The status field is typically one of: The status field is typically one of:
"y" posting is permitted "y" posting is permitted
"n" posting is not permitted "n" posting is not permitted
"m" postings will be forwarded to the newsgroup moderator "m" postings will be forwarded to the newsgroup moderator
The server SHOULD use these values when these meanings are required The server SHOULD use these values when these meanings are required
and MUST NOT use them with any other meaning. Other values for the and MUST NOT use them with any other meaning. Other values for the
skipping to change at page 53, line 45 skipping to change at page 64, line 32
extension or may be private to the server. A client SHOULD treat an extension or may be private to the server. A client SHOULD treat an
unrecognized status as giving no information. unrecognized status as giving no information.
The status of a newsgroup only indicates how posts to that newsgroup The status of a newsgroup only indicates how posts to that newsgroup
are normally processed and is not necessarily customised to the are normally processed and is not necessarily customised to the
specific client. For example, if the current client is forbidden specific client. For example, if the current client is forbidden
from posting, then this will apply equally to groups with status "y". from posting, then this will apply equally to groups with status "y".
Conversely, a client with special privileges (not defined by this Conversely, a client with special privileges (not defined by this
specification) might be able to post to a group with status "n". specification) might be able to post to a group with status "n".
If the optional wildmat argument is specified, the response is For example:
limited to only the groups (if any) whose names match the wildmat.
If no wildmat is specified, the keyword ACTIVE MAY be omitted without
altering the effect of the command.
7.6.1.3 Examples
Example of LIST ACTIVE returning a list of newsgroups:
[C] LIST ACTIVE [C] LIST ACTIVE
[S] 215 list of newsgroups follows [S] 215 list of newsgroups follows
[S] misc.test 3002322 3000234 y [S] misc.test 3002322 3000234 y
[S] comp.risks 442001 441099 m [S] comp.risks 442001 441099 m
[S] alt.rfc-writers.recovery 4 1 y [S] alt.rfc-writers.recovery 4 1 y
[S] tx.natives.recovery 89 56 y [S] tx.natives.recovery 89 56 y
[S] tx.natives.recovery.d 11 9 n [S] tx.natives.recovery.d 11 9 n
[S] . [S] .
The same output on an implementation that includes leading zeroes: or, on an implementation that includes leading zeroes:
[C] LIST ACTIVE [C] LIST ACTIVE
[S] 215 list of newsgroups follows [S] 215 list of newsgroups follows
[S] misc.test 0003002322 0003000234 y [S] misc.test 0003002322 0003000234 y
[S] comp.risks 0000442001 0000441099 m [S] comp.risks 0000442001 0000441099 m
[S] alt.rfc-writers.recovery 0000000004 0000000001 y [S] alt.rfc-writers.recovery 0000000004 0000000001 y
[S] tx.natives.recovery 0000000089 0000000056 y [S] tx.natives.recovery 0000000089 0000000056 y
[S] tx.natives.recovery.d 0000000011 0000000009 n [S] tx.natives.recovery.d 0000000011 0000000009 n
[S] . [S] .
Example of LIST ACTIVE omitting the second keyword and returning no The information is newsgroup-based and a wildmat MAY be specified, in
newsgroups: which case the response is limited to only the groups (if any) whose
[C] LIST names match the wildmat. For example:
[S] 215 list of newsgroups follows
[S] .
Example of LIST ACTIVE with a wildmat:
[C] LIST ACTIVE *.recovery [C] LIST ACTIVE *.recovery
[S] 215 list of newsgroups follows [S] 215 list of newsgroups follows
[S] alt.rfc-writers.recovery 4 1 y [S] alt.rfc-writers.recovery 4 1 y
[S] tx.natives.recovery 89 56 y [S] tx.natives.recovery 89 56 y
[S] . [S] .
7.6.2 LIST ACTIVE.TIMES 7.6.4 LIST ACTIVE.TIMES
7.6.2.1 Usage
This command is optional.
Syntax
LIST ACTIVE.TIMES [wildmat]
Responses
215 Information follows (multiline)
Parameters
wildmat = groups of interest
7.6.2.2 Description
The active.times list is maintained by some news transfer systems to
contain information about who created a particular newsgroup and
when. Each line of this list consists of three fields separated from
each other by one or more spaces. The first field is the name of the
newsgroup. The second is the time when this group was created on
this news server, measured in seconds since the start of January 1,
1970. The third is plain text intended to describe the entity that
created the newsgroup; it is often a mailbox as defined in RFC 2822
[RFC2822].
The list MAY omit newsgroups for which the information is unavailable
and MAY include groups not available on the server; in particular, it
MAY omit all groups created before the date and time of the oldest
entry. The client MUST NOT assume that the list is complete or that
it matches the list returned by LIST ACTIVE. The NEWGROUPS command
(Section 7.3) may provide a better way to access this information and
the results of the two commands SHOULD be consistent (subject to the
caveats in the description of that command).
If the information is available, it is returned as a multi-line
response following the 215 response code. If the optional wildmat
argument is specified, the response is limited to only the groups (if
any) whose names match the wildmat and for which the information is
available.
Note that an empty list is a possible valid response (whether or not This keyword is optional.
a wildmat is specified) and indicates that there are no groups
meeting the above criteria.
7.6.2.3 Examples The active.times list is maintained by some NNTP servers to contain
information about who created a particular newsgroup and when. Each
line of this list consists of three fields separated from each other
by one or more spaces. The first field is the name of the newsgroup.
The second is the time when this group was created on this news
server, measured in seconds since the start of January 1, 1970. The
third is plain text intended to describe the entity that created the
newsgroup; it is often a mailbox as defined in RFC 2822 [RFC2822].
For example:
Example of LIST ACTIVE.TIMES returning a list of newsgroups:
[C] LIST ACTIVE.TIMES [C] LIST ACTIVE.TIMES
[S] 215 information follows [S] 215 information follows
[S] misc.test 930445408 <creatme@isc.org> [S] misc.test 930445408 <creatme@isc.org>
[S] alt.rfc-writers.recovery 930562309 <m@example.com> [S] alt.rfc-writers.recovery 930562309 <m@example.com>
[S] tx.natives.recovery 930678923 <sob@academ.com> [S] tx.natives.recovery 930678923 <sob@academ.com>
[S] . [S] .
Example of LIST ACTIVE.TIMES returning an error where the command is The list MAY omit newsgroups for which the information is unavailable
recognized but the software does not maintain this information: and MAY include groups not available on the server; in particular, it
[C] LIST ACTIVE.TIMES MAY omit all groups created before the date and time of the oldest
[S] 503 program error, function not performed entry. The client MUST NOT assume that the list is complete or that
it matches the list returned by the LIST ACTIVE (Section 7.6.3)
Example of LIST ACTIVE.TIMES sent to a server that does not recognize command. The NEWGROUPS command (Section 7.3) may provide a better
this command: way to access this information, and the results of the two commands
[C] LIST ACTIVE.TIMES SHOULD be consistent except that, if the latter is invoked with a
[S] 501 Syntax Error date and time earlier than the oldest entry in active.times list, its
result may include extra groups.
7.6.3 LIST DISTRIBUTIONS
7.6.3.1 Usage
This command is optional.
Syntax
LIST DISTRIBUTIONS
Responses
215 Information follows (multiline)
7.6.3.2 Description The information is newsgroup-based and a wildmat MAY be specified, in
which case the response is limited to only the groups (if any) whose
names match the wildmat.
The distributions list is maintained by some news transfer systems to 7.6.5 LIST DISTRIB.PATS
contain information about valid values for the content of the
Distribution header in a news article and about what the various
values mean. Each line of this list consists of two fields separated
from each other by one or more spaces. The first field is a value
and the second is a short explanation of the meaning of that value.
If the information is available, it is returned as a multi-line This keyword is optional.
response following the 215 response code.
7.6.3.3 Examples The distrib.pats list is maintained by some NNTP servers to assist
clients to choose a value for the content of the Distribution header
of a news article being posted. Each line of this list consists of
three fields separated from each other by a colon (":"). The first
field is a weight, the second field is a wildmat (which may be a
simple group name), and the third field is a value for the
Distribution header content. For example:
Example of LIST DISTRIBUTIONS returning a list of distributions: [C] LIST DISTRIB.PATS
[C] LIST DISTRIBUTIONS
[S] 215 information follows [S] 215 information follows
[S] usa United States of America [S] 10:local.*:local
[S] na North America [S] 5:*:world
[S] world All over the World [S] 20:local.here.*:thissite
[S] . [S] .
Example of LIST DISTRIBUTIONS returning an error where the command is
recognized but the software does not maintain this information:
[C] LIST DISTRIBUTIONS
[S] 503 program error, function not performed
Example of LIST DISTRIBUTIONS sent to a server that does not
recognize this command:
[C] LIST DISTRIBUTIONS
[S] 501 Syntax Error
7.6.4 LIST DISTRIB.PATS
7.6.4.1 Usage
This command is optional.
Syntax
LIST DISTRIB.PATS
Responses
215 Information follows (multiline)
7.6.4.2 Description
The distrib.pats list is maintained by some news transfer systems to
choose a value for the content of the Distribution header of a news
article being posted. Each line of this list consists of three
fields separated from each other by a colon (":"). The first field
is a weight, the second field is a wildmat (which may be a simple
group name), and the third field is a value for the Distribution
header content.
The client MAY use this information to construct an appropriate The client MAY use this information to construct an appropriate
Distribution header given the name of a newsgroup. To do so, it Distribution header given the name of a newsgroup. To do so, it
should determine the lines whose second field matches the newsgroup should determine the lines whose second field matches the newsgroup
name, select from among them the line with the highest weight (with 0 name, select from among them the line with the highest weight (with 0
being the lowest), and use the value of the third field to construct being the lowest), and use the value of the third field to construct
the Distribution header. the Distribution header.
If the information is available, it is returned as a multi-line The information is not newsgroup-based and an argument MUST NOT be
response following the 215 response code. specified.
7.6.4.3 Examples
Example of LIST DISTRIB.PATS returning a list of newsgroups:
[C] LIST DISTRIB.PATS
[S] 215 information follows
[S] 10:local.*:local
[S] 5:*:world
[S] 20:local.here.*:thissite
[S] .
Example of LIST DISTRIB.PATS returning an error where the command is
recognized but the software does not maintain this information:
[C] LIST DISTRIB.PATS
[S] 503 program error, function not performed
Example of LIST DISTRIB.PATS sent to a server that does not recognize
this command:
[C] LIST DISTRIB.PATS
[S] 501 Syntax Error
7.6.5 LIST NEWSGROUPS
7.6.5.1 Usage
This command is optional.
Syntax
LIST NEWSGROUPS [wildmat]
Responses
215 Information follows (multiline)
Parameters
wildmat = groups of interest
7.6.5.2 Description
The newsgroups list is maintained by some news transfer systems to
contain the name of each newsgroup that is available on the server
and a short description about the purpose of the group. Each line of
this list consists of two fields separated from each other by one or
more space or TAB characters (usual practice is a single TAB). The
first field is the name of the newsgroup and the second is a short
description of the group.
The list MAY omit newsgroups for which the information is unavailable
and MAY include groups not available on the server. The client MUST
NOT assume that the list is complete or that it matches the list
returned by LIST ACTIVE.
If the information is available, it is returned as a multi-line 7.6.6 LIST NEWSGROUPS
response following the 215 response code. If the optional wildmat
argument is specified, the response is limited to only the groups (if
any) whose names match the wildmat and for which the information is
available.
Note that an empty list is a possible valid response (whether or not This keyword MUST be supported by servers advertising the READER
a wildmat is specified) and indicates that there are no groups capability.
meeting the above criteria.
7.6.5.3 Examples The newsgroups list is maintained by NNTP servers to contain the name
of each newsgroup that is available on the server and a short
description about the purpose of the group. Each line of this list
consists of two fields separated from each other by one or more space
or TAB characters (the usual practice is a single TAB). The first
field is the name of the newsgroup and the second is a short
description of the group. For example:
Example of LIST NEWSGROUPS returning a list of newsgroups:
[C] LIST NEWSGROUPS [C] LIST NEWSGROUPS
[S] 215 information follows [S] 215 information follows
[S] misc.test General Usenet testing [S] misc.test General Usenet testing
[S] alt.rfc-writers.recovery RFC Writers Recovery [S] alt.rfc-writers.recovery RFC Writers Recovery
[S] tx.natives.recovery Texas Natives Recovery [S] tx.natives.recovery Texas Natives Recovery
[S] . [S] .
Example of LIST NEWSGROUPS returning an error where the command is The list MAY omit newsgroups for which the information is unavailable
recognized but the software does not maintain this information: and MAY include groups not available on the server. The client MUST
[C] LIST NEWSGROUPS NOT assume that the list is complete or that it matches the list
[S] 503 program error, function not performed returned by LIST ACTIVE.
Example of LIST NEWSGROUPS sent to a server that does not recognize
this command:
[C] LIST NEWSGROUPS
[S] 501 Syntax error
8. Framework for NNTP extensions
Although NNTP is widely and robustly deployed, some parts of the
Internet community might wish to extend the NNTP service. This
document defines a means whereby an extended NNTP client can query
the server to determine the service extensions that it supports.
It must be emphasized that any extension to the NNTP service should
not be considered lightly. NNTP's strength comes primarily from its
simplicity. Experience with many protocols has shown that:
Protocols with few options tend towards ubiquity, whilst protocols
with many options tend towards obscurity.
This means that each and every extension, regardless of its benefits,
must be carefully scrutinized with respect to its implementation,
deployment, and interoperability costs. In many cases, the cost of
extending the NNTP service will likely outweigh the benefit.
Given this environment, the framework for extensions described in
this document consists of:
o a mechanism for clients to determine a server's available
extensions
o a registry of NNTP service extensions
The LIST EXTENSIONS command is described in this document (see
Section 5.3) and is the mechanism for clients to use to determine
what extensions are available. Except where stated otherwise, the
commands in this document are understood (even if not supported) by
all servers and are not described in the list of features returned by
the LIST EXTENSIONS command.
The IANA shall maintain a registry of NNTP service extensions.
An extension is identified by a unique extension-label, which is a
string of 1 to 12 uppercase US-ASCII letters. The extension-label
will often be the name of a new command that the extension adds.
However this is not a requirement: an extension might not add any new
commands or keywords.
An extension is either a private extension or else it is included in
the IANA registry and is defined in an RFC (in which case it is a
"standard extension" or "registered extension"). Such RFCs either
must be on the standards track or must define an IESG-approved
experimental protocol.
The definition of an extension must include:
o a descriptive name for the extension;
o the extension-label (which is returned by LIST EXTENSIONS to
indicate to the client that the server supports this particular
extension) - the extension-label of a registered extension MUST
NOT begin with "X";
o the syntax, values, and meanings of any arguments following the
extension-label in the output of LIST EXTENSIONS;
o any new NNTP commands associated with the extension - the names of
commands associated with registered extensions MUST NOT begin with
"X";
o the syntax and possible values of arguments associated with the
new NNTP commands;
o the response codes and possible values of arguments for the
responses of the new NNTP commands;
o any new arguments the extension associates with any other
pre-existing NNTP commands;
o how support for the extension affects the behaviour of a server
and NNTP client;
o any increase in the maximum length of commands and initial
response lines over the value specified in this document;
o a specific statement about the effect on pipelining this extension
may have (if any);
o a specific statement about the circumstances when use of this
extension can alter the output from LIST EXTENSIONS;
o the circumstances under which the extension can cause any
pre-existing command to produce a 401, 480, or 483 response;
o whether the extension can be used before or after the MODE READER
command, and what changes (if any) the latter has on the
extension.
A private extension need not be included in the output of LIST
EXTENSIONS. A server MAY provide additional keywords - for new
commands and also for new variants of existing commands - as part of
a private extension. To avoid the risk of a clash with a future
registered extension, the names of private extensions and commands
defined by them SHOULD begin with "X" and MUST NOT be the same as the
name of a registered extension.
If the server provides a registered extension (indicated by listing
it in the output of LIST EXTENSIONS), it MUST implement all of the
commands in the specification of the extension except for those
marked as optional. If it does not implement the extension as
specified, it MUST NOT list the extension in the output of LIST
EXTENSIONS under its registered name; in this case it MAY, but SHOULD
NOT, provide a private extension (not listed, or listed with a
different name) that implements part of the extension or implements
the commands of the extension with a different meaning.
A server MUST NOT send different response codes to basic NNTP
commands documented here or commands documented in registered
extensions in response to the availability or use of a private
extension.
8.1 Initial IANA registry
The IANA's initial registry of NNTP service extensions consists of
these entries:
+-------------------------+--------------+--------------------------+
| Extension | Label | Added behaviour |
+-------------------------+--------------+--------------------------+
| Specific article | LISTGROUP | Defined in this document |
| numbers | | |
| | | |
| Overview support | OVER | Defined in this document |
| | | |
| Batched header | HDR | Defined in this document |
| retrieval | | |
+-------------------------+--------------+--------------------------+
8.2 Standard extensions
N.B. while these extensions are standard extensions, the term
includes all extensions in the IANA registry, not just these three.
Each of the following sections describes an extension that a server
MAY provide. If the server provides the extension, it MUST include
the appropriate extension label in the response to LIST EXTENSIONS.
If it does not provide it, it MUST NOT include the appropriate
extension label. The descriptions of facilities in each section are
written as if the extension is provided. If it is not provided, the
entire section should be ignored.
The formal definitions of these extensions are provided in Appendix
D.
8.3 The LISTGROUP extension
This extension provides one command and has the extension label
LISTGROUP.
8.3.1 LISTGROUP
8.3.1.1 Usage
Syntax
LISTGROUP [group]
Responses
211 number low high group Article numbers follow (multiline)
411 No such newsgroup
412 No newsgroup selected [1]
Parameters
group = name of newsgroup
number = estimated number of articles in the group
low = reported low water mark
high = reported high water mark
[1] The 412 response can only occur if no group has been specified.
8.3.1.2 Description
The LISTGROUP command is used to get a listing of all the article
numbers in a particular newsgroup. As a side effect, it also selects
the group in the same way as the GROUP command (see Section 6.1.1).
The optional argument is the name of the newsgroup to be selected
(e.g. "news.software.misc"). A list of valid newsgroups may be
obtained from the LIST ACTIVE command. If no group is specified, the
current selected newsgroup is used.
On success, the list of article numbers is returned as a multi-line
response following the 211 response code (the arguments on the
initial response line are the same as for the GROUP command. The
list contains one number per line, is in numerical order, and lists
precisely those articles that exist in the group.
When a valid group is selected by means of this command, the current
selected newsgroup MUST be set to that group and the current article
number MUST be set to the first article in the group. If an empty
newsgroup is selected, the current article pointer is made invalid.
If an invalid group is specified, the current selected newsgroup and
current article number MUST NOT be changed.
The LISTGROUP command MAY be used by a client as a replacement for
the GROUP command in establishing a valid current selected newsgroup
and current article number.
If the group specified is not available on the server, a 411 response
MUST be returned. If no group is specified and the current selected
newsgroup is invalid, a 412 response MUST be returned.
8.3.1.3 Examples
Example of LISTGROUP on an empty group: The information is newsgroup-based and a wildmat MAY be specified, in
which case the response is limited to only the groups (if any) whose
names match the wildmat.
[C] LISTGROUP example.empty.newsgroup 8. Article field access commands
[S] 211 0 0 0 example.empty.newsgroup list follows
[S] .
Example of LISTGROUP on a valid current selected newsgroup: This section lists commands that may be used to access specific
[C] GROUP misc.test article fields; that is, headers of articles and metadata about
[S] 211 2000 3000234 3002322 misc.test articles. These commands typically fetch data from an "overview
[C] LISTGROUP database", which is a database of headers extracted from incoming
[S] 211 2000 3000234 3002322 misc.test list follows articles plus metadata determined as the article arrives. Only
[S] 3000234 certain fields are included in the database.
[S] 3000237
[S] 3000238
[S] 3000239
[S] 3002322
[S] .
Example of LISTGROUP failing because no group has been selected: This section is based on the Overview/NOV database [ROBE1995]
[Assumes current selected newsgroup is invalid.] developed by Geoff Collyer.
[C] LISTGROUP
[S] 412 no current group
[C] GROUP example.is.sob.bradner.or.barber
[S] 411 no such group
[C] LISTGROUP
[S] 412 no current group
8.4 Article metadata 8.1 Article metadata
The OVER and HDR extensions refer to the concept of "article Article "metadata" is data about articles that does not occur within
metadata". This is data about articles that does not occur within
the article itself. Each metadata item has a name which MUST begin the article itself. Each metadata item has a name which MUST begin
with a colon (and which MUST NOT contain a colon elsewhere within with a colon (and which MUST NOT contain a colon elsewhere within
it). As with header names, metadata item names are not it). As with header names, metadata item names are not
case-sensitive. case-sensitive.
When generating a metadata item, the server MUST compute it for When generating a metadata item, the server MUST compute it for
itself and MUST NOT trust any related value provided in the article. itself and MUST NOT trust any related value provided in the article.
(In particular, a Lines or Bytes header in the article MUST NOT be (In particular, a Lines or Bytes header in the article MUST NOT be
assumed to specify the correct number of lines or bytes in the assumed to specify the correct number of lines or bytes in the
article.) If the server has access to several non-identical copies of article.) If the server has access to several non-identical copies of
an article, the value returned MUST be correct for any copy of that an article, the value returned MUST be correct for any copy of that
article retrieved during the same session. article retrieved during the same session.
This specification defines two metadata items: ":bytes" and ":lines". This specification defines two metadata items: ":bytes" and ":lines".
Other metadata items may be defined by extensions. The names of Other metadata items may be defined by extensions. The names of
metadata items defined by registered extensions MUST NOT begin with metadata items defined by registered extensions MUST NOT begin with
":x-". To avoid the risk of a clash with a future registered ":x-". To avoid the risk of a clash with a future registered
extension, the names of metadata items defined by private extensions extension, the names of metadata items defined by private extensions
SHOULD begin with ":x-". SHOULD begin with ":x-".
8.4.1 The :bytes metadata item 8.1.1 The :bytes metadata item
The :bytes metadata item for an article is a decimal integer. It The :bytes metadata item for an article is a decimal integer. It
SHOULD equal the number of octets in the entire article - headers, SHOULD equal the number of octets in the entire article - headers,
body, and separating empty line (counting a CRLF pair as two octets, body, and separating empty line (counting a CRLF pair as two octets,
and excluding both the "." CRLF terminating the response and any "." and excluding both the "." CRLF terminating the response and any "."
added for "byte-stuffing" purposes). added for "byte-stuffing" purposes).
Note to client implementers: some existing servers return a value Note to client implementers: some existing servers return a value
different to that above. The commonest reasons for this are: different to that above. The commonest reasons for this are:
o counting a CRLF pair as one octet; o counting a CRLF pair as one octet;
o including the "." character used for byte-stuffing in the number; o including the "." character used for byte-stuffing in the number;
o including the terminating "." CRLF in the number; o including the terminating "." CRLF in the number;
o using one copy of an article for counting the octets but then o using one copy of an article for counting the octets but then
returning another one that differs in some (permitted) manner. returning another one that differs in some (permitted) manner.
Implementations should be prepared for such variation and MUST NOT Implementations should be prepared for such variation and MUST NOT
rely on the value being accurate. rely on the value being accurate.
8.4.2 The :lines metadata item 8.1.2 The :lines metadata item
The :lines metadata item for an article is a decimal integer. It The :lines metadata item for an article is a decimal integer. It
MUST equal the number of lines in the article body (excluding the MUST equal the number of lines in the article body (excluding the
empty line separating headers and body); equivalently, it is two less empty line separating headers and body); equivalently, it is two less
than the number of CRLF pairs that the BODY command would return for than the number of CRLF pairs that the BODY command would return for
that article (the extra two are those following the response code and that article (the extra two are those following the response code and
the termination octet). the termination octet).
8.5 The OVER extension 8.2 Database consistency
This extension provides two commands, OVER and LIST OVERVIEW.FMT.
The label for this extension is OVER.
The OVER extension provides access to the "overview database", which
is a database of headers extracted from incoming articles. Only
certain headers are included in the database. The database also
includes some article metadata.
The information stored in the database may change over time. If the The information stored in the overview database may change over time.
database records the content or absence of a given field (that is, a If the database records the content or absence of a given field (that
header or metadata item) for all articles, it is said to be is, a header or metadata item) for all articles, it is said to be
"consistent" for that field. If it records the content of a header "consistent" for that field. If it records the content of a header
for some articles but not for others that nevertheless included that for some articles but not for others that nevertheless included that
header, or records a metadata item for some articles but not others header, or records a metadata item for some articles but not others
to which that item applies, it is said to be "inconsistent" for that to which that item applies, it is said to be "inconsistent" for that
field. field.
The LIST OVERVIEW.FMT command SHOULD list all the fields for which The LIST OVERVIEW.FMT command SHOULD list all the fields for which
the database is consistent at that moment. It MAY omit such fields the database is consistent at that moment. It MAY omit such fields
(for example if it is not known whether the database is consistent or (for example if it is not known whether the database is consistent or
inconsistent). It MUST NOT include fields for which the database is inconsistent). It MUST NOT include fields for which the database is
skipping to change at page 66, line 21 skipping to change at page 69, line 49
These rules assume the fields being stored in the database remain These rules assume the fields being stored in the database remain
constant for long periods of time, with the database therefore being constant for long periods of time, with the database therefore being
consistent. When the set of fields to be stored is changed, it will consistent. When the set of fields to be stored is changed, it will
be inconsistent until either the database is rebuilt or the only be inconsistent until either the database is rebuilt or the only
articles remaining are those received since the change. Therefore articles remaining are those received since the change. Therefore
the output from LIST OVERVIEW.FMT needs to be altered twice: before the output from LIST OVERVIEW.FMT needs to be altered twice: before
any fields stop being stored, they MUST be removed from the output, any fields stop being stored, they MUST be removed from the output,
then when the database is once more known to be consistent, the new then when the database is once more known to be consistent, the new
fields SHOULD be added to the output. fields SHOULD be added to the output.
Support for the message-id form of the OVER command is optional. If If the HDR command uses the overview database rather than taking
an implementation supports this form, it MUST use the argument information directly from the articles, the same issues of
"MSGID" following the extension label in the output of LIST consistency and inconsistency apply and the and the LIST HEADERS
EXTENSIONS; if not, it MUST NOT use any argument. command SHOULD take the same approach as the LIST OVERVIEW.FMT
command in resolving them.
This extension is based on the Overview/NOV database [ROBE1995]
developed by Geoff Collyer.
8.5.1 OVER 8.3 OVER
8.5.1.1 Usage 8.3.1 Usage
Indicating capability: OVER
Syntax Syntax
OVER message-id OVER message-id
OVER range OVER range
OVER OVER
Responses Responses
First form (message-id specified) First form (message-id specified)
224 Overview information follows (multiline) 224 Overview information follows (multiline)
430 No article with that message-id 430 No article with that message-id
Second form (range specified) Second form (range specified)
224 Overview information follows (multiline) 224 Overview information follows (multiline)
412 No newsgroup selected 412 No newsgroup selected
423 No articles in that range 423 No articles in that range
Third form (current article number used) Third form (current article number used)
224 Overview information follows (multiline) 224 Overview information follows (multiline)
412 No newsgroup selected 412 No newsgroup selected
420 Current article number is invalid 420 Current article number is invalid
Parameters Parameters
range = number(s) of articles range = number(s) of articles
message-id = message-id of article message-id = message-id of article
8.5.1.2 Description 8.3.2 Description
The OVER command returns the contents of the headers and metadata in The OVER command returns the contents of all the fields in the
the database for an article specified by message-id, or from a database for an article specified by message-id, or from a specified
specified article or range of articles in the current selected article or range of articles in the current selected newsgroup.
newsgroup.
The message-id argument indicates a specific article. The range The message-id argument indicates a specific article. The range
argument may be any of the following: argument may be any of the following:
o an article number o an article number
o an article number followed by a dash to indicate all following o an article number followed by a dash to indicate all following
o an article number followed by a dash followed by another article o an article number followed by a dash followed by another article
number number
If neither is specified, the current article number is used. Support If neither is specified, the current article number is used.
for the first (message-id) form is optional. If it is not supported,
the generic response code 503 MUST be returned. Support for the first (message-id) form is optional. If is is
supported, the OVER capability line MUST include the argument
"MSGID". Otherwise, the capability line MUST NOT include this
argument, and the OVER command MUST return the the generic response
code 503 when this form is used.
If the information is available, it is returned as a multi-line If the information is available, it is returned as a multi-line
response following the 224 response code and contains one line per response following the 224 response code and contains one line per
article, sorted in numerical order of article number (note that article, sorted in numerical order of article number (note that
unless the argument is a range including a dash, there will only be unless the argument is a range including a dash, there will only be
one line but it will still be in multi-line format). Each line one line but it will still be in multi-line format). Each line
consists of a number of fields separated by a TAB. A field may be consists of a number of fields separated by a TAB. A field may be
empty (in which case there will be two adjacent TABs), and a sequence empty (in which case there will be two adjacent TABs), and a sequence
of trailing TABs may be omitted. of trailing TABs may be omitted.
skipping to change at page 68, line 45 skipping to change at page 72, line 25
exist. exist.
If the argument is a message-id and no such article exists, a 430 If the argument is a message-id and no such article exists, a 430
response MUST be returned. If the argument is a range or is omitted response MUST be returned. If the argument is a range or is omitted
and the current selected newsgroup is invalid, a 412 response MUST be and the current selected newsgroup is invalid, a 412 response MUST be
returned. If the argument is a range and no articles in that number returned. If the argument is a range and no articles in that number
range exist in the current selected newsgroup, a 423 response MUST be range exist in the current selected newsgroup, a 423 response MUST be
returned. If the argument is omitted and the current article number returned. If the argument is omitted and the current article number
is invalid, a 420 response MUST be returned. is invalid, a 420 response MUST be returned.
8.5.1.3 Examples 8.3.3 Examples
In the first three examples, TAB has been replaced by vertical bar In the first three examples, TAB has been replaced by vertical bar
and some lines have been folded for readability. and some lines have been folded for readability.
Example of a successful retrieval of overview information for an Example of a successful retrieval of overview information for an
article (using no article number): article (using no article number):
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] OVER [C] OVER
[S] 224 Overview information follows [S] 224 Overview information follows
[S] 300234|I am just a test article|"Demo User" [S] 300234|I am just a test article|"Demo User"
<nobody@example.com>|6 Oct 1998 04:38:40 -0500| <nobody@example.com>|6 Oct 1998 04:38:40 -0500|
<45223423@example.com>|<45454@example.net>|1234| <45223423@example.com>|<45454@example.net>|1234|
17|Xref: news.example.com misc.test:3000363 17|Xref: news.example.com misc.test:3000363
[S] . [S] .
skipping to change at page 69, line 17 skipping to change at page 72, line 44
[C] OVER [C] OVER
[S] 224 Overview information follows [S] 224 Overview information follows
[S] 300234|I am just a test article|"Demo User" [S] 300234|I am just a test article|"Demo User"
<nobody@example.com>|6 Oct 1998 04:38:40 -0500| <nobody@example.com>|6 Oct 1998 04:38:40 -0500|
<45223423@example.com>|<45454@example.net>|1234| <45223423@example.com>|<45454@example.net>|1234|
17|Xref: news.example.com misc.test:3000363 17|Xref: news.example.com misc.test:3000363
[S] . [S] .
Example of a successful retrieval of overview information for an Example of a successful retrieval of overview information for an
article by message-id: article by message-id:
[C] LIST EXTENSIONS [C] CAPABILITIES
[S] 202 extensions supported: [S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] OVER MSGID [S] OVER MSGID
[S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
[S] . [S] .
[C] OVER <45223423@example.com> [C] OVER <45223423@example.com>
[S] 224 Overview information follows [S] 224 Overview information follows
[S] 0|I am just a test article|"Demo User" [S] 0|I am just a test article|"Demo User"
<nobody@example.com>|6 Oct 1998 04:38:40 -0500| <nobody@example.com>|6 Oct 1998 04:38:40 -0500|
<45223423@example.com>|<45454@example.net>|1234| <45223423@example.com>|<45454@example.net>|1234|
17|Xref: news.example.com misc.test:3000363 17|Xref: news.example.com misc.test:3000363
[S] . [S] .
Note that the article number has been replaced by "0". Note that the article number has been replaced by "0".
Example of the same commands on a system that does not implement Example of the same commands on a system that does not implement
retrieval by message-id: retrieval by message-id:
[C] LIST EXTENSIONS [C] CAPABILITIES
[S] 202 extensions supported: [S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] OVER [S] OVER
[S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
[S] . [S] .
[C] OVER <45223423@example.com> [C] OVER <45223423@example.com>
[S] 503 Overview by message-id unsupported [S] 503 Overview by message-id unsupported
Example of a successful retrieval of overview information for a range Example of a successful retrieval of overview information for a range
of articles: of articles:
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] OVER 3000234-3000240 [C] OVER 3000234-3000240
[S] 224 Overview information follows [S] 224 Overview information follows
skipping to change at page 70, line 31 skipping to change at page 74, line 16
[C] OVER [C] OVER
[S] 412 No newsgroup selected [S] 412 No newsgroup selected
Example of an attempt to retrieve information when the current Example of an attempt to retrieve information when the current
selected newsgroup is empty: selected newsgroup is empty:
[C] GROUP example.empty.newsgroup [C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup
[C] OVER [C] OVER
[S] 420 No current article selected [S] 420 No current article selected
8.5.2 LIST OVERVIEW.FMT 8.4 LIST OVERVIEW.FMT
8.5.2.1 Usage 8.4.1 Usage
This command is optional. Indicating capability: OVER
Syntax Syntax
LIST OVERVIEW.FMT LIST OVERVIEW.FMT
Responses Responses
215 Information follows (multiline) 215 Information follows (multiline)
8.5.2.2 Description 8.4.2 Description
The LIST OVERVIEW.FMT command returns a description of the fields in See Section 7.6.1 for general requirements of the LIST command.
the database for which it is consistent (as described above).
If the information is available, it is returned as a multi-line The LIST OVERVIEW.FMT command returns a description of the fields in
response following the 215 response code. The information contains the database for which it is consistent (as described above). The
one line per field in the order they are returned by the OVER information is returned as a multi-line response following the 215
command; the first 7 lines MUST (except for the case of letters) be response code. The information contains one line per field in the
exactly: order they are returned by the OVER command; the first 7 lines MUST
(except for the case of letters) be exactly:
Subject: Subject:
From: From:
Date: Date:
Message-ID: Message-ID:
References: References:
:bytes :bytes
:lines :lines
except that, for compatibility with existing implementations, the except that, for compatibility with existing implementations, the
skipping to change at page 71, line 34 skipping to change at page 75, line 18
There are no leading or trailing spaces in the output. There are no leading or trailing spaces in the output.
Note that the 7 fixed lines describe the 2nd to 8th fields of the Note that the 7 fixed lines describe the 2nd to 8th fields of the
OVER output. The "full" suffix (which may use either uppercase, OVER output. The "full" suffix (which may use either uppercase,
lowercase, or a mix) is a reminder that the corresponding fields lowercase, or a mix) is a reminder that the corresponding fields
include the header name. include the header name.
This command MAY generate different results if used more than once in This command MAY generate different results if used more than once in
a session. a session.
8.5.2.3 Examples 8.4.3 Examples
Example of LIST OVERVIEW.FMT output corresponding to the example OVER Example of LIST OVERVIEW.FMT output corresponding to the example OVER
output above, using the preferred format: output above, using the preferred format:
[C] LIST OVERVIEW.FMT [C] LIST OVERVIEW.FMT
[S] 215 Order of fields in overview database. [S] 215 Order of fields in overview database.
[S] Subject: [S] Subject:
[S] From: [S] From:
[S] Date: [S] Date:
[S] Message-ID: [S] Message-ID:
[S] References: [S] References:
skipping to change at page 72, line 18 skipping to change at page 75, line 50
[S] From: [S] From:
[S] Date: [S] Date:
[S] Message-ID: [S] Message-ID:
[S] References: [S] References:
[S] Bytes: [S] Bytes:
[S] Lines: [S] Lines:
[S] Xref:FULL [S] Xref:FULL
[S] Distribution:FULL [S] Distribution:FULL
[S] . [S] .
Example of LIST OVERVIEW.FMT returning an error where the command is 8.5 HDR
recognized but the software does not maintain this information:
[C] LIST OVERVIEW.FMT
[S] 503 overview.fmt not available
8.6 The HDR extension
This extension provides two new commands: HDR and LIST HEADERS. The
label for this extension is HDR.
The HDR extension provides access to specific headers and metadata
items (collectively "fields") of articles or groups of articles. In
the case of headers, an implementation MAY restrict the use of this
extension to a specific list of headers or MAY allow it to be used
with any header; it may behave differently when the HDR command is
used with a message-id argument and when it is used with a range or
no argument.
The HDR command may take information from a database rather than
directly from the articles. If so, the same issues of consistency
and inconsistency apply as with the OVER extension (Section 8.5) and
the LIST HEADERS command SHOULD take the same approach as the LIST
OVERVIEW.FMT command in resolving them.
8.6.1 HDR
8.6.1.1 Usage 8.5.1 Usage
Indicating capability: HDR
Syntax Syntax
HDR header message-id HDR field message-id
HDR header range HDR field range
HDR header HDR field
Responses Responses
First form (message-id specified) First form (message-id specified)
225 Headers follow (multiline) 225 Headers follow (multiline)
430 No article with that message-id 430 No article with that message-id
Second form (range specified) Second form (range specified)
225 Headers follow (multiline) 225 Headers follow (multiline)
412 No newsgroup selected 412 No newsgroup selected
423 No articles in that range 423 No articles in that range
Third form (current article number used) Third form (current article number used)
225 Headers follow (multiline) 225 Headers follow (multiline)
412 No newsgroup selected 412 No newsgroup selected
420 Current article number is invalid 420 Current article number is invalid
Parameters Parameters
header = name of header, without the colon field = name of field
range = number(s) of articles range = number(s) of articles
message-id = message-id of article message-id = message-id of article
8.6.1.2 Description 8.5.2 Description
The HDR command retrieves specific headers from an article specified The HDR command provides access to specific fields from an article
by message-id, or from a specified article or range of articles in specified by message-id, or from a specified article or range of
the current selected newsgroup. It can also return certain metadata articles in the current selected newsgroup. It MAY take the
about the article or articles. information directly from the articles or from the overview database.
In the case of headers, an implementation MAY restrict the use of
this command to a specific list of headers or MAY allow it to be used
with any header; it may behave differently when it is used with a
message-id argument and when it is used with a range or no argument.
The required header argument is the name of a header (e.g. The required field argument is the name of a header with the colon
"subject") in an article, or the name of a metadata item, and is omitted (e.g. "subject"), or the name of a metadata item including
case-insensitive. Names of metadata items always begin with a colon. the leading colon (e.g. ":bytes"), and is case-insensitive.
Except where stated otherwise, metadata items are treated as if they
were header contents, and references to headers in this description
apply equally to metadata items.
The message-id argument indicates a specific article. The range The message-id argument indicates a specific article. The range
argument may be any of the following: argument may be any of the following:
o an article number o an article number
o an article number followed by a dash to indicate all following o an article number followed by a dash to indicate all following
o an article number followed by a dash followed by another article o an article number followed by a dash followed by another article
number number
If neither is specified, the current article number is used. If neither is specified, the current article number is used.
If the information is available, it is returned as a multi-line If the information is available, it is returned as a multi-line
response following the 225 response code and contains one line for response following the 225 response code and contains one line for
each article in the range that exists (note that unless the argument each article in the range that exists (note that unless the argument
is a range including a dash, there will be at most one line but it is a range including a dash, there will be at most one line but it
will still be in multi-line format). The line consists of the will still be in multi-line format). The line consists of the
article number, a space, and then the contents of the header or article number, a space, and then the contents of the field. In the
metadata item. In the case of a header, the header name, colon, and case of a header, the header name, colon, and the first space after
the first space after the colon are all omitted. the colon are all omitted.
If the article is specified by message-id (the first form of the If the article is specified by message-id (the first form of the
command), the article number MUST be replaced with zero, except that command), the article number MUST be replaced with zero, except that
if there is a current selected group and the article is present in if there is a current selected group and the article is present in
that group, the server MAY use that article number (see the ARTICLE that group, the server MAY use that article number (see the ARTICLE
command (Section 6.2.1) and STAT examples (Section 6.2.4.3) for more command (Section 6.2.1) and STAT examples (Section 6.2.4.3) for more
details). In the other two forms of the command, the article number details). In the other two forms of the command, the article number
MUST be returned. MUST be returned.
Header contents are modified as follows: all CRLF pairs are removed, Header contents are modified as follows: all CRLF pairs are removed,
and then each TAB is replaced with a single space (note that this is and then each TAB is replaced with a single space (note that this is
the same transformation as is performed by the OVER extension the same transformation as is performed by the OVER command
(Section 8.5.1.2), and the same comment concerning NUL, CR, and LF (Section 8.3.2), and the same comment concerning NUL, CR, and LF
applies). applies).
The header content is in all cases taken from the article. This Note the distinction between headers and metadata appearing to have
means that, for example, a request for the header "Lines" returns the the same meaning. Headers are always taken unchanged from the
contents of the "Lines" header of the specified articles, if any, not article; metadata are always calculated. For example, a request for
the line count metadata or any other server-generated value. If the "Lines" returns the contents of the "Lines" header of the specified
header occurs in a given article multiple times, only the content of articles, if any, no matter whether or not they accurately state the
the first occurrence is returned by HDR. number of lines, while a request for ":lines" returns the line count
metadata, which is always the actual number of lines irrespective of
what any header may state.
If the requested header is not present in the article or if it is If the requested header is not present in the article or if it is
present but empty, a line for that article is included in the output present but empty, a line for that article is included in the output
but the header content portion of the line is empty (the space after but the header content portion of the line is empty (the space after
the article number MAY be retained or omitted). If any article the article number MAY be retained or omitted). If the header occurs
number in the provided range does not exist in the group, no line for in a given article more than once, only the content of the first
that article number is included in the output. occurrence is returned by HDR. If any article number in the provided
range does not exist in the group, no line for that article number is
included in the output.
If the second argument is a message-id and no such article exists, a If the second argument is a message-id and no such article exists, a
430 response MUST be returned. If the second argument is a range or 430 response MUST be returned. If the second argument is a range or
is omitted and the current selected newsgroup is invalid, a 412 is omitted and the current selected newsgroup is invalid, a 412
response MUST be returned. If the second argument is a range and no response MUST be returned. If the second argument is a range and no
articles in that number range exist in the current selected articles in that number range exist in the current selected
newsgroup, a 423 response MUST be returned. If the second argument newsgroup, a 423 response MUST be returned. If the second argument
is omitted and the current article number is invalid, a 420 response is omitted and the current article number is invalid, a 420 response
MUST be returned. MUST be returned.
A server MAY only allow HDR commands for a limited set of headers and A server MAY only allow HDR commands for a limited set of fields; it
metadata items; it may behave differently in this respect for the may behave differently in this respect for the first (message-id)
first (message-id) form than for the other forms. If so, it MUST form than for the other forms. If so, it MUST respond with the
respond with the generic 503 response to attempts to request other generic 503 response to attempts to request other fields, rather than
headers, rather than returning erroneous results such as a successful returning erroneous results such as a successful empty response.
empty response.
If HDR uses a separate database and it is inconsistent for the If HDR uses the overview database and it is inconsistent for the
requested header or metadata item, the server MAY return what results requested field, the server MAY return what results it can or it MAY
it can or it MAY respond with the generic 503 response; in the latter respond with the generic 503 response; in the latter case, the field
case, the field MUST NOT appear in the output from LIST HEADERS. MUST NOT appear in the output from LIST HEADERS.
8.6.1.3 Examples 8.5.3 Examples
Example of a successful retrieval of subject lines from a range of Example of a successful retrieval of subject lines from a range of
articles (3000235 has no Subject header, and 3000236 is missing): articles (3000235 has no Subject header, and 3000236 is missing):
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] HDR Subject 3000234-300238 [C] HDR Subject 3000234-300238
[S] 225 Headers follow [S] 225 Headers follow
[S] 3000234 I am just a test article [S] 3000234 I am just a test article
[S] 3000235 [S] 3000235
[S] 3000237 Re: I am just a test article [S] 3000237 Re: I am just a test article
skipping to change at page 76, line 24 skipping to change at page 79, line 37
[C] HDR subject 1- [C] HDR subject 1-
[S] 423 No articles in that range [S] 423 No articles in that range
Example of an unsuccessful retrieval of headers because the server Example of an unsuccessful retrieval of headers because the server
does not allow HDR commands for that header: does not allow HDR commands for that header:
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] HDR Content-Type 3000234-300238 [C] HDR Content-Type 3000234-300238
[S] 503 HDR not permitted on Content-Type [S] 503 HDR not permitted on Content-Type
8.6.2 LIST HEADERS 8.6 LIST HEADERS
8.6.2.1 Usage 8.6.1 Usage
Indicating capability: HDR
Syntax Syntax
LIST HEADERS [MSGID|RANGE] LIST HEADERS [MSGID|RANGE]
Responses Responses
215 Header and metadata list follows (multiline) 215 Field list follows (multiline)
Parameters Parameters
MSGID = requests list for access by message-id MSGID = requests list for access by message-id
RANGE = requests list for access by range RANGE = requests list for access by range
8.6.2.2 Description 8.6.2 Description
The LIST HEADERS command returns a list of headers and metadata items See Section 7.6.1 for general requirements of the LIST command.
that may be retrieved using the HDR command.
The LIST HEADERS command returns a list of fields that may be
retrieved using the HDR command.
The information is returned as a multi-line response following the The information is returned as a multi-line response following the
215 response code and contains one line for each header or metadata 215 response code and contains one line for each field name
item name (excluding the colon in the former case). If the (excluding the trailing colon for headers and including the leading
implementation allows any header to be retrieved, it MUST NOT include colon for metadata items). If the implementation allows any header
any header names in the list but MUST include the special entry ":" to be retrieved, it MUST NOT include any header names in the list but
(a single colon on its own); it MUST still list any metadata items MUST include the special entry ":" (a single colon on its own); it
that are available. The order of items in the list is not MUST still explicitly list any metadata items that are available.
significant; the server need not even consistently return the same The order of items in the list is not significant; the server need
order. The list MAY be empty (though in this circumstance there is not even consistently return the same order. The list MAY be empty
little point in providing the extension). (though in this circumstance there is little point in providing the
HDR command).
An implementation that also supports the OVER extension SHOULD at An implementation that also supports the OVER command SHOULD at least
least permit all the headers and metadata items listed in the output permit all the headers and metadata items listed in the output from
from the LIST OVERVIEW.FMT command. the LIST OVERVIEW.FMT command.
If the server treats the first form of the HDR command (message-id If the server treats the first form of the HDR command (message-id
specified) differently to the other two forms (range specified or specified) differently to the other two forms (range specified or
current article number used) in respect of which headers or metadata current article number used) in respect of which headers or metadata
items are available, then: items are available, then:
o if the MSGID argument is specified, the results MUST be those o if the MSGID argument is specified, the results MUST be those
available for the first form of the HDR command; available for the first form of the HDR command;
o if the RANGE argument is specified, the results MUST be those o if the RANGE argument is specified, the results MUST be those
available for the second and third forms of the HDR command; available for the second and third forms of the HDR command;
o if no argument is specified, the results MUST be those available o if no argument is specified, the results MUST be those available
in all forms of the HDR command (that is, it MUST only list those in all forms of the HDR command (that is, it MUST only list those
items listed in both the previous cases). items listed in both the previous cases).
If the server does not treat the various forms differently, then it If the server does not treat the various forms differently, then it
MUST always produce the same results and ignore any argument. MUST always produce the same results and ignore any argument.
8.6.2.3 Examples 8.6.3 Examples
Example of an implementation providing access to only a few headers: Example of an implementation providing access to only a few headers:
[C] LIST HEADERS [C] LIST HEADERS
[S] 215 headers supported: [S] 215 headers supported:
[S] Subject [S] Subject
[S] Message-ID [S] Message-ID
[S] Xref [S] Xref
[S] . [S] .
Example of an implementation providing access to the same fields as Example of an implementation providing access to the same fields as
the first example in Section 8.5.2.3: the first example in Section 8.4.3:
[C] LIST EXTENSIONS [C] CAPABILITIES
[S] 202 extensions supported: [S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] OVER [S] OVER
[S] HDR [S] HDR
[S] LIST ACTIVE NEWSGROUPS HEADERS OVERVIEW.FMT
[S] . [S] .
[C] LIST HEADERS [C] LIST HEADERS
[S] 215 headers and metadata items supported: [S] 215 headers and metadata items supported:
[S] Date [S] Date
[S] Distribution [S] Distribution
[S] From [S] From
[S] Message-ID [S] Message-ID
[S] References [S] References
[S] Subject [S] Subject
[S] Xref [S] Xref
skipping to change at page 79, line 14 skipping to change at page 83, line 14
9. Augmented BNF Syntax for NNTP 9. Augmented BNF Syntax for NNTP
Each of the following sections describes the syntax of a major Each of the following sections describes the syntax of a major
element of NNTP. This syntax extends and refines the descriptions element of NNTP. This syntax extends and refines the descriptions
elsewhere in this specification, and should be given precedence when elsewhere in this specification, and should be given precedence when
resolving apparent conflicts. Note that ABNF [RFC2234] strings are resolving apparent conflicts. Note that ABNF [RFC2234] strings are
case-insensitive. Non-terminals used in several places are defined case-insensitive. Non-terminals used in several places are defined
in a separate section at the end. in a separate section at the end.
The non-terminals "command-line", "command-continuation", and The non-terminals <command-line>, <command-continuation>, and
"response" between them specify the text that flows between client <response> between them specify the text that flows between client
and server. For each command, the sequence is: and server. For each command, the sequence is:
o the client sends an instance of "command-line"; o the client sends an instance of <command-line>;
o the server sends an instance of "response"; o if the client is one that immediately streams data [1], it sends
an instance of <command-datastream>;
o the server sends an instance of <response>;
o while the latest response is one that indicates more data is o while the latest response is one that indicates more data is
required (in general, a 3xx response): required (in general, a 3xx response):
* the client sends an instance of "command-continuation"; * the client sends an instance of <command-continuation>;
* the server sends an instance of "response". * the server sends an instance of <response>.
[1] There are no commands in this specification that immediately
stream data, but this non-terminal is defined for the convenience of
extensions.
9.1 Commands 9.1 Commands
This syntax defines the non-terminal "command-line", which represents This syntax defines the non-terminal <command-line>, which represents
what is sent from the client to the server. what is sent from the client to the server.
command-line = command EOL command-line = command EOL
command = article-command / command = X-command
X-command = keyword *(WS token)
command =/ article-command /
body-command / body-command /
capabilities-command /
date-command / date-command /
group-command / group-command /
hdr-command / hdr-command /
head-command / head-command /
help-command / help-command /
ihave-command / ihave-command /
last-command / last-command /
list-active-command / list-command /
list-active-times-command /
list-distrib-pats-command /
list-distributions-command /
list-extensions-command /
list-headers-command /
list-newsgroups-command /
list-overview-fmt-command /
listgroup-command / listgroup-command /
mode-reader-command / mode-reader-command /
newgroups-command / newgroups-command /
newnews-command / newnews-command /
next-command / next-command /
over-command / over-command /
post-command / post-command /
quit-command / quit-command /
stat-command / stat-command
x-command
article-command = "ARTICLE" [article-ref] article-command = "ARTICLE" [WS article-ref]
body-command = "BODY" [article-ref] body-command = "BODY" [WS article-ref]
capabilities-command = "CAPABILITIES" [WS keyword]
date-command = "DATE" date-command = "DATE"
group-command = "GROUP" WS newsgroup-name group-command = "GROUP" WS newsgroup-name
hdr-command = "HDR" WS header-meta-name [range-ref] hdr-command = "HDR" WS header-meta-name [WS range-ref]
head-command = "HEAD" [article-ref] head-command = "HEAD" [WS article-ref]
help-command = "HELP" help-command = "HELP"
ihave-command = "IHAVE" WS message-id ihave-command = "IHAVE" WS message-id
last-command = "LAST" last-command = "LAST"
list-active-command = "LIST" [WS "ACTIVE" [WS wildmat]] list-command = "LIST" [WS list-arguments]
list-active-times-command = "LIST" WS "ACTIVE.TIMES" [WS wildmat]
list-distrib-pats-command = "LIST" WS "DISTRIB.PATS"
list-distributions-command = "LIST" WS "DISTRIBUTIONS"
list-extensions-command = "LIST" WS "EXTENSIONS"
list-headers-command = "LIST" WS "HEADERS" WS ["MSGID" / "RANGE"]
list-newsgroups-command = "LIST" WS "NEWSGROUPS" [WS wildmat]
list-overview-fmt-command = "LIST" WS "OVERVIEW.FMT"
listgroup-command = "LISTGROUP" [WS newsgroup-name] listgroup-command = "LISTGROUP" [WS newsgroup-name]
mode-reader-command = "MODE" WS "READER" mode-reader-command = "MODE" WS "READER"
newgroups-command = "NEWGROUPS" WS date-time newgroups-command = "NEWGROUPS" WS date-time
newnews-command = "NEWNEWS" WS wildmat WS date-time newnews-command = "NEWNEWS" WS wildmat WS date-time
next-command = "NEXT" next-command = "NEXT"
over-command = "OVER" [WS range-ref] over-command = "OVER" [WS range-ref]
post-command = "POST" post-command = "POST"
quit-command = "QUIT" quit-command = "QUIT"
stat-command = "STAT" [article-ref] stat-command = "STAT" [WS article-ref]
x-command = x-command-name *(WS x-argument)
; This is the generic syntax for an extension command.
; Each extension command is specified fully elsewhere
article-ref = WS (article-number / message-id) article-ref = article-number / message-id
date = date2y / date4y date = date2y / date4y
date4y = 4DIGIT 2DIGIT 2DIGIT date4y = 4DIGIT 2DIGIT 2DIGIT
date2y = 2DIGIT 2DIGIT 2DIGIT date2y = 2DIGIT 2DIGIT 2DIGIT
date-time = date WS time [WS "GMT"] date-time = date WS time [WS "GMT"]
header-meta-name = header-name / metadata-name header-meta-name = header-name / metadata-name
list-arguments = keyword [WS token]
metadata-name = ":" 1*A-NOTCOLON metadata-name = ":" 1*A-NOTCOLON
range = article-number ["-" [article-number]] range = article-number ["-" [article-number]]
range-ref = WS (range / message-id) range-ref = range / message-id
time = 2DIGIT 2DIGIT 2DIGIT time = 2DIGIT 2DIGIT 2DIGIT
x-command-name = 3*12A-CHAR
x-argument = 1*P-CHAR
9.2 Command continuation 9.2 Command continuation
This syntax defines the further material sent by the client in the This syntax defines the further material sent by the client in the
case of multi-stage commands. case of multi-stage commands and those that stream data.
command-datastream = UNDEFINED
; not used, provided as a hook for extensions
command-continuation = ihave-continuation / command-continuation = ihave-continuation /
post-continuation post-continuation
ihave-continuation = encoded-article ihave-continuation = encoded-article
post-continuation = encoded-article post-continuation = encoded-article
encoded-article = content-lines termination encoded-article = content-lines termination
; after undoing the "byte-stuffing", this MUST match "article" ; after undoing the "byte-stuffing", this MUST match <article>
9.3 Responses 9.3 Responses
9.3.1 Generic responses 9.3.1 Generic responses
This syntax defines the non-terminal "response", which represents the This syntax defines the non-terminal <response>, which represents the
generic form of responses - that is, what is sent from the server to generic form of responses - that is, what is sent from the server to
the client in response to a command or a command-continuation. the client in response to a <command> or a<command-continuation>.
response = simple-response / multiline-response response = simple-response / multiline-response
multiline-response = simple-response content-lines termination multiline-response = simple-response content-lines termination
simple-response = simple-response =
simple-response-content [SP trailing-comment] CRLF simple-response-content [SP trailing-comment] CRLF
simple-response-content = 3DIGIT arguments simple-response-content = X-simple-response-content
X-simple-response-content = 3DIGIT *(SP response-argument)
response-argument = 1*A-CHAR
trailing-comment = *U-CHAR trailing-comment = *U-CHAR
arguments = *(SP argument) ; How many depends on the response
argument = 1*A-CHAR
9.3.2 Initial response line contents 9.3.2 Initial response line contents
This syntax defines the specific initial response lines for the This syntax defines the specific initial response lines for the
various commands and extensions in this specification. Only those various commands in this specification. Only those response codes
response codes with arguments are listed. with arguments are listed.
simple-response-content =/ response-111-content simple-response-content =/ response-111-content
response-211-content response-211-content
response-22x-content response-22x-content
response-401-content response-401-content
response-111-content = "111" SP date4y time response-111-content = "111" SP date4y time
response-211-content = "211" 3(SP article-number) SP newsgroup-name response-211-content = "211" 3(SP article-number) SP newsgroup-name
response-22x-content = ("220" / "221" / "222" / "223") response-22x-content = ("220" / "221" / "222" / "223")
SP article-number SP message-id SP article-number SP message-id
response-401-content = "401" SP extension-label response-401-content = "401" SP capability-label
9.3.3 Multi-line response contents 9.3.3 Multi-line response contents
This syntax defines the content of the various multi-line responses This syntax defines the content of the various multi-line responses
(more precisely, the part of the response in "content-lines"), in (more precisely, the part of the response in <content-lines>), in
each case after any "byte-stuffing" has been undone. each case after any "byte-stuffing" has been undone.
multiline-response-content = article-response / multiline-response-content = article-response /
body-response / body-response /
capabilities-response /
hdr-response / hdr-response /
head-response / head-response /
help-response / help-response /
list-active-response / list-response /
list-active-times-response /
list-distrib-pats-response /
list-distributions-response /
list-extensions-response /
list-headers-response /
list-newsgroups-response /
list-overview-fmt-response /
listgroup-response / listgroup-response /
newgroups-response / newgroups-response /
newnews-response / newnews-response /
over-response over-response
article-response = article article-response = article
body-response = body body-response = body
capabilities-response = 1*(capability-line CRLF)
hdr-response = *(article-number SP hdr-content CRLF) hdr-response = *(article-number SP hdr-content CRLF)
head-response = 1*header head-response = 1*header
help-response = *(*B-CHAR CRLF) help-response = *(*B-CHAR CRLF)
list-active-response = *(newsgroup-name SPA article-number list-response = body
listgroup-response = *(article-number CRLF)
newgroups-response = *(newsgroup-name SPA article-number
SPA article-number SPA newsgroup-status CRLF) SPA article-number SPA newsgroup-status CRLF)
newnews-response = *(message-id CRLF)
over-response = *(article-number over-content CRLF)
hdr-content = *S-NONTAB
hdr-n-content = [(header-name ":" / metadata-name) SP hdr-content]
newsgroup-status = %x79 / %x6E / %x6D / private-status
over-content = 1*6(TAB hdr-content) /
7(TAB hdr-content) *(TAB hdr-n-content)
private-status = token ; except the values in newsgroup-status
9.4 Capability lines
This syntax defines the generic form of a capability line in the
capabilities list (see Section 3.3.1).
capability-line = capability-entry
capability-entry = X-capability-entry
X-capability-entry = capability-label *(WS capability-argument)
capability-label = keyword
capability-argument = token
This syntax defines the specific capability entries for the
capabilities in this specification.
capability-entry =/
hdr-capability /
ihave-capability /
implementation-capability /
list-capability /
mode-reader-capability /
over-capability /
reader-capability /
version-capability
hdr-capability = "HDR"
ihave-capability = "IHAVE"
implementation-capability = "IMPLEMENTATION" *(WS token)
list-capability = "LIST" 1*(WS keyword)
mode-reader-capability = "MODE-READER"
over-capability = "OVER" [WS "MSGID"]
reader-capability = "READER" *(WS reader-option)
reader-option = "POST" / "LISTGROUP" ; each to appear at most once
version-capability = "VERSION" 1*(WS version-number)
version-number = nzDIGIT *5DIGIT
9.5 LIST variants
This section defines more specifically the keywords for the LIST
command and the syntax of the corresponding responses.
; active
list-arguments =/ "ACTIVE" [WS wildmat]
list-response =/ list-active-response
list-active-response = newgroups-response
; active.times
list-arguments =/ "ACTIVE.TIMES" [WS wildmat]
list-response =/ list-active-times-response
list-active-times-response = list-active-times-response =
*(newsgroup-name SPA 1*DIGIT SPA newsgroup-creator CRLF) *(newsgroup-name SPA 1*DIGIT SPA newsgroup-creator CRLF)
newsgroup-creator = U-TEXT
; distrib.pats
list-arguments =/ "DISTRIB.PATS"
list-response =/ list-distrib-pats-response
list-distrib-pats-response = list-distrib-pats-response =
*(1*DIGIT ":" wildmat ":" distribution CRLF) *(1*DIGIT ":" wildmat ":" distribution CRLF)
list-distributions-response = distribution = token
*(distribution SPA distribution-description CRLF)
list-extensions-response = ; headers
*(extension-descriptor CRLF) list-arguments =/ "HEADERS" [WS ("MSGID" / "RANGE")]
list-response =/ list-headers-response
list-headers-response = *(header-meta-name CRLF) / list-headers-response = *(header-meta-name CRLF) /
*((metadata-name / ":") CRLF) *((metadata-name / ":") CRLF)
; newsgroups
list-arguments =/ "NEWSGROUPS" [WS wildmat]
list-response =/ list-newsgroups-response
list-newsgroups-response = list-newsgroups-response =
*(newsgroup-name WS newsgroup-description CRLF) *(newsgroup-name WS newsgroup-description CRLF)
list-overview-fmt-response = list-overview-fmt-text newsgroup-description = S-TEXT
listgroup-response = *(article-number CRLF)
newgroups-response = list-active-response
newnews-response = *(message-id CRLF)
over-response = *(article-number over-content CRLF)
list-overview-fmt-text = ; overview.fmt
"Subject:" CRLF list-arguments =/ "OVERVIEW.FMT"
list-response =/ list-overview-fmt-response
list-overview-fmt-response = "Subject:" CRLF
"From:" CRLF "From:" CRLF
"Date:" CRLF "Date:" CRLF
"Message-ID:" CRLF "Message-ID:" CRLF
"References:" CRLF "References:" CRLF
( ":bytes" CRLF ":lines" / "Bytes:" CRLF "Lines:") CRLF ( ":bytes" CRLF ":lines" / "Bytes:" CRLF "Lines:") CRLF
*((header-name ":full" / metadata-name) CRLF) *((header-name ":full" / metadata-name) CRLF)
distribution = 1*P-CHAR 9.6 Articles
distribution-description = U-TEXT
hdr-content = *S-NONTAB
hdr-n-content = [(header-name ":" / metadata-name) SP hdr-content]
newsgroup-creator = U-TEXT
newsgroup-description = S-TEXT
newsgroup-status = %x79 / %x6E / %x6D / private-status
over-content = 1*6(TAB hdr-content) /
7(TAB hdr-content) *(TAB hdr-n-content)
private-status = 1*P-CHAR ; except the values in newsgroup-status
9.4 LIST EXTENSIONS responses
This syntax defines the generic form of a LIST EXTENSIONS response
line.
extension-argument = 1*P-CHAR
extension-descriptor = extension-generic-descriptor
extension-generic-descriptor =
extension-label *(SPA extension-argument)
extension-label = 1*12UPPER
This syntax defines the specific LIST EXTENSIONS response lines for
the various extensions in this specification.
extension-descriptor =/ hdr-extension /
listgroup-extension /
over-extension
hdr-extension = %x48.44.52 ; "HDR"
listgroup-extension = %x4C.49.53.54.47.52.4F.55.50 ; "LISTGROUP"
over-extension = %x4F.56.45.52 [SPA "MSGID"] ; "OVER"
9.5 Articles
This syntax defines the non-terminal "article", which represents the This syntax defines the non-terminal <article>, which represents the
format of an article as described in Section 3.4. format of an article as described in Section 3.6.
article = 1*header CRLF body article = 1*header CRLF body
header = header-name ":" [CRLF] SP header-content CRLF header = header-name ":" [CRLF] SP header-content CRLF
header-content = *(S-CHAR / [CRLF] WS) header-content = *(S-CHAR / [CRLF] WS)
body = *(*B-CHAR CRLF) body = *(*B-CHAR CRLF)
9.6 General non-terminals 9.7 General non-terminals
These non-terminals are used at various places in the syntax and are These non-terminals are used at various places in the syntax and are
collected here for convenience. A few of these non-terminals are not collected here for convenience. A few of these non-terminals are not
used in this specification but are provided for the consistency and used in this specification but are provided for the consistency and
convenience of extension authors. convenience of extension authors.
article-number = 1*16DIGIT article-number = 1*16DIGIT
content-lines = *([content-text] CRLF) content-lines = *([content-text] CRLF)
content-text = (".." / B-NONDOT) *B-CHAR content-text = (".." / B-NONDOT) *B-CHAR
header-name = 1*A-NOTCOLON header-name = 1*A-NOTCOLON
keyword = ALPHA 2*11(ALPHA / DIGIT / "." / "-")
message-id = "<" 1*248A-NOTGT ">" message-id = "<" 1*248A-NOTGT ">"
newsgroup-name = 1*wildmat-exact newsgroup-name = 1*wildmat-exact
termination = "." CRLF termination = "." CRLF
token = 1*P-CHAR
wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) wildmat = wildmat-pattern *("," ["!"] wildmat-pattern)
wildmat-pattern = 1*wildmat-item wildmat-pattern = 1*wildmat-item
; must not begin with "!" if not immediately preceded by "!"
wildmat-item = wildmat-exact / wildmat-wild wildmat-item = wildmat-exact / wildmat-wild
wildmat-exact = %x21-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / wildmat-exact = %x21-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E /
UTF8-non-ascii ; exclude * , ? [ \ ] UTF8-non-ascii ; exclude * , ? [ \ ]
wildmat-wild = "*" / "?" wildmat-wild = "*" / "?"
base64 = *(4base64-char) [base64-terminal] base64 = *(4base64-char) [base64-terminal]
base64-char = UPPER / LOWER / DIGIT / "+" / "/" base64-char = UPPER / LOWER / DIGIT / "+" / "/"
base64-terminal = 2base64-char "==" / 3base64-char "=" base64-terminal = 2base64-char "==" / 3base64-char "="
; Assorted special character sets ; Assorted special character sets
skipping to change at page 85, line 35 skipping to change at page 91, line 5
U-NONTAB = CTRL / SP / A-CHAR / UTF8-non-ascii U-NONTAB = CTRL / SP / A-CHAR / UTF8-non-ascii
U-TEXT = P-CHAR *U-CHAR U-TEXT = P-CHAR *U-CHAR
B-CHAR = CTRL / TAB / SP / %x21-FF B-CHAR = CTRL / TAB / SP / %x21-FF
B-NONDOT = CTRL / TAB / SP / %x21-2D / %x2F-FF ; exclude "." B-NONDOT = CTRL / TAB / SP / %x21-2D / %x2F-FF ; exclude "."
ALPHA = UPPER / LOWER ; use only when case-insensitive ALPHA = UPPER / LOWER ; use only when case-insensitive
CR = %x0D CR = %x0D
CRLF = CR LF CRLF = CR LF
CTRL = %x01-08 / %x0B-0C / %x0E-1F CTRL = %x01-08 / %x0B-0C / %x0E-1F
DIGIT = %x30-39 DIGIT = %x30-39
nzDIGIT = %x31-39
EOL = *(SP / TAB) CRLF EOL = *(SP / TAB) CRLF
LF = %x0A LF = %x0A
LOWER = %x61-7A LOWER = %x61-7A
SP = %x20 SP = %x20
SPA = 1*SP SPA = 1*SP
TAB = %x09 TAB = %x09
UPPER = %x41-5A UPPER = %x41-5A
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail / UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail /
skipping to change at page 87, line 5 skipping to change at page 91, line 39
S-CHAR = %x21-FF S-CHAR = %x21-FF
S-NONTAB = CTRL / SP / S-CHAR S-NONTAB = CTRL / SP / S-CHAR
S-TEXT = (CTRL / S-CHAR) *B-CHAR S-TEXT = (CTRL / S-CHAR) *B-CHAR
Implementations SHOULD only generate content that meets this syntax: Implementations SHOULD only generate content that meets this syntax:
S-CHAR = P-CHAR S-CHAR = P-CHAR
S-NONTAB = U-NONTAB S-NONTAB = U-NONTAB
S-TEXT = U-TEXT S-TEXT = U-TEXT
9.8 Extensions and Validation
The specification of a registered extension MUST include formal
syntax that defines additional forms for the following non-terminals:
command
for each new command other than a variant of the LIST command -
the syntax of each command MUST be compatible with the definition
of <X-command>;
command-datastream
for each new command that immediately streams data;
command-continuation
for each new command that sends further material after the initial
command line - the syntax of each continuation MUST be exactly
what is sent to the server, including any escape mechanisms such
as "byte-stuffing";
simple-response-content
for each new response code that has arguments - the syntax of each
response MUST be compatible with the definition of
<X-simple-response-content>;
multiline-response-content
for each new response code that has a multi-line response - the
syntax MUST show the response after the lines containing the
response code and the terminating octet have been removed and any
"byte-stuffing" undone;
capability-entry
for each new capability label - the syntax of each entry MUST be
compatible with the definition of <X-capability-entry>;
list-arguments
for each new variant of the LIST command - the syntax of each
entry MUST be compatible with the definition of <X-command>;
list-response
for each new variant of the LIST command - the syntax MUST show
the response after the lines containing the 215 response code and
the terminating octet have been removed and any "byte-stuffing"
undone.
The =/ notation of ABNF [RFC2234] SHOULD be used for this.
When validating the syntax in this specification, or syntax based on
it, it should be noted that:
o the non-terminals <command-line>, <command-datastream>,
<command-continuation>, <response>, and
<multiline-response-content> describe basic concepts of the
protocol and are not referred to by any other rule;
o the non-terminal <base64> is provided for the convenience of
extension authors and is not referred to by any rule in this
specification;
o for the reasons given above, the non-terminals <S-CHAR>,
<S-NONTAB>, and <S-TEXT> each have two definitions;
o the non-terminal <UNDEFINED> is deliberately not defined.
10. IANA Considerations 10. IANA Considerations
This specification requires IANA to keep a registry of This specification requires IANA to keep a registry of capability
extension-labels. The initial contents of this registry are labels. The initial contents of this registry are specified in
specified in Section 8.1. As described in Section 8, names beginning Section 3.3.4. As described in Section 3.3.3, labels beginning with
with X are reserved for private use while all other names are X are reserved for private use while all other names are expected to
expected to be associated with a specification in an RFC on the be associated with a specification in an RFC on the standards-track
standards-track or defining an IESG-approved experimental protocol. or defining an IESG-approved experimental protocol.
Different entries in the registry MUST use different Different entries in the registry MUST use different capability
extension-labels. labels.
Different entries in the registry MUST NOT use the same command name. Different entries in the registry MUST NOT use the same command name.
For this purpose, variants distinguished by a second or subsequent For this purpose, variants distinguished by a second or subsequent
keyword (e.g. "LIST HEADERS" and "LIST OVERVIEW.FMT") count as keyword (e.g. "LIST HEADERS" and "LIST OVERVIEW.FMT") count as
different commands. If there is a need for two extensions to use the different commands. If there is a need for two extensions to use the
same command, a single harmonised specification MUST be registered. same command, a single harmonised specification MUST be registered.
11. Security Considerations 11. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
skipping to change at page 90, line 23 skipping to change at page 96, line 23
(%x20). If it is replaced by the latter in a command line, this (%x20). If it is replaced by the latter in a command line, this
needs to happen before the command line is parsed into individual needs to happen before the command line is parsed into individual
arguments. If the replacement came after parsing, it would be arguments. If the replacement came after parsing, it would be
possible to generate an argument with an embedded space, which is possible to generate an argument with an embedded space, which is
forbidden. Use of the "replacement character" does not have this forbidden. Use of the "replacement character" does not have this
problem, since it is permitted wherever non-US-ASCII characters are. problem, since it is permitted wherever non-US-ASCII characters are.
Implementations SHOULD use one of the first two solutions where the Implementations SHOULD use one of the first two solutions where the
general structure of the NNTP stream remains intact, and close the general structure of the NNTP stream remains intact, and close the
connection if it is no longer possible to parse it sensibly. connection if it is no longer possible to parse it sensibly.
11.6 Caching of LIST EXTENSIONS results 11.6 Caching of capability lists
The LIST EXTENSIONS command provides information about the extensions The CAPABILITIES command provides a capability list, which is
currently available from the server. Whenever there is a relevant information about the current capabilities of the server. Whenever
change to the server state, the results of this command are required there is a relevant change to the server state, the results of this
to change accordingly. command are required to change accordingly.
In most situations the results from this command in a given server In most situations the capabilities list in a given server state will
state will not change from session to session; a given extension will not change from session to session; for example, a given extension
be installed permanently on a server. Some clients may therefore will be installed permanently on a server. Some clients may
wish to remember which extensions a server supports to avoid the therefore wish to remember which extensions a server supports to
delay of an additional command and response, particularly if they avoid the delay of an additional command and response, particularly
open multiple connections in the same session. if they open multiple connections in the same session.
However, information about extensions related to security and privacy However, information about extensions related to security and privacy
MUST NOT be cached, since this could allow a variety of attacks. MUST NOT be cached, since this could allow a variety of attacks.
For example, consider a server which permits the use of cleartext For example, consider a server which permits the use of cleartext
passwords on links that are encrypted but not otherwise: passwords on links that are encrypted but not otherwise:
[Initial TCP connection set-up completed.] [Initial TCP connection set-up completed.]
[S] 200 NNTP Service Ready, posting permitted [S] 200 NNTP Service Ready, posting permitted
[C] LIST EXTENSIONS [C] CAPABILITIES
[S] 202 Extensions supported: [S] 101 Capability list:
[S] VERSION 2
[S] READER POST
[S] XENCRYPT [S] XENCRYPT
[S] LIST ACTIVE NEWSGROUPS
[S] . [S] .
[C] XENCRYPT [C] XENCRYPT
[Client and server negotiate encryption on the link] [Client and server negotiate encryption on the link]
[S] 283 Encrypted link established [S] 283 Encrypted link established
[C] LIST EXTENSIONS [C] CAPABILITIES
[S] 202 Extensions supported: [S] 101 Capability list:
[S] VERSION 2
[S] READER POST
[S] XSECRET [S] XSECRET
[S] LIST ACTIVE NEWSGROUPS
[S] . [S] .
[C] XSECRET fred flintstone [C] XSECRET fred flintstone
[S] 290 Password for fred accepted [S] 290 Password for fred accepted
If the client caches the last LIST EXTENSIONS result, then on the If the client caches the last capabilities list, then on the next
next session it will attempt to use XSECRET on an unencrypted link: session it will attempt to use XSECRET on an unencrypted link:
[Initial TCP connection set-up completed.] [Initial TCP connection set-up completed.]
[S] 200 NNTP Service Ready, posting permitted [S] 200 NNTP Service Ready, posting permitted
[C] XSECRET fred flintstone [C] XSECRET fred flintstone
[S] 483 Only permitted on secure links [S] 483 Only permitted on secure links
exposing the password to any eavesdropper. While the primary cause exposing the password to any eavesdropper. While the primary cause
of this is passing a secret without first checking the security of of this is passing a secret without first checking the security of
the link, caching of LIST EXTENSIONS results can increase the risk. the link, caching of capability lists can increase the risk.
Any security extension should include requirements to check the Any security extension should include requirements to check the
security state of the link in a manner appropriate to that extension. security state of the link in a manner appropriate to that extension.
Caching should normally only be considered for anonymous clients that Caching should normally only be considered for anonymous clients that
do not use any security or privacy extensions and for which the time do not use any security or privacy extensions and for which the time
required for an additional command and response is a noticeable required for an additional command and response is a noticeable
issue. issue.
12. Acknowledgements 12. Acknowledgements
skipping to change at page 92, line 21 skipping to change at page 98, line 21
The author acknowledges the original authors of NNTP as documented in The author acknowledges the original authors of NNTP as documented in
RFC 977 [RFC977]: Brian Kantor and Phil Lapsey. RFC 977 [RFC977]: Brian Kantor and Phil Lapsey.
The author gratefully acknowledges: The author gratefully acknowledges:
o The work of the NNTP committee chaired by Eliot Lear. The o The work of the NNTP committee chaired by Eliot Lear. The
organization of this document was influenced by the last available organization of this document was influenced by the last available
draft from this working group. A special thanks to Eliot for draft from this working group. A special thanks to Eliot for
generously providing the original machine-readable sources for generously providing the original machine-readable sources for
that document. that document.
o The work of the DRUMS working group, specifically RFC 1869 o The work of the DRUMS working group, specifically RFC 1869
[RFC1869], which is the basis of the NNTP extensions mechanism [RFC1869], which drove the original thinking which led to the
detailed in this document. CAPABILITIES command and the extensions mechanism detailed in this
document.
o The authors of RFC 2616 [RFC2616] for providing specific and o The authors of RFC 2616 [RFC2616] for providing specific and
relevant examples of security issues that should be considered for relevant examples of security issues that should be considered for
HTTP. Since many of the same considerations exist for NNTP, those HTTP. Since many of the same considerations exist for NNTP, those
examples that are relevant have been included here with some minor examples that are relevant have been included here with some minor
rewrites. rewrites.
o The comments and additional information provided by the following o The comments and additional information provided by the following
individuals in preparing one or more of the progenitors of this individuals in preparing one or more of the progenitors of this
document: document:
Russ Allbery <rra@stanford.edu> Russ Allbery <rra@stanford.edu>
Wayne Davison <davison@armory.com> Wayne Davison <davison@armory.com>
skipping to change at page 93, line 27 skipping to change at page 99, line 29
Henry Spencer Henry Spencer
One of the original authors of CNEWS One of the original authors of CNEWS
Kim Storm Kim Storm
Original author of the NN news reader Original author of the NN news reader
Other people who contributed to this document include: Other people who contributed to this document include:
Matthias Andree Matthias Andree
Greg Andruk Greg Andruk
Maurizio Codogno Maurizio Codogno
Mark Crispin
Andrew Gierth Andrew Gierth
Juergen Helbing Juergen Helbing
Scott Hollenbeck Scott Hollenbeck
Charles Lindsey Charles Lindsey
Ade Lovett Ade Lovett
Ken Murchinson Ken Murchison
Francois Petillon Francois Petillon
Peter Robinson Peter Robinson
Rob Siemborski Rob Siemborski
Howard Swinehart Howard Swinehart
Ruud van Tol Ruud van Tol
Jeffrey Vinocur Jeffrey Vinocur
The author thanks them all and apologises to anyone omitted. The author thanks them all and apologises to anyone omitted.
Finally, the present author gratefully acknowledges the vast amount Finally, the present author gratefully acknowledges the vast amount
skipping to change at page 94, line 37 skipping to change at page 100, line 37
Protocol", RFC 977, February 1986. Protocol", RFC 977, February 1986.
[TF.686-1] [TF.686-1]
International Telecommunications Union - Radio, "Glossary, International Telecommunications Union - Radio, "Glossary,
ITU-R Recommendation TF.686-1", ITU-R Recommendation ITU-R Recommendation TF.686-1", ITU-R Recommendation
TF.686-1, October 1997. TF.686-1, October 1997.
13.2 Informative References 13.2 Informative References
[NNTP-AUTH] [NNTP-AUTH]
Vinocur, J., Newman, C. and K. Murchinson, "NNTP Vinocur, J., Murchison, K. and C. Newman, "NNTP
Authentication", draft-ietf-nntpext-authinfo-02 (work in Authentication",
progress), July 2004. Internet-draft draft-ietf-nntpext-authinfo-06, December
2004.
[NNTP-STREAM]
Vinocur, J. and K. Murchison, "NNTP Authentication",
Internet-draft draft-ietf-nntpext-streaming-03, December
2004.
[NNTP-TLS] [NNTP-TLS]
Vinocur, J. and C. Newman, "Using TLS with NNTP", Vinocur, J., Murchison, K. and C. Newman, "Using TLS with
draft-ietf-nntpext-tls-nntp-01 (work in progress), October NNTP", Internet-draft draft-ietf-nntpext-tls-nntp-04,
2003. December 2004.
[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.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869, Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
November 1995. November 1995.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
skipping to change at page 95, line 46 skipping to change at page 102, line 15
Author's Address Author's Address
Clive D.W. Feather Clive D.W. Feather
Thus plc Thus plc
322 Regents Park Road 322 Regents Park Road
London N3 2QQ London N3 2QQ
GB GB
Phone: +44 20 8495 6138 Phone: +44 20 8495 6138
Fax: +44 870 051 9937 Fax: +44 870 051 9937
EMail: clive@demon.net Email: clive@demon.net
URI: http://www.davros.org/ URI: http://www.davros.org/
Appendix A. Future Directions Appendix A. Interaction with other specifications
It has been proposed that the response code range 6xx be used for
multiline responses. While existing commands and extensions do not
use this, it would at least limit the problem clients would face in
dealing with an unknown response.
Appendix B. Interaction with other specifications
NNTP is most often used for transferring articles that conform to RFC NNTP is most often used for transferring articles that conform to RFC
1036 [RFC1036] (such articles are called "Netnews articles" here). 1036 [RFC1036] (such articles are called "Netnews articles" here).
It is also sometimes used for transferring email messages that It is also sometimes used for transferring email messages that
conform to RFC 2822 [RFC2822] (such articles are called "email conform to RFC 2822 [RFC2822] (such articles are called "email
articles" here). In this situation, articles must conform both to articles" here). In this situation, articles must conform both to
this specification and to that other one; this appendix describes this specification and to that other one; this appendix describes
some relevant issues. some relevant issues.
B.1 Header folding A.1 Header folding
NNTP allows a header line to be folded (by inserting a CRLF pair) NNTP allows a header line to be folded (by inserting a CRLF pair)
before any space or TAB character. before any space or TAB character.
Both email and Netnews articles are required to have at least one Both email and Netnews articles are required to have at least one
octet other than space or TAB on each header line. Thus folding can octet other than space or TAB on each header line. Thus folding can
only happen at one point in each sequence of consecutive spaces or only happen at one point in each sequence of consecutive spaces or
TABs. Netnews articles are further required to have the header name, TABs. Netnews articles are further required to have the header name,
colon, and following space all on the first line; folding may only colon, and following space all on the first line; folding may only
happen beyond that space. Finally, some non-conforming software will happen beyond that space. Finally, some non-conforming software will
remove trailing spaces and TABs from a line. Therefore it might be remove trailing spaces and TABs from a line. Therefore it might be
inadvisable to fold a header after a space or TAB. inadvisable to fold a header after a space or TAB.
For maximum safety, header lines SHOULD conform to the following For maximum safety, header lines SHOULD conform to the following
syntax rather than that in Section 9.5. syntax rather than that in Section 9.6.
header = header-name ":" SP [header-content] CRLF header = header-name ":" SP [header-content] CRLF
header-content = [WS] 1*P-CHAR *( [CRLF] WS 1*P-CHAR ) header-content = [WS] token *( [CRLF] WS token )
B.2 Message-IDs A.2 Message-IDs
Every article handled by an NNTP server MUST have a unique Every article handled by an NNTP server MUST have a unique
message-id. For the purposes of this specification, a message-id is message-id. For the purposes of this specification, a message-id is
an arbitrary opaque string that merely needs to meet certain an arbitrary opaque string that merely needs to meet certain
syntactic requirements and is just a way to refer to the article. syntactic requirements and is just a way to refer to the article.
Because there is a significant risk of old articles being reinjected Because there is a significant risk of old articles being reinjected
into the global Usenet system, RFC 1036 [RFC1036] requires that into the global Usenet system, RFC 1036 [RFC1036] requires that
message-ids are globally unique for all time. message-ids are globally unique for all time.
skipping to change at page 98, line 42 skipping to change at page 104, line 42
or determine one from the article contents. However, whichever it or determine one from the article contents. However, whichever it
does it SHOULD ensure that, if the IHAVE command is repeated with the does it SHOULD ensure that, if the IHAVE command is repeated with the
same argument and article, it will be recognized as a duplicate. same argument and article, it will be recognized as a duplicate.
If an article does not contain a message-id that the server can If an article does not contain a message-id that the server can
identify, it MUST synthesize one. This could, for example, be a identify, it MUST synthesize one. This could, for example, be a
simple sequence number or based on the date and time that the article simple sequence number or based on the date and time that the article
arrived. When handling email or Netnews articles, a Message-ID arrived. When handling email or Netnews articles, a Message-ID
header SHOULD be added to ensure global consistency and uniqueness. header SHOULD be added to ensure global consistency and uniqueness.
B.3 Article posting A.3 Article posting
As far as NNTP is concerned, the POST and IHAVE commands provide the As far as NNTP is concerned, the POST and IHAVE commands provide the
same basic facilities in a slightly different way. However they have same basic facilities in a slightly different way. However they have
rather different intentions. rather different intentions.
The IHAVE command is intended for transmitting conforming articles The IHAVE command is intended for transmitting conforming articles
between a system of NNTP servers, with all articles perhaps also between a system of NNTP servers, with all articles perhaps also
conforming to another specification (e.g. all articles are Netnews conforming to another specification (e.g. all articles are Netnews
articles). It is expected that the client will have already done any articles). It is expected that the client will have already done any
necessary validation (or has in turn obtained the article from a necessary validation (or has in turn obtained the article from a
skipping to change at page 100, line 5 skipping to change at page 106, line 5
important to ensure - as far as possible - that the same message-id important to ensure - as far as possible - that the same message-id
is allocated to both attempts so that the server, or other servers, is allocated to both attempts so that the server, or other servers,
can recognize the two articles as being duplicates. In the case of can recognize the two articles as being duplicates. In the case of
email or Netnews articles, therefore, the posted article SHOULD email or Netnews articles, therefore, the posted article SHOULD
contain a header with name "Message-ID" and the contents of this contain a header with name "Message-ID" and the contents of this
header SHOULD be identical on each attempt. The server SHOULD ensure header SHOULD be identical on each attempt. The server SHOULD ensure
that two POSTed articles with the same contents for this header are that two POSTed articles with the same contents for this header are
recognized as identical and the same message-id allocated, whether or recognized as identical and the same message-id allocated, whether or
not those contents are suitable for use as the message-id. not those contents are suitable for use as the message-id.
Appendix B. Summary of Commands
This section contains a list of every command defined in this
document, ordered by command name and by indicating capability.
Ordered by command name:
+-------------------+-----------------------+---------------+
| Command | Indicating capability | Definition |
+-------------------+-----------------------+---------------+
| ARTICLE | READER | Section 6.2.1 |
| | | |
| BODY | READER | Section 6.2.3 |
| | | |
| CAPABILITIES | mandatory | Section 5.2 |
| | | |
| DATE | READER | Section 7.1 |
| | | |
| GROUP | READER | Section 6.1.1 |
| | | |
| HDR | HDR | Section 8.5 |
| | | |
| HEAD | mandatory | Section 6.2.2 |
| | | |
| HELP | mandatory | Section 7.2 |
| | | |
| IHAVE | IHAVE | Section 6.3.2 |
| | | |
| LAST | READER | Section 6.1.3 |
| | | |
| LIST | LIST | Section 7.6.1 |
| | | |
| LIST ACTIVE.TIMES | LIST | Section 7.6.4 |
| | | |
| LIST ACTIVE | LIST | Section 7.6.3 |
| | | |
| LIST DISTRIB.PATS | LIST | Section 7.6.5 |
| | | |
| LIST HEADERS | HDR | Section 8.6 |
| | | |
| LIST NEWSGROUPS | LIST | Section 7.6.6 |
| | | |
| LIST OVERVIEW.FMT | OVER | Section 8.4 |
| | | |
| LISTGROUP | READER LISTGROUP | Section 6.1.2 |
| | | |
| MODE READER | MODE-READER | Section 5.3 |
| | | |
| NEWGROUPS | READER | Section 7.3 |
| | | |
| NEWNEWS | READER | Section 7.4 |
| | | |
| NEXT | READER | Section 6.1.4 |
| | | |
| OVER | OVER | Section 8.3 |
| | | |
| POST | READER POST | Section 6.3.1 |
| | | |
| QUIT | mandatory | Section 5.4 |
| | | |
| STAT | mandatory | Section 6.2.4 |
+-------------------+-----------------------+---------------+
Ordered by indicating capability:
+-------------------+-----------------------+---------------+
| Command | Indicating capability | Definition |
+-------------------+-----------------------+---------------+
| CAPABILITIES | mandatory | Section 5.2 |
| | | |
| HEAD | mandatory | Section 6.2.2 |
| | | |
| HELP | mandatory | Section 7.2 |
| | | |
| QUIT | mandatory | Section 5.4 |
| | | |
| STAT | mandatory | Section 6.2.4 |
| | | |
| HDR | HDR | Section 8.5 |
| | | |
| LIST HEADERS | HDR | Section 8.6 |
| | | |
| IHAVE | IHAVE | Section 6.3.2 |
| | | |
| LIST | LIST | Section 7.6.1 |
| | | |
| LIST ACTIVE | LIST | Section 7.6.3 |
| | | |
| LIST ACTIVE.TIMES | LIST | Section 7.6.4 |
| | | |
| LIST DISTRIB.PATS | LIST | Section 7.6.5 |
| | | |
| LIST NEWSGROUPS | LIST | Section 7.6.6 |
| | | |
| MODE READER | MODE-READER | Section 5.3 |
| | | |
| OVER | OVER | Section 8.3 |
| | | |
| LIST OVERVIEW.FMT | OVER | Section 8.4 |
| | | |
| ARTICLE | READER | Section 6.2.1 |
| | | |
| BODY | READER | Section 6.2.3 |
| | | |
| DATE | READER | Section 7.1 |
| | | |
| GROUP | READER | Section 6.1.1 |
| | | |
| LAST | READER | Section 6.1.3 |
| | | |
| NEWGROUPS | READER | Section 7.3 |
| | | |
| NEWNEWS | READER | Section 7.4 |
| | | |
| NEXT | READER | Section 6.1.4 |
| | | |
| LISTGROUP | READER LISTGROUP | Section 6.1.2 |
| | | |
| POST | READER POST | Section 6.3.1 |
+-------------------+-----------------------+---------------+
Where two keywords are given in the capability column, the second is
an argument to the first.
Appendix C. Summary of Response Codes Appendix C. Summary of Response Codes
This section contains a list of every response code defined in this This section contains a list of every response code defined in this
document, whether it is multi-line, which commands can generate it, document, whether it is multi-line, which commands can generate it,
what arguments it has, and what its meaning is. what arguments it has, and what its meaning is.
Response code 100 (multi-line) Response code 100 (multi-line)
Generated by: HELP Generated by: HELP
Meaning: help text follows. Meaning: help text follows.
Response code 101 (multi-line)
Generated by: CAPABILITIES
Meaning: capabilities list follows.
Response code 111 Response code 111
Generated by: DATE Generated by: DATE
1 argument: yyyymmddhhmmss 1 argument: yyyymmddhhmmss
Meaning: server date and time. Meaning: server date and time.
Response code 200 Response code 200
Generated by: initial connection, MODE READER Generated by: initial connection, MODE READER
Meaning: service available, posting allowed. Meaning: service available, posting allowed.
Response code 201 Response code 201
Generated by: initial connection, MODE READER Generated by: initial connection, MODE READER
Meaning: service available, posting prohibited. Meaning: service available, posting prohibited.
Response code 202 (multi-line)
Generated by: LIST EXTENSIONS
Meaning: extension list follows.
Response code 205 Response code 205
Generated by: QUIT Generated by: QUIT
Meaning: connection closing (the server immediately closes the Meaning: connection closing (the server immediately closes the
connection). connection).
Response code 211 Response code 211
The 211 response code has two completely different forms depending The 211 response code has two completely different forms depending
on which command generated it: on which command generated it:
Generated by: GROUP Generated by: GROUP
4 arguments: number low high group 4 arguments: number low high group
Meaning: group selected. Meaning: group selected.
skipping to change at page 100, line 37 skipping to change at page 109, line 37
Response code 205 Response code 205
Generated by: QUIT Generated by: QUIT
Meaning: connection closing (the server immediately closes the Meaning: connection closing (the server immediately closes the
connection). connection).
Response code 211 Response code 211
The 211 response code has two completely different forms depending The 211 response code has two completely different forms depending
on which command generated it: on which command generated it:
Generated by: GROUP Generated by: GROUP
4 arguments: number low high group 4 arguments: number low high group
Meaning: group selected. Meaning: group selected.
(multi-line) (multi-line)
Generated by: LISTGROUP Generated by: LISTGROUP
4 arguments: number low high group 4 arguments: number low high group
Meaning: article numbers follow. Meaning: article numbers follow.
Response code 215 (multi-line) Response code 215 (multi-line)
Generated by: LIST ACTIVE, LIST ACTIVE.TIMES, LIST DISTRIB.PATS, Generated by: LIST
LIST DISTRIBUTIONS, LIST HEADERS, LIST NEWSGROUPS,
LIST OVERVIEW.FMT
Meaning: information follows. Meaning: information follows.
Response code 220 (multi-line) Response code 220 (multi-line)
Generated by: ARTICLE Generated by: ARTICLE
2 arguments: n message-id 2 arguments: n message-id
Meaning: article follows. Meaning: article follows.
Response code 221 (multi-line) Response code 221 (multi-line)
Generated by: HEAD Generated by: HEAD
2 arguments: n message-id 2 arguments: n message-id
Meaning: article headers follow. Meaning: article headers follow.
Response code 222 (multi-line) Response code 222 (multi-line)
Generated by: BODY Generated by: BODY
2 arguments: n message-id 2 arguments: n message-id
Meaning: article body follows. Meaning: article body follows.
Response code 223 Response code 223
Generated by: LAST, NEXT, STAT Generated by: LAST, NEXT, STAT
2 arguments: n message-id 2 arguments: n message-id
Meaning: article exists and selected. Meaning: article exists and selected.
Response code 224 (multi-line) Response code 224 (multi-line)
Generated by: OVER Generated by: OVER
skipping to change at page 101, line 47 skipping to change at page 110, line 43
Meaning: send article to be transferred. Meaning: send article to be transferred.
Response code 340 Response code 340
Generated by: POST (first stage) Generated by: POST (first stage)
Meaning: send article to be posted. Meaning: send article to be posted.
Response code 400 Response code 400
Generic response and generated by initial connection Generic response and generated by initial connection
Meaning: service not available or no longer available (the server Meaning: service not available or no longer available (the server
immediately closes the connection). immediately closes the connection).
Response code 401 Response code 401
Generic response Generic response
1 argument: extension-label 1 argument: capability-label
Meaning: the server is in the wrong mode; the indicated extension Meaning: the server is in the wrong mode; the indicated capability
should be used to change the mode. should be used to change the mode.
Response code 402
Generated by: LIST EXTENSIONS
Meaning: server has no extensions.
Response code 403 Response code 403
Generic response Generic response
Meaning: internal fault or problem preventing action being taken. Meaning: internal fault or problem preventing action being taken.
Response code 411 Response code 411
Generated by: GROUP, LISTGROUP Generated by: GROUP, LISTGROUP
Meaning: no such newsgroup. Meaning: no such newsgroup.
Response code 412 Response code 412
Generated by: ARTICLE, BODY, HDR, HEAD, LAST, LISTGROUP, NEXT, Generated by: ARTICLE, BODY, HDR, HEAD, LAST, LISTGROUP, NEXT,
OVER, STAT OVER, STAT
Meaning: no newsgroup selected. Meaning: no newsgroup selected.
Response code 420 Response code 420
Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT
Meaning: current article number is invalid. Meaning: current article number is invalid.
Response code 421 Response code 421
Generated by: NEXT Generated by: NEXT
Meaning: no next article in this group. Meaning: no next article in this group.
skipping to change at page 104, line 5 skipping to change at page 113, line 5
connection). connection).
Meaning for all other commands: command not permitted (and there Meaning for all other commands: command not permitted (and there
is no way for the client to change this). is no way for the client to change this).
Response code 503 Response code 503
Generic response Generic response
Meaning: feature not supported. Meaning: feature not supported.
Response code 504 Response code 504
Generic response Generic response
Meaning: error in base64-encoding [RFC3548] of an argument Meaning: error in base64-encoding [RFC3548] of an argument
Appendix D. Formal specification of the standard extensions
This section gives a formal definition of each of the extensions in
Section 8.2 as required by Section 8 for the IANA registry.
D.1 The LISTGROUP extension
o This extension provides information about specific article
numbers.
o The extension-label is "LISTGROUP".
o The extension-label has no arguments.
o The extension defines one new command: LISTGROUP, whose behaviour,
arguments, and responses are defined in Section 8.3.
o The extension does not associate any new responses with
pre-existing NNTP commands.
o The extension does not affect the behaviour of a server or client
other than via the new command.
o The extension does not affect the maximum length of commands and
initial response lines.
o The extension does not alter pipelining, and the LISTGROUP command
can be pipelined.
o Use of this extension does not alter the output from LIST
EXTENSIONS.
o The extension does not cause any pre-existing command to produce a
401, 480, or 483 response.
o The LISTGROUP command can only be used after the MODE READER
command.
D.2 The OVER extension
o This extension provides support for an overview of newsgroups.
o The extension-label is "OVER".
o The extension-label has the optional argument "MSGID", indicating
that the message-id variant of the OVER command is supported.
o The extension defines two new commands: OVER and LIST
OVERVIEW.FMT, whose behaviour, arguments, and responses are
defined in Section 8.5.
o The extension does not associate any new responses with
pre-existing NNTP commands.
o The extension requires the server to maintain an overview database
and article metadata, as described in Section 8.4.
o The extension does not affect the maximum length of commands and
initial response lines.
o The extension does not alter pipelining, and the OVER and LIST
OVERVIEW.FMT commands can be pipelined.
o Use of this extension does not alter the output from LIST
EXTENSIONS.
o The extension does not cause any pre-existing command to produce a
401, 480, or 483 response.
o The OVER and LIST OVERVIEW.FMT commands can only be used after the
MODE READER command.
D.3 The HDR extension
o This extension provides batched header retrieval.
o The extension-label is "HDR".
o The extension-label has no arguments.
o The extension defines two new commands: HDR and LIST HEADERS,
whose behaviour, arguments, and responses are defined in Section
8.6.
o The extension does not associate any new responses with
pre-existing NNTP commands.
o The extension requires the server to maintain article metadata, as
described in Section 8.4.
o The extension does not affect the maximum length of commands and
initial response lines.
o The extension does not alter pipelining, and the HDR and LIST
HEADERS commands can be pipelined.
o Use of this extension does not alter the output from LIST
EXTENSIONS.
o The extension does not cause any pre-existing command to produce a
401, 480, or 483 response.
o The HDR and LIST HEADERS commands can only be used after the MODE
READER command.
Intellectual Property Statement Intellectual Property Statement
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 106, line 41 skipping to change at page 113, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/