draft-ietf-nntpext-base-20.txt   draft-ietf-nntpext-base-21.txt 
NNTP C. Feather NNTP C. Feather
Internet-Draft Thus plc Internet-Draft Thus plc
Expires: April 15, 2004 October 16, 2003 Expires: September 6, 2004 March 8, 2004
Network News Transport Protocol Network News Transport Protocol
draft-ietf-nntpext-base-20 draft-ietf-nntpext-base-21
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3667.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 April 15, 2004. This Internet-Draft will expire on September 6, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The Network News Transport Protocol (NNTP) has been in use in the The Network News Transport 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 20. This is draft 21.
Author's Note Author's Note
This draft is written in XML using an NNTP-specific DTD. Custom This draft 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 draft. No perl was used in producing this draft.
Rights Rights
UNIX is a registered trademark of the X/Open Company Ltd. UNIX is a registered trademark of The Open Group.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . 8 3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . 8
3.1 Commands and Responses . . . . . . . . . . . . . . . . . 8 3.1 Commands and Responses . . . . . . . . . . . . . . . . . 8
3.2 Response Codes . . . . . . . . . . . . . . . . . . . . . 10 3.2 Response Codes . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Generic Response Codes . . . . . . . . . . . . . . . . . 11 3.2.1 Generic Response Codes . . . . . . . . . . . . . . . . . 11
3.2.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Articles . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4 Articles . . . . . . . . . . . . . . . . . . . . . . . . 16
4. The WILDMAT format . . . . . . . . . . . . . . . . . . . 18 4. The WILDMAT format . . . . . . . . . . . . . . . . . . . 18
4.1 Wildmat syntax . . . . . . . . . . . . . . . . . . . . . 18 4.1 Wildmat syntax . . . . . . . . . . . . . . . . . . . . . 18
4.2 Wildmat semantics . . . . . . . . . . . . . . . . . . . 18 4.2 Wildmat semantics . . . . . . . . . . . . . . . . . . . 18
4.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . 19 4.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Session administration commands . . . . . . . . . . . . 21 5. Session administration commands . . . . . . . . . . . . 21
5.1 Initial Connection . . . . . . . . . . . . . . . . . . . 21 5.1 Initial Connection . . . . . . . . . . . . . . . . . . . 21
5.2 MODE READER . . . . . . . . . . . . . . . . . . . . . . 22 5.2 MODE READER . . . . . . . . . . . . . . . . . . . . . . 22
5.3 LIST EXTENSIONS . . . . . . . . . . . . . . . . . . . . 24 5.3 LIST EXTENSIONS . . . . . . . . . . . . . . . . . . . . 25
5.4 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Article posting and retrieval . . . . . . . . . . . . . 28 6. Article posting and retrieval . . . . . . . . . . . . . 28
6.1 Group and article selection . . . . . . . . . . . . . . 28 6.1 Group and article selection . . . . . . . . . . . . . . 28
6.1.1 GROUP . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1.1 GROUP . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.2 LAST . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.2 LAST . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.3 NEXT . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.1.3 NEXT . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2 Retrieval of articles and article sections . . . . . . . 34 6.2 Retrieval of articles and article sections . . . . . . . 34
6.2.1 ARTICLE . . . . . . . . . . . . . . . . . . . . . . . . 34 6.2.1 ARTICLE . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.2 HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.2.2 HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.3 BODY . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2.3 BODY . . . . . . . . . . . . . . . . . . . . . . . . . . 39
skipping to change at page 3, line 14 skipping to change at page 3, line 16
7. Information commands . . . . . . . . . . . . . . . . . . 49 7. Information commands . . . . . . . . . . . . . . . . . . 49
7.1 DATE . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.1 DATE . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2 HELP . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.2 HELP . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.3 NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . 50 7.3 NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . 50
7.4 NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . 52 7.4 NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . 52
7.5 Time . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.5 Time . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 53 7.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 53
7.6 The LIST commands . . . . . . . . . . . . . . . . . . . 54 7.6 The LIST commands . . . . . . . . . . . . . . . . . . . 54
7.6.1 LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . . 54 7.6.1 LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . . 54
7.6.2 LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . . 56 7.6.2 LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . . 56
7.6.3 LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . 57 7.6.3 LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . 58
7.6.4 LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . . 58 7.6.4 LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . . 59
7.6.5 LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . . 60 7.6.5 LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . . 60
8. Framework for NNTP extensions . . . . . . . . . . . . . 62 8. Framework for NNTP extensions . . . . . . . . . . . . . 62
8.1 Initial IANA registry . . . . . . . . . . . . . . . . . 64 8.1 Initial IANA registry . . . . . . . . . . . . . . . . . 64
8.2 Standard extensions . . . . . . . . . . . . . . . . . . 64 8.2 Standard extensions . . . . . . . . . . . . . . . . . . 64
8.3 The LISTGROUP extension . . . . . . . . . . . . . . . . 64 8.3 The LISTGROUP extension . . . . . . . . . . . . . . . . 64
8.3.1 LISTGROUP . . . . . . . . . . . . . . . . . . . . . . . 64 8.3.1 LISTGROUP . . . . . . . . . . . . . . . . . . . . . . . 65
8.4 Article metadata . . . . . . . . . . . . . . . . . . . . 66 8.4 Article metadata . . . . . . . . . . . . . . . . . . . . 66
8.4.1 The :bytes metadata item . . . . . . . . . . . . . . . . 67 8.4.1 The :bytes metadata item . . . . . . . . . . . . . . . . 67
8.4.2 The :lines metadata item . . . . . . . . . . . . . . . . 67 8.4.2 The :lines metadata item . . . . . . . . . . . . . . . . 67
8.5 The OVER extension . . . . . . . . . . . . . . . . . . . 67 8.5 The OVER extension . . . . . . . . . . . . . . . . . . . 67
8.5.1 OVER . . . . . . . . . . . . . . . . . . . . . . . . . . 68 8.5.1 OVER . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.5.2 LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . 72 8.5.2 LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . 73
8.6 The HDR extension . . . . . . . . . . . . . . . . . . . 74 8.6 The HDR extension . . . . . . . . . . . . . . . . . . . 75
8.6.1 HDR . . . . . . . . . . . . . . . . . . . . . . . . . . 74 8.6.1 HDR . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.6.2 LIST HEADERS . . . . . . . . . . . . . . . . . . . . . . 78 8.6.2 LIST HEADERS . . . . . . . . . . . . . . . . . . . . . . 79
9. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . 81 9. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . 83
9.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . 81 9.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . 83
9.2 Responses . . . . . . . . . . . . . . . . . . . . . . . 83 9.2 Responses . . . . . . . . . . . . . . . . . . . . . . . 85
9.3 Articles . . . . . . . . . . . . . . . . . . . . . . . . 83 9.3 Multi-line response contents . . . . . . . . . . . . . . 85
9.4 General non-terminals . . . . . . . . . . . . . . . . . 83 9.4 Articles . . . . . . . . . . . . . . . . . . . . . . . . 87
10. IANA Considerations . . . . . . . . . . . . . . . . . . 85 9.5 General non-terminals . . . . . . . . . . . . . . . . . 87
11. Security Considerations . . . . . . . . . . . . . . . . 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . 89
11.1 Personal and Proprietary Information . . . . . . . . . . 86 11. Security Considerations . . . . . . . . . . . . . . . . 90
11.2 Abuse of Server Log Information . . . . . . . . . . . . 86 11.1 Personal and Proprietary Information . . . . . . . . . . 90
11.3 Weak Authentication and Access Control . . . . . . . . . 86 11.2 Abuse of Server Log Information . . . . . . . . . . . . 90
11.4 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 87 11.3 Weak Authentication and Access Control . . . . . . . . . 90
11.5 UTF-8 issues . . . . . . . . . . . . . . . . . . . . . . 87 11.4 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 91
11.6 Caching of LIST EXTENSIONS results . . . . . . . . . . . 88 11.5 UTF-8 issues . . . . . . . . . . . . . . . . . . . . . . 91
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . 90 11.6 Caching of LIST EXTENSIONS results . . . . . . . . . . . 92
Normative References . . . . . . . . . . . . . . . . . . 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . 94
Informative References . . . . . . . . . . . . . . . . . 93 Normative References . . . . . . . . . . . . . . . . . . 96
Author's Address . . . . . . . . . . . . . . . . . . . . 93 Informative References . . . . . . . . . . . . . . . . . 97
A. Future Directions . . . . . . . . . . . . . . . . . . . 94 Author's Address . . . . . . . . . . . . . . . . . . . . 97
B. Interaction with other specifications . . . . . . . . . 95 A. Future Directions . . . . . . . . . . . . . . . . . . . 98
B.1 Header folding . . . . . . . . . . . . . . . . . . . . . 95 B. Interaction with other specifications . . . . . . . . . 99
B.2 Message-IDs . . . . . . . . . . . . . . . . . . . . . . 95 B.1 Header folding . . . . . . . . . . . . . . . . . . . . . 99
B.3 Article posting . . . . . . . . . . . . . . . . . . . . 96 B.2 Message-IDs . . . . . . . . . . . . . . . . . . . . . . 99
C. Summary of Response Codes . . . . . . . . . . . . . . . 98 B.3 Article posting . . . . . . . . . . . . . . . . . . . . 100
D. Formal specification of the standard extensions . . . . 103 C. Summary of Response Codes . . . . . . . . . . . . . . . 102
D.1 The LISTGROUP extension . . . . . . . . . . . . . . . . 103 D. Formal specification of the standard extensions . . . . 107
D.2 The OVER extension . . . . . . . . . . . . . . . . . . . 103 D.1 The LISTGROUP extension . . . . . . . . . . . . . . . . 107
D.3 The HDR extension . . . . . . . . . . . . . . . . . . . 104 D.2 The OVER extension . . . . . . . . . . . . . . . . . . . 107
Intellectual Property and Copyright Statements . . . . . 106 D.3 The HDR extension . . . . . . . . . . . . . . . . . . . 108
Intellectual Property and Copyright Statements . . . . . 110
1. Introduction 1. Introduction
This document specifies the Network News Transport Protocol (NNTP), This document specifies the Network News Transport 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 news of Netnews articles using a reliable stream-based mechanism. For news
reading clients, NNTP enables retrieval of news articles that are reading clients, NNTP enables retrieval of news articles that are
stored in a central database, giving subscribers the ability to 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. For server-to-server interaction, NNTP
is designed for efficient transmission of Netnews articles over a is designed for efficient transmission of Netnews articles over a
reliable full duplex communication channel. reliable full duplex 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 [RFC2279] instead of US-ASCII [ANSI1986]. It now requires to UTF-8 [RFC3629] instead of US-ASCII [ANSI1986]. It now requires
all articles to have a message-id, eliminating the "<0>" placeholder all articles to have a message-id, eliminating the "<0>" placeholder
used in RFC 977. It also extends the newsgroup name matching used in RFC 977. It also extends the newsgroup name matching
capabilities already documented in RFC 977. capabilities already documented in RFC 977.
Generally, new functionality is made available using new commands. A Generally, new functionality is made available using new commands. A
number of such commands (including some commands taken from RFC 2980 number of such commands (including some commands taken from RFC 2980
[RFC2980]) are now mandatory. Part of the new functionality involves [RFC2980]) are now mandatory. Part of the new functionality involves
a mechanism to discover what new functionality is available to a mechanism to discover what new functionality is available to
clients from a server. This mechanism can also be used to add more clients from a server. This mechanism can also be used to add more
functionality as needs merit such additions. functionality as needs merit such additions.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
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 running over TCP/IP, the official port for the NNTP
service is 119. When a client host wishes to make use of the service, service is 119. When a client host wishes to make use of the service,
it MUST establish a TCP connection with the server host by connecting it MUST establish a TCP connection with the server host by connecting
to that host on the same port on which the server is listening. When to that host on the same port on which the server is listening. When
the connection is established, the NNTP server host MUST send a the connection is established, the NNTP server host MUST send a
greeting. The client host and server host then exchange commands and greeting. The client host and server host then exchange commands and
responses (respectively) until the connection is closed or aborted. responses (respectively) until the connection is closed or aborted.
The character set for all NNTP commands is UTF-8 [RFC2279]. 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. Keywords MUST consist of
printable US-ASCII characters. Unless otherwise noted elsewhere in printable US-ASCII characters. Unless otherwise noted elsewhere in
this document, arguments SHOULD consist of printable US-ASCII this document, arguments SHOULD consist of printable US-ASCII
characters. Keywords and arguments MUST be each separated by one or characters. Keywords and arguments MUST be each separated by one or
more space or TAB characters. Keywords MUST be at least three more space or TAB characters. Keywords MUST be at least three
characters and MUST NOT exceed 12 characters. Command lines MUST NOT 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 limits arguments MUST NOT exceed 497 octets. A server MAY relax these limits
for commands defined in an extension. 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.
The term "character" means a single Unicode code point and
implementations are not required to carry out normalisation. Thus
U+0084 (A-dieresis) is one character while U+0041 U+0308 (A composed
with dieresis) is two; the two need not be treated as equivalent.
Commands may have variants, using a second keyword immediately after Commands may have variants, using a second keyword immediately after
the first to indicate which variant is required. The only such the first to indicate which variant is required. The only such
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 or be ignored by the server. Command and response arguments are case or
language specific only when stated, either in this document or in language specific only when stated, either in this document or in
skipping to change at page 10, line 36 skipping to change at page 10, line 42
1xx - Informative message. 1xx - Informative message.
2xx - Command completed OK. 2xx - Command completed OK.
3xx - Command OK so far; send the rest of it. 3xx - Command OK so far; send the rest of it.
4xx - Command was syntactically correct but failed for some 4xx - Command was syntactically correct but failed for some
reason. reason.
5xx - Command unknown, unsupported, unavailable, or syntax error. 5xx - Command unknown, unsupported, unavailable, or syntax error.
The next digit in the code indicates the function response category: The next digit in the code indicates the function response category:
x0x - Connection, setup, and miscellaneous messages x0x - Connection, set-up, and miscellaneous messages
x1x - Newsgroup selection x1x - Newsgroup selection
x2x - Article selection x2x - Article selection
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
skipping to change at page 15, line 42 skipping to change at page 15, line 46
end of the response is sent to the client. end of the response is sent to the client.
The initial connection must not be part of a pipeline; that is, the The initial connection must not be part of a pipeline; that is, the
client MUST NOT send any command until receiving the CRLF at the end client MUST NOT send any command until receiving the CRLF at the end
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. is typically 4k octets for TCP. (Since the server only sends data in
response to commands from the client, the converse problem does not
occur.)
3.3.1 Examples 3.3.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
skipping to change at page 16, line 47 skipping to change at page 17, line 8
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
empty. empty.
The headers of an article consist of one or more header lines. Each The headers of an article consist of one or more header lines. Each
header line consists of a header name, a colon, a space, the header header line consists of a header name, a colon, a space, the header
content, and a CRLF in that order. The name consists of one or more content, and a CRLF in that order. The name consists of one or more
printable US-ASCII characters other than colon and, for the purposes printable US-ASCII characters other than colon and, for the purposes
of this specification, is not case sensitive. There MAY be more than of this specification, is not case sensitive. There MAY be more than
one header line with the same name. The content MUST NOT contain CRLF one header line with the same name. The content MUST NOT contain
but is otherwise unrestricted; in particular, it MAY be empty. A CRLF; it MAY be empty. A header may be "folded"; that is, a CRLF pair
header may be "folded"; that is, a CRLF pair may be placed before any may be placed before any TAB or space in the line; there MUST still
TAB or space in the line; there MUST still be some other octet be some other octet between any two CRLF pairs in a header line.
between any two CRLF pairs in a header line. (Note that folding means (Note that folding means that the header line occupies more than one
that the header line occupies more than one line when displayed or line when displayed or transmitted; nevertheless it is still referred
transmitted; nevertheless it is still referred to as "a" header to as "a" header line.) The presence or absence of folding does not
line.) The presence or absence of folding does not affect the meaning affect the meaning of the header line; that is, the CRLF pairs
of the header line; that is, the CRLF pairs introduced by folding are introduced by folding are not considered part of the header content.
not considered part of the header value. Header lines SHOULD NOT be Header lines SHOULD NOT be folded before the space after the colon
folded before the space after the colon that follows the header name, that follows the header name, and SHOULD include at least one octet
and should include at least one octet other than %x09 or %x20 between other than %x09 or %x20 between CRLF pairs. However, if an article
CRLF pairs. However, if an article has been received from elsewhere has been received from elsewhere with one of these, clients and
with one of these, clients and servers MAY transfer it to the other servers MAY transfer it to the other without re-folding it.
without re-folding it.
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
to 255 in some other manner, it MAY pass it to a client without
modification. Therefore clients MUST be prepared to receive such
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
always UTF-8.
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 of an NNTP server MUST NOT have the same message-id. For the purposes of
this specification, message-ids are opaque strings that MUST meet the this specification, message-ids are opaque strings that MUST meet the
following requirements: 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.
skipping to change at page 17, line 35 skipping to change at page 17, line 51
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 synthesise one (this message-id from the article itself, it MUST synthesise 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). result). See also Appendix B.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
skipping to change at page 21, line 37 skipping to change at page 21, line 37
as a greeting to the client. This response informs the client whether as a greeting to the client. This response informs the client whether
service is available and whether the client is permitted to post. service is available and whether the client is permitted to post.
If the server will accept further commands from the client including If the server will accept further commands from the client including
POST, the server MUST present a 200 greeting code. If the server will POST, the server MUST present a 200 greeting code. If the server will
accept further commands from the client, but it is not authorized to accept further commands from the client, but it is not authorized to
post articles using the POST command, the server MUST present a 201 post articles using the POST command, the server MUST present a 201
greeting code. greeting code.
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. 502 MUST be used if the client is immediately close the connection. 400 SHOULD be used if the issue is
not permitted under any circumstances to interact with the server and only temporary (for example, because of load) and the client can
400 otherwise. 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
permitted under any circumstances to interact with the server, and
MAY be used if the server has insufficient information to determine
whether the issue is temporary or permanent.
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 setup 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 setup 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 setup 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 setup 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 MODE READER
5.2.1 Usage 5.2.1 Usage
This command MUST NOT be pipelined. This command MUST NOT be pipelined.
Syntax Syntax
skipping to change at page 25, line 44 skipping to change at page 25, line 50
include the extension in that situation. Similarly, if only some of include the extension in that situation. Similarly, if only some of
the commands in an extension will be available, or if the behaviour 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 of the extension will change in some other manner, before or after a
MODE READER command, this MUST be indicated by different arguments to MODE READER command, this MUST be indicated by different arguments to
the extension-label in the results of LIST EXTENSIONS in each the extension-label in the results of LIST EXTENSIONS in each
situation. situation.
While some extensions are likely to be always available or never While some extensions are likely to be always available or never
available, others will "appear" and "disappear" depending on server available, others will "appear" and "disappear" depending on server
state changes within the session or external events between sessions. state changes within the session or external events between sessions.
An NNTP client may cache the results of this command, but MUST NOT An NNTP client MAY cache the results of this command, but MUST NOT
rely on the correctness of any cached results, whether from earlier rely on the correctness of any cached results, whether from earlier
in this session or from a previous session, MUST cope gracefully with in this session or from a previous session, MUST cope gracefully with
the cached status being out of date, and SHOULD (if caching results) the cached status being out of date, and SHOULD (if caching results)
provide a way to force the cached information to be refreshed. provide a way to force the cached information to be refreshed.
Furthermore, a client MUST NOT use cached results in relation to Furthermore, a client MUST NOT use cached results in relation to
security, privacy, and authentication extensions. See Section 11.6 security, privacy, and authentication extensions. See Section 11.6
for further discussion of this topic. for further discussion of this topic.
The list of extensions is returned as a multi-line response following 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 202 response code. Each extension is listed on a separate line;
the line MUST begin with an extension-label and optionally one or the line MUST begin with an extension-label and optionally one or
more arguments (separated by single spaces). The extension-label and more arguments (separated by one or more spaces). The extension-label
the meaning of the arguments are specified as part of the definition and the meaning of the arguments are specified as part of the
of the extension. The extension-label is a string of 1 to 12 US-ASCII definition of the extension. The extension-label is a string of 1 to
letters and MUST be in uppercase. Arguments are strings of 1 or more 12 US-ASCII letters and MUST be in uppercase. Arguments are strings
printable UTF-8 characters (that is, either printable US-ASCII of 1 or more printable UTF-8 characters (that is, either printable
characters or any UTF-8 sequence outside the US-ASCII range, but not US-ASCII characters or any UTF-8 sequence outside the US-ASCII range,
space or TAB). but not space or TAB).
The server MUST NOT list the same extension twice in the response, The server MUST NOT list the same extension twice in the response,
and MUST list all supported extensions. The order in which the and MUST list all supported extensions. The order in which the
extensions are listed is not significant. The server need not even extensions are listed is not significant. The server need not even
consistently return the same order. If the server does not support consistently return the same order. If the server does not support
any extensions, it MUST return an empty list. The 402 response code any extensions, it MUST return an empty list. The 402 response code
is documented for historic reasons only; clients SHOULD handle it is documented for historic reasons only; clients SHOULD handle it
gracefully, but servers MUST NOT generate it. gracefully, but servers MUST NOT generate it.
Following a generic failure response, such as 403, an extension might Following a generic failure response, such as 403, an extension might
still be available, and the client MAY attempt to use it. still be available, and the client MAY attempt to use it.
5.3.3 Examples 5.3.3 Examples
Example of a successful response: Example of a successful response:
[C] LIST EXTENSIONS [C] LIST EXTENSIONS
[S] 202 Extensions supported: [S] 202 Extensions supported:
[S] OVER [S] OVER MSGID
[S] HDR [S] HDR
[S] LISTGROUP [S] LISTGROUP
[S] . [S] .
The particular extensions shown here are simply examples of what The particular extensions shown here are simply examples of what
might be defined in other places, and no particular meaning should be might be defined in other places, and no particular meaning should be
attributed to them. attributed to them.
Example where no extensions are available: Example where no extensions are available:
skipping to change at page 28, line 25 skipping to change at page 28, line 25
there may be multiple keys that point to the same article on the same there may be multiple keys that point to the same article on the same
server. The final key is the arrival timestamp, giving the time that server. The final key is the arrival timestamp, giving the time that
the article arrived at the server. the article arrived at the server.
The server MUST ensure that article numbers are issued in order of The server MUST ensure that article numbers are issued in order of
arrival timestamp; that is, articles arriving later MUST have higher arrival timestamp; that is, articles arriving later MUST have higher
numbers than those that arrive earlier. The server SHOULD allocate numbers than those that arrive earlier. The server SHOULD allocate
the next sequential unused number to each new article. the next sequential unused number to each new article.
Article numbers MUST lie between 1 and 4,294,967,295 inclusive. The Article numbers MUST lie between 1 and 4,294,967,295 inclusive. The
client and server SHOULD NOT use leading zeroes in specifying article client and server MAY use leading zeroes in specifying article
numbers, and MUST NOT use more than 16 digits. In some situations, numbers, but MUST NOT use more than 16 digits. In some situations,
the value zero replaces an article number to show some special the value zero replaces an article number to show some special
situation. situation.
6.1 Group and article selection 6.1 Group and article selection
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".
skipping to change at page 29, line 51 skipping to change at page 29, line 51
o articles may be removed from the group o articles may be removed from the group
o articles may be reinstated in the group with the same article o articles may be reinstated in the group with the same article
number, but those articles MUST have numbers no less than the number, but those articles MUST have numbers no less than the
reported low water mark (note that this is a reinstatement of the reported low water mark (note that this is a reinstatement of the
previous article, not a new article reusing the number) previous article, not a new article reusing the number)
o new articles may be added with article numbers greater than the o new articles may be added with article numbers greater than the
reported high water mark (if an article that was the one with the reported high water mark (if an article that was the one with the
highest number has been removed, the next new article will not highest number has been removed and the high water mark adjusted
have the number one greater than the reported high water mark) accordingly, the next new article will not have the number one
greater than the reported high water mark)
Except when the group is empty and all three numbers are zero, Except when the group is empty and all three numbers are zero,
whenever a subsequent GROUP command for the same newsgroup is issued, whenever a subsequent GROUP command for the same newsgroup is issued,
either by the same client or a different client, the reported low either by the same client or a different client, the reported low
water mark in the response MUST be no less than that in any previous water mark in the response MUST be no less than that in any previous
response for that newsgroup sent to any client. The client may make response for that newsgroup in any session, and SHOULD be no less
use of the low water mark to remove all remembered information about than that in any previous response for that newsgroup ever sent to
articles with lower numbers, as these will never recur. This includes any client. Any failure to meet the latter condition SHOULD be
the situation when the high water mark is one less than the low water transient only. The client may make use of the low water mark to
mark. No similar assumption can be made about the high water mark, as remove all remembered information about articles with lower numbers,
this can decrease if an article is removed, and then increase again as these will never recur. This includes the situation when the high
if it is reinstated or if new articles arrive. water mark is one less than the low water mark. No similar assumption
can be made about the high water mark, as this can decrease if an
article is removed, and then increase again if it is 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 command (or the LISTGROUP command, if implemented) MUST be
used by a client and a successful response received before any other used by a client and a successful response received before any other
skipping to change at page 39, line 16 skipping to change at page 39, line 22
[S] 430 No Such Article Found [S] 430 No Such Article Found
Example of an unsuccessful retrieval of the headers of an article by Example of an unsuccessful retrieval of the headers of an article by
number: number:
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] HEAD 300256 [C] HEAD 300256
[S] 423 No such article number in this group [S] 423 No such article number in this group
Example of an unsuccessful retrieval the headers of an article by Example of an unsuccessful retrieval of the headers of an article by
number because no newsgroup was selected first: number because no newsgroup was selected first:
[Assumes current selected newsgroup is invalid.] [Assumes current selected newsgroup is invalid.]
[C] HEAD 300256 [C] HEAD 300256
[S] 412 No newsgroup selected [S] 412 No newsgroup selected
Example of an attempt to retrieve the headers of an article when the Example of an attempt to retrieve the headers 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
skipping to change at page 42, line 29 skipping to change at page 42, line 29
6.2.4.3 Examples 6.2.4.3 Examples
Example of STAT on an existing article (using no article number): Example of STAT on an existing 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] STAT [C] STAT
[S] 223 3000234 <45223423@example.com> [S] 223 3000234 <45223423@example.com>
Example of a STAT of an existing article by message-id: Example of STAT on an existing article by message-id:
[C] STAT <45223423@example.com> [C] STAT <45223423@example.com>
[S] 223 0 <45223423@example.com> [S] 223 0 <45223423@example.com>
Example of an STAT of an article not on the server by message-id: Example of STAT on an article not on the server by message-id:
[C] STAT <i.am.not.there@example.com> [C] STAT <i.am.not.there@example.com>
[S] 430 No Such Article Found [S] 430 No Such Article Found
Example of STAT of an article not in the server by number: Example of STAT on an article not in the server by number:
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] STAT 300256 [C] STAT 300256
[S] 423 No such article number in this group [S] 423 No such article number in this group
Example of STAT of an article by number when no newsgroup was Example of STAT on an article by number when no newsgroup was
selected first: selected first:
[Assumes current selected newsgroup is invalid.] [Assumes current selected newsgroup is invalid.]
[C] STAT 300256 [C] STAT 300256
[S] 412 No newsgroup selected [S] 412 No newsgroup selected
Example of STAT of an article when the current selected newsgroup is Example of STAT on an article when the current selected newsgroup is
empty: 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] STAT [C] STAT
[S] 420 No current article selected [S] 420 No current article selected
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 modes: individual article
skipping to change at page 43, line 48 skipping to change at page 43, line 48
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.4 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 following in direct response to the POST command. Others are returned following
the sending of the article. the sending of the article.
A response of 240 SHOULD indicate that, barring unforseen 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 and/
or transferred to other servers as appropriate, possibly following or transferred to other servers as appropriate, possibly following
further processing. In other words, articles not wanted by the server further processing. In other words, articles not wanted by the server
SHOULD be rejected with a 441 response and not accepted and silently SHOULD be rejected with a 441 response and not accepted and silently
discarded. However, the client SHOULD NOT assume that the article has discarded. However, the client SHOULD NOT assume that the article has
been successfully transferred unless it receives an affirmative been successfully transferred unless it receives an affirmative
response from the server, and SHOULD NOT assume that it is being made response from the server, and SHOULD NOT assume that it is being made
available to other clients without explicitly checking (for example available to other clients without explicitly checking (for example
using the STAT command). using the STAT command).
skipping to change at page 51, line 41 skipping to change at page 51, line 41
Clients SHOULD make all queries using Coordinated Universal Time Clients SHOULD make all queries using Coordinated Universal Time
(i.e. by including the "GMT" argument) when possible. (i.e. by including the "GMT" argument) when possible.
7.3.3 Examples 7.3.3 Examples
Example where there are new groups: Example where there are 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] alt.fc-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] .
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
skipping to change at page 53, line 12 skipping to change at page 53, line 12
[C] NEWNEWS alt.* 19990624 000000 GMT [C] NEWNEWS alt.* 19990624 000000 GMT
[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
reponses. responses.
The DATE command MUST return a timestamp from the same clock as is The DATE command MUST return a timestamp from the same clock as is
used for determining article arrival and group creation times. This used for determining article arrival and group creation times. This
clock SHOULD be monotonic, and adjustments SHOULD be made by running clock SHOULD be monotonic, and adjustments SHOULD be made by running
it fast or slow compared to "real" time rather than by making sudden it fast or slow compared to "real" time rather than by making sudden
jumps. 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:
skipping to change at page 55, line 6 skipping to change at page 55, line 6
where: where:
"group" is the name of the newsgroup; "group" is the name of the newsgroup;
"high" is the reported high water mark for the group; "high" is the reported high water mark for the group;
"low" is the reported low 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. "status" is the current status of the group on this server.
Each field in the line is separated from its neighboring fields by 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 one or more spaces.
response, and indicates that there are currently no valid newsgroups.
Note that an empty list is a possible valid response, and indicates
that there are currently no valid newsgroups.
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
skipping to change at page 55, line 48 skipping to change at page 55, line 50
altering the effect of the command. altering the effect of the command.
7.6.1.3 Examples 7.6.1.3 Examples
Example of LIST ACTIVE returning a list of newsgroups: 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.fc-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:
[C] LIST ACTIVE
[S] 215 list of newsgroups follows
[S] misc.test 0003002322 0003000234 y
[S] comp.risks 0000442001 0000441099 m
[S] alt.rfc-writers.recovery 0000000004 0000000001 y
[S] tx.natives.recovery 0000000089 0000000056 y
[S] tx.natives.recovery.d 0000000011 0000000009 n
[S] .
Example of LIST ACTIVE omitting the second keyword and returning no Example of LIST ACTIVE omitting the second keyword and returning no
newsgroups: newsgroups:
[C] LIST [C] LIST
[S] 215 list of newsgroups follows [S] 215 list of newsgroups follows
[S] . [S] .
Example of LIST ACTIVE with a wildmat: 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.fc-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.2 LIST ACTIVE.TIMES
7.6.2.1 Usage 7.6.2.1 Usage
This command is optional. This command is optional.
Syntax Syntax
skipping to change at page 57, line 10 skipping to change at page 57, line 27
The list MAY omit newsgroups for which the information is unavailable The list MAY omit newsgroups for which the information is unavailable
and MAY include groups not available on the server; in particular, it 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 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 entry. The client MUST NOT assume that the list is complete or that
it matches the list returned by LIST ACTIVE. The NEWGROUPS command it matches the list returned by LIST ACTIVE. The NEWGROUPS command
(Section 7.3) may provide a better way to access this information and (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 the results of the two commands SHOULD be consistent (subject to the
caveats in the description of that command). caveats in the description of that command).
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 215 response code. 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.
If the optional wildmat argument is specified, the response is Note that an empty list is a possible valid response (whether or not
limited to only the groups (if any) whose names match the wildmat and a wildmat is specified) and indicates that there are no groups
for which the information is available. Note that an empty list is a meeting the above criteria.
possible valid response (whether or not a wildmat is specified) and
indicates that there are no such groups.
7.6.2.3 Examples 7.6.2.3 Examples
Example of LIST ACTIVE.TIMES returning a list of newsgroups: 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>
skipping to change at page 60, line 37 skipping to change at page 61, line 4
more space or TAB characters (usual practice is a single TAB). The 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 first field is the name of the newsgroup and the second is a short
description of the group. description of the group.
The list MAY omit newsgroups for which the information is unavailable The list MAY omit newsgroups for which the information is unavailable
and MAY include groups not available on the server. The client MUST 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 NOT assume that the list is complete or that it matches the list
returned by LIST ACTIVE. returned by LIST ACTIVE.
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 215 response code. 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.
If the optional wildmat argument is specified, the response is Note that an empty list is a possible valid response (whether or not
limited to only the groups (if any) whose names match the wildmat and a wildmat is specified) and indicates that there are no groups
for which the information is available. Note that an empty list is a meeting the above criteria.
possible valid response (whether or not a wildmat is specified) and
indicates that there are no such groups.
7.6.5.3 Examples 7.6.5.3 Examples
Example of LIST NEWSGROUPS returning a list of newsgroups: 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
skipping to change at page 63, line 28 skipping to change at page 63, line 28
o the syntax and possible values of arguments associated with the o the syntax and possible values of arguments associated with the
new NNTP commands; new NNTP commands;
o the response codes and possible values of arguments for the o the response codes and possible values of arguments for the
responses of the new NNTP commands; responses of the new NNTP commands;
o any new arguments the extension associates with any other o any new arguments the extension associates with any other
pre-existing NNTP commands; pre-existing NNTP commands;
o how support for the extension affects the behavior of a server and o how support for the extension affects the behaviour of a server
NNTP client; and NNTP client;
o any increase in the maximum length of commands and initial o any increase in the maximum length of commands and initial
response lines over the value specified in this document; response lines over the value specified in this document;
o a specific statement about the effect on pipelining this extension o a specific statement about the effect on pipelining this extension
may have (if any); may have (if any);
o a specific statement about the circumstances when use of this o a specific statement about the circumstances when use of this
extension can alter the output from LIST EXTENSIONS; extension can alter the output from LIST EXTENSIONS;
skipping to change at page 66, line 42 skipping to change at page 66, line 45
[C] GROUP example.is.sob.bradner.or.barber [C] GROUP example.is.sob.bradner.or.barber
[S] 411 no such group [S] 411 no such group
[C] LISTGROUP [C] LISTGROUP
[S] 412 no current group [S] 412 no current group
8.4 Article metadata 8.4 Article metadata
The OVER and HDR extensions refer to the concept of "article The OVER and HDR extensions refer to the concept of "article
metadata". This is data about articles that does not occur within the metadata". This is data about articles that does not occur within the
article itself. Each metadata item has a name which MUST begin with a article itself. Each metadata item has a name which MUST begin with a
colon (and which MUST NOT contain a colon elsewhere within it). colon (and which MUST NOT contain a colon elsewhere within it). As
with header names, metadata item names are not case sensistive.
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.) 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
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.4.1 The :bytes metadata item
The :bytes metadata item for an article is a decimal integer. It MUST The :bytes metadata item for an article is a decimal integer. It
equal the number of octets in the entire article - headers, body, and SHOULD equal the number of octets in the entire article - headers,
separating empty line - except that each CRLF pair MAY (but SHOULD body, and separating empty line (counting a CRLF pair as two octets,
NOT) be counted as a single octet. and not including either the "." CRLF terminating the response nor
any "." added for "byte-stuffing" purposes).
Note to client implementers: some existing servers return a value
different to that above. The commonest reasons for this are:
o counting a CRLF pair as one octet;
o including the "." character used for byte-stuffing in the number;
o including the terminating "." CRLF in the number;
o using one copy of an article for counting the octets but then
returning another one that differs in some (permitted) manner.
Implementations should be prepared for such variation and MUST NOT
rely on the value being accurate.
8.4.2 The :lines metadata item 8.4.2 The :lines metadata item
The :lines metadata item for an article is a decimal integer. It MUST The :lines metadata item for an article is a decimal integer. It MUST
equal the number of lines in the article body (excluding the empty equal the number of lines in the article body (excluding the empty
line separating headers and body); equivalently, it is two less than line separating headers and body); equivalently, it is two less than
the number of CRLF pairs that the BODY command would return for that the number of CRLF pairs that the BODY command would return for that
article (the extra two are those following the response code and the article (the extra two are those following the response code and the
termination octet). termination octet).
8.5 The OVER extension 8.5 The OVER extension
This extension provides two commands, OVER and LIST OVERVIEW.FMT. The This extension provides two commands, OVER and LIST OVERVIEW.FMT. The
label for this extension is OVER. label for this extension is OVER.
The OVER extension provides access to the "overview database", which The OVER extension provides access to the "overview database", which
is a database of headers extracted from incoming articles. Only is a database of headers extracted from incoming articles. Only
certain headers are included in the database. The database also certain headers are included in the database. The database also
includes some article metadata. The information stored in the includes some article metadata.
database may change over time. If the database records the content or
absence of a given field (that is, a header or metadata item) for all The information stored in the database may change over time. If the
articles, it is said to be "consistent" for that field. If it records database records the content or absence of a given field (that is, a
the content of a header for some articles but not for others that header or metadata item) for all articles, it is said to be
nevertheless included that header, or records a metadata item for "consistent" for that field. If it records the content of a header
some articles but not others to which that item applies, it is said for some articles but not for others that nevertheless included that
to be "inconsistent" for that field. 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
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
inconsistent or which are not stored in the database. Therefore if a inconsistent or which are not stored in the database. Therefore if a
header appears in the LIST OVERVIEW.FMT output but not the OVER header appears in the LIST OVERVIEW.FMT output but not the OVER
output for a given article, that header does not appear in the output for a given article, that header does not appear in the
article, and similarly for metadata items. article, and similarly for metadata items.
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 the articles remaining are those received since the change. Therefore the
output from LIST OVERVIEW.FMT needs to be altered twice: before any output from LIST OVERVIEW.FMT needs to be altered twice: before any
fields stop being stored, they MUST be removed from the output, then fields stop being stored, they MUST be removed from the output, then
when the database is once more known to be consistent, the new fields when the database is once more known to be consistent, the new fields
SHOULD be added to the output. SHOULD be added to the output.
Support for the message-id form of the OVER command is optional. If
an implementation supports this form, it MUST use the argument
"MSGID" following the extension label in the output of LIST
EXTENSIONS; if not, it MUST NOT use any argument.
This extension is based on the Overview/NOV database [ROBE1995] This extension is based on the Overview/NOV database [ROBE1995]
developed by Geoff Collyer. developed by Geoff Collyer.
8.5.1 OVER 8.5.1 OVER
8.5.1.1 Usage 8.5.1.1 Usage
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
skipping to change at page 69, line 16 skipping to change at page 69, line 46
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. Support
for the first (message-id) form is optional. If it is not supported,
the generic response code 503 MUST be returned.
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 71, line 8 skipping to change at page 71, line 41
[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
[S] 202 extensions supported:
[S] OVER MSGID
[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
retrieval by message-id:
[C] LIST EXTENSIONS
[S] 202 extensions supported:
[S] OVER
[S] .
[C] OVER <45223423@example.com>
[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
[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|
skipping to change at page 72, line 35 skipping to change at page 73, line 34
215 Information follows (multiline) 215 Information follows (multiline)
8.5.2.2 Description 8.5.2.2 Description
The LIST OVERVIEW.FMT command returns a description of the fields in The LIST OVERVIEW.FMT command returns a description of the fields in
the database for which it is consistent (as described above). the database for which it is consistent (as described above).
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 215 response code. The information contains response following the 215 response code. The information contains
one line per field in the order they are returned by the OVER one line per field in the order they are returned by the OVER
command; the first 7 lines MUST be exactly: 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 73, line 13 skipping to change at page 74, line 13
Lines: Lines:
even though they refer to metadata, not headers. even though they refer to metadata, not headers.
All subsequent lines MUST consist of either a header name followed by All subsequent lines MUST consist of either a header name followed by
":full", or the name of a piece of metadata. ":full", or the name of a piece of metadata.
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 is a reminder that the corresponding OVER output. The "full" suffix (which may use either uppercase,
fields include the header name. lowercase, or a mix) is a reminder that the corresponding fields
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.5.2.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
skipping to change at page 73, line 49 skipping to change at page 74, line 50
[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:
[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 Example of LIST OVERVIEW.FMT returning an error where the command is
recognised but the software does not maintain this information: recognised but the software does not maintain this information:
[C] LIST OVERVIEW.FMT [C] LIST OVERVIEW.FMT
[S] 503 overview.fmt not available [S] 503 overview.fmt not available
8.6 The HDR extension 8.6 The HDR extension
This extension provides two new commands: HDR and LIST HEADERS. The This extension provides two new commands: HDR and LIST HEADERS. The
label for this extension is HDR. label for this extension is HDR.
The HDR extension provides access to specific headers and metadata The HDR extension provides access to specific headers and metadata
items (collectively "fields") of articles or groups of articles. In items (collectively "fields") of articles or groups of articles. In
the case of headers, an implementation MAY restrict the use of this 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 extension to a specific list of headers or MAY allow it to be used
with any header. In the latter case it MUST use the argument "ALL" with any header; it may behave differently when the HDR command is
following the extension label in the output of LIST EXTENSIONS; in used with a message-id argument and when it is used with a range or
the former case it MUST NOT use any argument. no argument.
The HDR command may take information from a database rather than The HDR command may take information from a database rather than
directly from the articles. If so, the same issues of consistency and directly from the articles. If so, the same issues of consistency and
inconsistency apply as with the OVER extension (Section 8.5) and the inconsistency apply as with the OVER extension (Section 8.5) and the
LIST HEADERS command SHOULD take the same approach as the LIST LIST HEADERS command SHOULD take the same approach as the LIST
OVERVIEW.FMT command in resolving them. OVERVIEW.FMT command in resolving them.
8.6.1 HDR 8.6.1 HDR
8.6.1.1 Usage 8.6.1.1 Usage
skipping to change at page 75, line 42 skipping to change at page 76, line 42
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 where the relevant header line or metadata item exists each article in the range that exists (note that unless the argument
(note that unless the argument is a range including a dash, there is a range including a dash, there will be at most one line but it
will be at most one line but it will still be in multi-line format). will still be in multi-line format). The line consists of the article
The line consists of the article number, a space, and then the number, a space, and then the contents of the header or metadata
contents of the header (without the header name or the colon and item. In the case of a header, the header name, colon, and the first
space that follow it) or metadata item. If the article is specified space after the colon are all omitted. If the article is specified by
by message-id, the article number is given as "0". message-id, the article number is given as "0".
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 extension
(Section 8.5.1.2), and the same comment concerning NUL, CR, and LF (Section 8.5.1.2), and the same comment concerning NUL, CR, and LF
applies). applies).
The header content is in all cases taken from the article. This means The header content is in all cases taken from the article. This means
that, for example, a request for the header "Lines" returns the that, for example, a request for the header "Lines" returns the
contents of the "Lines" header of the specified articles, if any, not contents of the "Lines" header of the specified articles, if any, not
skipping to change at page 76, line 33 skipping to change at page 77, line 33
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 is newsgroup, a 423 response MUST be returned. If the second argument is
omitted and the current article number is invalid, a 420 response 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 headers and
metadata items. If so, it MUST respond with the generic 503 response metadata items; it may behave differently in this respect for the
to attempts to request other headers, rather than returning erroneous first (message-id) form than for the other forms. If so, it MUST
results such as a successful empty response. respond with the generic 503 response to attempts to request other
headers, rather than returning erroneous results such as a successful
empty response.
If HDR uses a separate database and it is inconsistent for the If HDR uses a separate database and it is inconsistent for the
requested header or metadata item, the server MAY return what results requested header or metadata item, the server MAY return what results
it can or it MAY respond with the generic 503 response; in the latter it can or it MAY respond with the generic 503 response; in the latter
case, the field MUST NOT appear in the output from LIST HEADERS. case, the field MUST NOT appear in the output from LIST HEADERS.
8.6.1.3 Examples 8.6.1.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):
skipping to change at page 78, line 28 skipping to change at page 79, line 30
[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.2 LIST HEADERS
8.6.2.1 Usage 8.6.2.1 Usage
Syntax Syntax
LIST HEADERS LIST HEADERS [MSGID|RANGE]
Responses Responses
215 Header and metadata list follows (multiline) 215 Header and metadata list follows (multiline)
Parameters
MSGID = requests list for access by message-id
RANGE = requests list for access by range
8.6.2.2 Description 8.6.2.2 Description
The LIST HEADERS command returns a list of headers and metadata items The LIST HEADERS command returns a list of headers and metadata items
that may be retrieved using the HDR command. 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 header or metadata
item name (excluding the colon in the former case). If the item name (excluding the colon in the former case). If the
implementation allows any header to be retrieved (also indicated by implementation allows any header to be retrieved, it MUST NOT include
the "ALL" argument to the extension label) it MUST NOT include any any header names in the list but MUST include the special entry ":"
header names in the list but MUST include the special entry ":" (a (a single colon on its own); it MUST still list any metadata items
single colon on its own); it MUST still list any metadata items that that are available. The order of items in the list is not
are available. The order of items in the list is not significant; the significant; the server need not even consistently return the same
server need not even consistently return the same order. The list MAY order. The list MAY be empty (though in this circumstance there is
be empty (though in this circumstance there is little point in little point in providing the extension).
providing the extension).
An implementation that also supports the OVER extension SHOULD at An implementation that also supports the OVER extension SHOULD at
least permit all the headers and metadata items listed in the output least permit all the headers and metadata items listed in the output
from the LIST OVERVIEW.FMT command. from the LIST OVERVIEW.FMT command.
If the server treats the first form of the HDR command (message-id
specified) differently to the other two forms (range specified or
current article number used) in respect of which headers or metadata
items are available, then:
o if the MSGID argument is specified, the results MUST be those
available for the first form of the HDR command;
o if the RANGE argument is specified, the results MUST be those
available for the second and third forms of the HDR command;
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
items listed in both the previous cases).
If the server does not treat the various forms differently, then it
MUST always produce the same results and ignore any argument.
8.6.2.3 Examples 8.6.2.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 EXTENSIONS
[S] 202 extensions supported:
[S] HDR
[S] .
[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.5.2.3:
skipping to change at page 79, line 47 skipping to change at page 81, line 16
[S] Message-ID [S] Message-ID
[S] References [S] References
[S] Subject [S] Subject
[S] Xref [S] Xref
[S] :bytes [S] :bytes
[S] :lines [S] :lines
[S] . [S] .
Example of an implementation providing access to all headers: Example of an implementation providing access to all headers:
[C] LIST EXTENSIONS
[S] 202 extensions supported:
[S] HDR ALL
[S] .
[C] LIST HEADERS [C] LIST HEADERS
[S] 215 metadata items supported: [S] 215 metadata items supported:
[S] :
[S] :lines
[S] :bytes
[S] :x-article-number
[S] .
Example of an implementation distinguishing the first form of the HDR
command from the other two forms:
[C] LIST HEADERS RANGE
[S] 215 metadata items supported:
[S] : [S] :
[S] :lines [S] :lines
[S] :bytes [S] :bytes
[S] .
[C] LIST HEADERS MSGID
[S] 215 headers and metadata items supported:
[S] Date
[S] Distribution
[S] From
[S] Message-ID
[S] References
[S] Subject
[S] :lines
[S] :bytes
[S] :x-article-number [S] :x-article-number
[S] . [S] .
[C] LIST HEADERS
[S] 215 headers and metadata items supported:
[S] Date
[S] Distribution
[S] From
[S] Message-ID
[S] References
[S] Subject
[S] :lines
[S] :bytes
[S] .
Note how :x-article-number does not appear in the last set of output.
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 in case insensitive. Non-terminals used in several places are defined in
a separate section at the end. a separate section at the end.
9.1 Commands 9.1 Commands
This syntax defines the non-terminal "command-line", which This syntax defines the non-terminal "command-line", which represents
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 = article-command /
body-command / body-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 /
skipping to change at page 82, line 13 skipping to change at page 84, line 13
hdr-command = "HDR" WS header-meta-name [range-ref] hdr-command = "HDR" WS header-meta-name [range-ref]
head-command = "HEAD" [article-ref] head-command = "HEAD" [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-active-command = "LIST" [WS "ACTIVE" [WS wildmat]]
list-active-times-command = "LIST" WS "ACTIVE.TIMES" [WS wildmat] list-active-times-command = "LIST" WS "ACTIVE.TIMES" [WS wildmat]
list-distrib-pats-command = "LIST" WS "DISTRIB.PATS" list-distrib-pats-command = "LIST" WS "DISTRIB.PATS"
list-distributions-command = "LIST" WS "DISTRIBUTIONS" list-distributions-command = "LIST" WS "DISTRIBUTIONS"
list-extensions-command = "LIST" WS "EXTENSIONS" list-extensions-command = "LIST" WS "EXTENSIONS"
list-headers-command = "LIST" WS "HEADERS" list-headers-command = "LIST" WS "HEADERS" WS ["MSGID" / "RANGE"]
list-newsgroups-command = "LIST" WS "NEWSGROUPS" [WS wildmat] list-newsgroups-command = "LIST" WS "NEWSGROUPS" [WS wildmat]
list-overview-fmt-command = "LIST" WS "OVERVIEW.FMT" 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" [article-ref]
x-command = x-command-name *(WS x-argument) x-command = x-command-name *(WS x-argument)
; Each extension command is specified fully elsewhere ; Each extension command is specified fully elsewhere
article-ref = WS (article-number / message-id) article-ref = WS (article-number / message-id)
article-number = 1*16DIGIT
date = [2DIGIT] 6DIGIT date = [2DIGIT] 6DIGIT
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
metadata-name = ":" 1*A-NOTCOLON metadata-name = ":" 1*A-NOTCOLON
newsgroup-name = 1*wildmat-exact newsgroup-name = 1*wildmat-exact
range = article-number ["-" [article-number]] range = article-number ["-" [article-number]]
range-ref = WS (range / message-id) range-ref = WS (range / message-id)
time = 6DIGIT time = 6DIGIT
x-command-name = 3*12A-CHAR x-command-name = 3*12A-CHAR
x-argument = 1*P-CHAR x-argument = 1*P-CHAR
skipping to change at page 83, line 21 skipping to change at page 85, line 21
multiline-response = simple-response *content-line termination multiline-response = simple-response *content-line termination
termination = "." CRLF termination = "." CRLF
content-line = [content-text] CRLF content-line = [content-text] CRLF
content-text = (".." / B-NONDOT) *B-CHAR content-text = (".." / B-NONDOT) *B-CHAR
simple-response = 3DIGIT arguments [ SP trailing-comment ] CRLF simple-response = 3DIGIT arguments [ SP trailing-comment ] CRLF
trailing-comment = *U-CHAR trailing-comment = *U-CHAR
arguments = *( SP argument ) ; How many depends on the response arguments = *( SP argument ) ; How many depends on the response
argument = 1*A-CHAR argument = 1*A-CHAR
9.3 Articles 9.3 Multi-line response contents
This syntax defines the content of the various multi-line responses,
in each case after any "dot-stuffing" has been undone.
multiline-response-content: article-response /
body-response /
hdr-response /
head-response /
help-response /
list-active-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 /
newgroups-response /
newnews-response /
over-response
article-response = article
body-response = body
hdr-response = *(article-number SP hdr-content CRLF)
head-response = 1*header
help-response = *(*B-CHAR CRLF)
list-active-response = *(newsgroup-name SPA article-number
SPA article-number SPA newsgroup-status CRLF)
list-active-times-response =
*(newsgroup-name SPA 1*DIGIT SPA newsgroup-creator CRLF)
list-distrib-pats-response =
*(1*DIGIT ":" wildmat ":" distribution CRLF)
list-distributions-response =
*(distribution SPA distribution-description CRLF)
list-extensions-response =
*(extension-label *(SPA extension-argument) CRLF)
list-headers-response = *(header-meta-name CRLF) /
*((metadata-name / ":") CRLF)
list-newsgroups-response =
*(newsgroup-name WS newsgroup-description CRLF)
list-overview-fmt-response = list-overview-fmt-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 =
"Subject:" CRLF
"From:" CRLF
"Date:" CRLF
"Message-ID:" CRLF
"References:" CRLF
( ":bytes" CRLF ":lines" / "Bytes:" CRLF "Lines:") CRLF
*((header-name ":full" / metadata-name) CRLF)
distribution = 1*P-CHAR
distribution-description = U-TEXT
extension-argument = 1*P-CHAR
extension-label = 1*12UPPER
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 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.4.
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 = *( P-CHAR / [CRLF] WS ) header-content = *(S-CHAR / [CRLF] WS)
body = *(*B-CHAR CRLF) body = *(*B-CHAR CRLF)
9.4 General non-terminals 9.5 General non-terminals
article-number = 1*16DIGIT
header-name = 1*A-NOTCOLON header-name = 1*A-NOTCOLON
message-id = "<" 1*248A-NOTGT ">" message-id = "<" 1*248A-NOTGT ">"
; Assorted special character sets ; Assorted special character sets
; A- means based on ASCII, excluding controls and SP ; A- means based on ASCII, excluding controls and SP
; P- means based on UTF-8, excluding controls and SP ; P- means based on UTF-8, excluding controls and SP
; U- means based on UTF-8, excluding NUL CR and LF ; U- means based on UTF-8, excluding NUL CR and LF
; B- means based on bytes, excluding NUL CR and LF ; B- means based on bytes, excluding NUL CR and LF
A-CHAR = %x21-7E A-CHAR = %x21-7E
A-NOTCOLON = %x21-39 / %x3B-7E ; exclude ":" A-NOTCOLON = %x21-39 / %x3B-7E ; exclude ":"
A-NOTGT = %x21-3D / %x3F-7E ; exclude ">" A-NOTGT = %x21-3D / %x3F-7E ; exclude ">"
P-CHAR = A-CHAR / UTF8-non-ascii P-CHAR = A-CHAR / UTF8-non-ascii
U-CHAR = %x01-09 / %x0B-0C / %x0E-7F / UTF8-non-ascii U-CHAR = CTRL / TAB / SP / A-CHAR / UTF8-non-ascii
B-CHAR = %x01-09 / %x0B-0C / %x0E-FF U-NONTAB = CTRL / SP / A-CHAR / UTF8-non-ascii
B-NONDOT = %x01-09 / %x0B-0C / %x0E-2D / %x2F-FF ; exclude "." U-TEXT = P-CHAR *U-CHAR
B-CHAR = CTRL / TAB / SP / %x21-FF
B-NONDOT = CTRL / TAB / SP / %x21-2D / %x2F-FF ; exclude "."
CR = %x0D CR = %x0D
CRLF = CR LF CRLF = CR LF
CTRL = %x01-08 / %x0B-0C / %x0E-1F
DIGIT = %x30-39 DIGIT = %x30-39
EOL = *(SP / HT) CRLF EOL = *(SP / TAB) CRLF
HT = %x09
LF = %x0A LF = %x0A
SP = %x20 SP = %x20
SPA = 1*SP
TAB = %x09
UPPER = %41-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 /
%xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail %xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail
UTF8-4 = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail / UTF8-4 = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail /
%xF4 %x80-8F 2UTF8-tail %xF4 %x80-8F 2UTF8-tail
UTF8-tail = %x80-BF UTF8-tail = %x80-BF
WS = 1*(SP / HT) WS = 1*(SP / TAB)
The following non-terminals require special consideration. They
represent situations where material SHOULD be restricted to UTF-8,
but implementations MUST be able to cope with other character
encodings. Therefore there are two sets of definitions for them.
Implementations MUST accept any content that meets this syntax:
S-CHAR = %x21-FF
S-NONTAB = CTRL / SP / S-CHAR
S-TEXT = (CTRL / S-CHAR) *B-CHAR
Implementations SHOULD only generate content that meets this syntax:
S-CHAR = P-CHAR
S-NONTAB = U-NONTAB
S-TEXT = U-TEXT
10. IANA Considerations 10. IANA Considerations
This specification requires IANA to keep a registry of This specification requires IANA to keep a registry of
extension-labels. The initial contents of this registry are specified extension-labels. The initial contents of this registry are specified
in Section 8.1. As described in Section 8, names beginning with X are in Section 8.1. As described in Section 8, names beginning with X are
reserved for private use while all other names are to be associated reserved for private use while all other names are to be associated
with a specification in an RFC on the standards-track or defining an with a specification in an RFC on the standards-track or defining an
IESG-approved experimental protocol. IESG-approved experimental protocol.
skipping to change at page 87, line 36 skipping to change at page 91, line 36
If NNTP clients or servers cache the results of host name lookups in If NNTP clients or servers cache the results of host name lookups in
order to achieve a performance improvement, they MUST observe the TTL order to achieve a performance improvement, they MUST observe the TTL
information reported by DNS. If NNTP clients or servers do not information reported by DNS. If NNTP clients or servers do not
observe this rule, they could be spoofed when a previously accessed observe this rule, they could be spoofed when a previously accessed
server's IP address changes. As network renumbering is expected to server's IP address changes. As network renumbering is expected to
become increasingly common, the possibility of this form of attack become increasingly common, the possibility of this form of attack
will grow. Observing this requirement thus reduces this potential will grow. Observing this requirement thus reduces this potential
security vulnerability. security vulnerability.
This requirement also improves the load-balancing behavior of clients This requirement also improves the load-balancing behaviour of
for replicated servers using the same DNS name and reduces the clients for replicated servers using the same DNS name and reduces
likelihood of a user's experiencing failure in accessing sites that the likelihood of a user's experiencing failure in accessing sites
use that strategy. that use that strategy.
11.5 UTF-8 issues 11.5 UTF-8 issues
UTF-8 [RFC2279] permits only certain sequences of octets and UTF-8 [RFC3629] permits only certain sequences of octets and
designates others as either malformed or "illegal". The Unicode designates others as either malformed or "illegal". The Unicode
standard identifies a number of security issues related to illegal standard identifies a number of security issues related to illegal
sequences and forbids their generation by conforming implementations. sequences and forbids their generation by conforming implementations.
Implementations of this specification MUST NOT generate malformed or Implementations of this specification MUST NOT generate malformed or
illegal sequences and SHOULD detect them and take some appropriate illegal sequences and SHOULD detect them and take some appropriate
action. This could include: action. This could include:
o generating a 501 response code. o generating a 501 response code.
skipping to change at page 88, line 46 skipping to change at page 92, line 46
to remember which extensions a server supports to avoid the delay of to remember which extensions a server supports to avoid the delay of
an additional command and response, particularly if they open an additional command and response, particularly if they open
multiple connections in the same session. 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 setup 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] LIST EXTENSIONS
[S] 202 Extensions supported: [S] 202 Extensions supported:
[S] XENCRYPT [S] XENCRYPT
[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] LIST EXTENSIONS
[S] 202 Extensions supported: [S] 202 Extensions supported:
[S] XSECRET [S] XSECRET
[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 LIST EXTENSIONS result, then on the
next session it will attempt to use XSECRET on an unencrypted link: next session it will attempt to use XSECRET on an unencrypted link:
[Initial TCP connection setup 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 of exposing the password to any eavesdropper. While the primary cause of
this is passing a secret without first checking the security of the this is passing a secret without first checking the security of the
link, caching of LIST EXTENSIONS results can increase the risk. link, caching of LIST EXTENSIONS results 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 noticable issue. required for an additional command and response is a noticeable
issue.
12. Acknowledgments 12. Acknowledgements
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 work of the NNTP committee The author gratefully acknowledges the work of the NNTP committee
chaired by Eliot Lear. The organization of this document was chaired by Eliot Lear. The organization of this document was
influenced by the last available draft from this working group. A influenced by the last available draft from this working group. A
special thanks to Eliot for generously providing the original special thanks to Eliot for generously providing the original
machine-readable sources for that document. machine-readable sources for that document.
skipping to change at page 92, line 18 skipping to change at page 96, line 18
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", STD 63, RFC 3629, November 2003.
[RFC977] Kantor, B. and P. Lapsley, "Network News Transfer [RFC977] Kantor, B. and P. Lapsley, "Network News Transfer
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.
Informative References Informative References
skipping to change at page 94, line 7 skipping to change at page 98, line 7
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. Future Directions
It has been proposed that the response code range 6xx is used for It has been proposed that the response code range 6xx be used for
multiline responses. While existing commands and extensions do not multiline responses. While existing commands and extensions do not
use this, it would at least limit the problem clients would face in use this, it would at least limit the problem clients would face in
dealing with an unknown response. dealing with an unknown response.
Appendix B. Interaction with other specifications 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 "Usenet articles" here). It 1036 [RFC1036] (such articles are called "Netnews articles" here). It
is also sometimes used for transferring email messages that conform is also sometimes used for transferring email messages that conform
to RFC 2822 [RFC2822] (such articles are called "email articles" to RFC 2822 [RFC2822] (such articles are called "email articles"
here). In this situation, articles must conform both to this here). In this situation, articles must conform both to this
specification and to that other one; this appendix describes some specification and to that other one; this appendix describes some
relevant issues. relevant issues.
B.1 Header folding B.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 Usenet 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. Usenet 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.3. syntax rather than that in Section 9.4.
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] 1*P-CHAR *( [CRLF] WS 1*P-CHAR )
B.2 Message-IDs B.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 is 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.
This specification states that message-ids are the same if and only This specification states that message-ids are the same if and only
if they consist of the same sequence of octets. Other specifications if they consist of the same sequence of octets. Other specifications
may define two different sequences as being equal because they are may define two different sequences as being equal because they are
putting an interpretation on particular characters. RFC 2822 putting an interpretation on particular characters. RFC 2822
[RFC2822] has a concept of "quoted" and "escaped" characters. It [RFC2822] has a concept of "quoted" and "escaped" characters. It
therefore considers the three messages-ids: therefore considers the three message-ids:
<abcd@example.com> <abcd@example.com>
<"abcd"@example.com> <"abcd"@example.com>
<"ab\cd"@example.com> <"ab\cd"@example.com>
as being identical. Therefore an NNTP implementation handing email as being identical. Therefore an NNTP implementation handing email
articles must ensure that only one of these three appears in the articles must ensure that only one of these three appears in the
protocol and the other two are converted to it as and when necessary, protocol and the other two are converted to it as and when necessary,
such as when a client checks the results of a NEWNEWS command against such as when a client checks the results of a NEWNEWS command against
an internal database of message-ids. an internal database of message-ids. Note that RFC 1036 [RFC1036]
never treats two different strings as being identical. Its draft
successor restricts the syntax of message-ids so that, whenever RFC
2822 would treat two strings as equivalent, only one of them is valid
(in the above example only the first string is valid).
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; it may be deduced from the contents of the article or is determined; it may be deduced from the contents of the article or
derived from some external source. If the server is also conforming derived from some external source. If the server is also conforming
to another specification that contains a definition of message-id to another specification that contains a definition of message-id
compatible with this one, the server SHOULD use those message-ids. A compatible with this one, the server SHOULD use those message-ids. A
common approach, and one that SHOULD be used for email and Usenet common approach, and one that SHOULD be used for email and Netnews
articles, is to extract the message-id from the contents of a header articles, is to extract the message-id from the contents of a header
with name "Message-ID". This may not be as simple as copying the with name "Message-ID". This may not be as simple as copying the
entire header contents; it may be necessary to strip off comments and entire header contents; it may be necessary to strip off comments and
undo quoting, or to reduce "equivalent" message-ids to a canonical undo quoting, or to reduce "equivalent" message-ids to a canonical
form. form.
If an article is obtained though the IHAVE command, there will be a If an article is obtained through the IHAVE command, there will be a
message-id provided with the command. The server MAY either use it or message-id provided with the command. The server MAY either use it or
determine one from the article contents. However, whichever it does determine one from the article contents. However, whichever it does
it SHOULD ensure that, if the IHAVE command is repeated with the same it SHOULD ensure that, if the IHAVE command is repeated with the same
argument and article, it will be recognised as a duplicate. argument and article, it will be recognised 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 synthesise one. This could, for example, be a identify, it MUST synthesise 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 Usenet articles, a Message-ID header arrived. When handling email or Netnews articles, a Message-ID header
SHOULD be added to ensure global consistency and uniqueness. SHOULD be added to ensure global consistency and uniqueness.
B.3 Article posting B.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 Usenet 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
third party which has done so); therefore the contents SHOULD be left third party which has done so); therefore the contents SHOULD be left
unchanged. unchanged.
In contrast, the POST command is intended for use when an end-user is In contrast, the POST command is intended for use when an end-user is
injecting a newly-created article into a such a system. The article injecting a newly-created article into a such a system. The article
being transferred might not be a conforming email or Usenet article, being transferred might not be a conforming email or Netnews article,
and the server is expected to validate it and, if necessary, convert and the server is expected to validate it and, if necessary, convert
it to the right form for onward distribution. It is often the case it to the right form for onward distribution. It is often the case
that this is done by a separate piece of software on the server that this is done by a separate piece of software on the server
installation. If so, the NNTP server SHOULD pass the incoming article installation. If so, the NNTP server SHOULD pass the incoming article
to that software unaltered, making no attempt to filter characters, to that software unaltered, making no attempt to filter characters,
fold or limit lines, or otherwise process the incoming text. fold or limit lines, or otherwise process the incoming text.
The POST command can fail in various ways and clients should be The POST command can fail in various ways and clients should be
prepared to re-send an article. When doing so, however, it is often prepared to re-send an article. When doing so, however, it is often
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 recognise the two articles as being duplicates. In the case of can recognise the two articles as being duplicates. In the case of
email or Usenet 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
recognised as identical and the same message-id allocated, whether or recognised 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 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,
skipping to change at page 103, line 49 skipping to change at page 107, line 49
o The LISTGROUP command can only be used after the MODE READER o The LISTGROUP command can only be used after the MODE READER
command. command.
D.2 The OVER extension D.2 The OVER extension
o This extension provides support for an overview of newsgroups. o This extension provides support for an overview of newsgroups.
o The extension-label is "OVER". o The extension-label is "OVER".
o The extension-label has no arguments. 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 o The extension defines two new commands: OVER and LIST
OVERVIEW.FMT, whose behaviour, arguments, and responses are OVERVIEW.FMT, whose behaviour, arguments, and responses are
defined in Section 8.5. defined in Section 8.5.
o The extension does not associate any new responses with o The extension does not associate any new responses with
pre-existing NNTP commands. pre-existing NNTP commands.
o The extension requires the server to maintain an overview database o The extension requires the server to maintain an overview database
and article metadata, as described in Section 8.4. and article metadata, as described in Section 8.4.
skipping to change at page 104, line 34 skipping to change at page 108, line 36
o The OVER and LIST OVERVIEW.FMT commands can only be used after the o The OVER and LIST OVERVIEW.FMT commands can only be used after the
MODE READER command. MODE READER command.
D.3 The HDR extension D.3 The HDR extension
o This extension provides batched header retrieval. o This extension provides batched header retrieval.
o The extension-label is "HDR". o The extension-label is "HDR".
o The extension-label has the optional argument "ALL", indicating it o The extension-label has no arguments.
may be used with any header or metadata item.
o The extension defines two new commands: HDR and LIST HEADERS, o The extension defines two new commands: HDR and LIST HEADERS,
whose behaviour, arguments, and responses are defined in Section whose behaviour, arguments, and responses are defined in Section
8.6. 8.6.
o The extension does not associate any new responses with o The extension does not associate any new responses with
pre-existing NNTP commands. pre-existing NNTP commands.
o The extension requires the server to maintain article metadata, as o The extension requires the server to maintain article metadata, as
described in Section 8.4. described in Section 8.4.
skipping to change at page 106, line 8 skipping to change at page 110, line 8
o The extension does not cause any pre-existing command to produce a o The extension does not cause any pre-existing command to produce a
401, 480, or 483 response. 401, 480, or 483 response.
o The HDR and LIST HEADERS commands can only be used after the MODE o The HDR and LIST HEADERS commands can only be used after the MODE
READER command. 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 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the IETF's procedures with respect to rights in IETF Documents can
standards-related documentation can be found in BCP-11. Copies of be found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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/