draft-ietf-nntpext-base-18.txt   draft-ietf-nntpext-base-19.txt 
NNTP C. Feather NNTP C. Feather
Internet-Draft Thus plc Internet-Draft Thus plc
Expires: October 24, 2003 April 25, 2003 Expires: January 30, 2004 August 1, 2003
Network News Transport Protocol Network News Transport Protocol
draft-ietf-nntpext-base-18 draft-ietf-nntpext-base-19
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
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 October 24, 2003. This Internet-Draft will expire on January 30, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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 19.
Outstanding issues Outstanding issues
OUTSTANDING ISSUE OUTSTANDING ISSUE
Outstanding substantive (as opposed to editorial) issues in the Outstanding substantive (as opposed to editorial) issues in the
text are shown thus. text are shown thus.
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,
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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 X/Open Company Ltd.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 9 3. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Commands and Responses . . . . . . . . . . . . . . . . . . 9 3.1 Commands and Responses . . . . . . . . . . . . . . . . . . 7
3.2 Response Codes . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Response Codes . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Generic Response Codes . . . . . . . . . . . . . . . . . . 13 3.2.1 Generic Response Codes . . . . . . . . . . . . . . . . . . 10
3.2.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Articles . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4 Articles . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. The WILDMAT format . . . . . . . . . . . . . . . . . . . . 20 4. The WILDMAT format . . . . . . . . . . . . . . . . . . . . 17
4.1 Wildmat syntax . . . . . . . . . . . . . . . . . . . . . . 20 4.1 Wildmat syntax . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Wildmat semantics . . . . . . . . . . . . . . . . . . . . 20 4.2 Wildmat semantics . . . . . . . . . . . . . . . . . . . . 17
4.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Session administration commands . . . . . . . . . . . . . 23 5. Session administration commands . . . . . . . . . . . . . 20
5.1 Initial Connection . . . . . . . . . . . . . . . . . . . . 23 5.1 Initial Connection . . . . . . . . . . . . . . . . . . . . 20
5.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2 MODE READER . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 23 5.3 LIST EXTENSIONS . . . . . . . . . . . . . . . . . . . . . 23
5.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 MODE READER . . . . . . . . . . . . . . . . . . . . . . . 24 6. Article posting and retrieval . . . . . . . . . . . . . . 26
5.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1 Group and article selection . . . . . . . . . . . . . . . 26
5.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.1 GROUP . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.2 LAST . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 LIST EXTENSIONS . . . . . . . . . . . . . . . . . . . . . 26 6.1.3 NEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.2 Retrieval of articles and article sections . . . . . . . . 32
5.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 26 6.2.1 ARTICLE . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.2 HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.2.3 BODY . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.2.4 STAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.2 Description . . . . . . . . . . . . . . . . . . . . . . . 28 6.3 Article posting . . . . . . . . . . . . . . . . . . . . . 41
5.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.3.1 POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6. Article posting and retrieval . . . . . . . . . . . . . . 29 6.3.2 IHAVE . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.1 Group and article selection . . . . . . . . . . . . . . . 29 7. Information commands . . . . . . . . . . . . . . . . . . . 46
6.1.1 GROUP . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1 DATE . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.1.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2 HELP . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.1.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 30 7.3 NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.4 NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1.2 LAST . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 32 7.6 The LIST commands . . . . . . . . . . . . . . . . . . . . 51
6.1.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.6.1 LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.3 NEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.6.2 LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . . . 53
6.1.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.6.3 LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . . 54
6.1.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 34 7.6.4 LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . . . 55
6.1.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.6.5 LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . . . 57
6.2 Retrieval of articles and article sections . . . . . . . . 35 8. Framework for NNTP extensions . . . . . . . . . . . . . . 59
6.2.1 ARTICLE . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.1 Initial IANA registry . . . . . . . . . . . . . . . . . . 61
6.2.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2 Standard extensions . . . . . . . . . . . . . . . . . . . 61
6.2.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 36 8.3 The LISTGROUP extension . . . . . . . . . . . . . . . . . 61
6.2.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.3.1 LISTGROUP . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.2 HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.4 Article metadata . . . . . . . . . . . . . . . . . . . . . 63
6.2.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.4.1 The :bytes metadata item . . . . . . . . . . . . . . . . . 63
6.2.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 39 8.4.2 The :lines metadata item . . . . . . . . . . . . . . . . . 63
6.2.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.5 The OVER extension . . . . . . . . . . . . . . . . . . . . 64
6.2.3 BODY . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.5.1 OVER . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.5.2 LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . . 68
6.2.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 41 8.6 The HDR extension . . . . . . . . . . . . . . . . . . . . 70
6.2.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.6.1 HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.4 STAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.6.2 LIST HEADERS . . . . . . . . . . . . . . . . . . . . . . . 74
6.2.4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . . 77
6.2.4.2 Description . . . . . . . . . . . . . . . . . . . . . . . 42 9.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.2.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3 Article posting . . . . . . . . . . . . . . . . . . . . . 44 9.3 Articles . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.1 POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.4 General non-terminals . . . . . . . . . . . . . . . . . . 79
6.3.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10. IANA Considerations . . . . . . . . . . . . . . . . . . . 81
6.3.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 44 11. Security Considerations . . . . . . . . . . . . . . . . . 82
6.3.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 45 11.1 Personal and Proprietary Information . . . . . . . . . . . 82
6.3.2 IHAVE . . . . . . . . . . . . . . . . . . . . . . . . . . 46 11.2 Abuse of Server Log Information . . . . . . . . . . . . . 82
6.3.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 46 11.3 Weak Authentication and Access Control . . . . . . . . . . 82
6.3.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 46 11.4 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 47 11.5 UTF-8 issues . . . . . . . . . . . . . . . . . . . . . . . 83
7. Information commands . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 85
7.1 DATE . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Normative References . . . . . . . . . . . . . . . . . . . 87
7.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Informative References . . . . . . . . . . . . . . . . . . 88
7.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 50 Author's Address . . . . . . . . . . . . . . . . . . . . . 88
7.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 50 A. Future Directions . . . . . . . . . . . . . . . . . . . . 89
7.2 HELP . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 B. Interaction with other specifications . . . . . . . . . . 90
7.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 50 B.1 Header folding . . . . . . . . . . . . . . . . . . . . . . 90
7.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 51 B.2 Message-IDs . . . . . . . . . . . . . . . . . . . . . . . 90
7.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 51 B.3 Article posting . . . . . . . . . . . . . . . . . . . . . 91
7.3 NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . 93
7.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 51
7.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.4 NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.4.2 Description . . . . . . . . . . . . . . . . . . . . . . . 53
7.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.6 The LIST commands . . . . . . . . . . . . . . . . . . . . 55
7.6.1 LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . . . 55
7.6.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.6.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 55
7.6.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.6.2 LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . . . 57
7.6.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.6.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 57
7.6.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.6.3 LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . . 58
7.6.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.6.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 59
7.6.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.6.4 LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . . . 60
7.6.4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.6.4.2 Description . . . . . . . . . . . . . . . . . . . . . . . 60
7.6.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.6.5 LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . . . 61
7.6.5.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.6.5.2 Description . . . . . . . . . . . . . . . . . . . . . . . 61
7.6.5.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 62
8. Framework for NNTP extensions . . . . . . . . . . . . . . 63
8.1 Initial IANA registry . . . . . . . . . . . . . . . . . . 65
8.2 Standard extensions . . . . . . . . . . . . . . . . . . . 65
8.3 The LISTGROUP extension . . . . . . . . . . . . . . . . . 65
8.3.1 LISTGROUP . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 66
8.3.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.4 Article metadata . . . . . . . . . . . . . . . . . . . . . 67
8.4.1 The :bytes metadata item . . . . . . . . . . . . . . . . . 68
8.4.2 The :lines metadata item . . . . . . . . . . . . . . . . . 68
8.5 The OVER extension . . . . . . . . . . . . . . . . . . . . 68
8.5.1 OVER . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.5.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.5.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 69
8.5.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.5.2 LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . . 72
8.5.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.5.2.2 Description . . . . . . . . . . . . . . . . . . . . . . . 72
8.5.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.6 The HDR extension . . . . . . . . . . . . . . . . . . . . 74
8.6.1 HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.6.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.6.1.2 Description . . . . . . . . . . . . . . . . . . . . . . . 74
8.6.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 76
9. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . . 78
9.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . 80
9.3 Articles . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.4 General non-terminals . . . . . . . . . . . . . . . . . . 80
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 82
11. Security Considerations . . . . . . . . . . . . . . . . . 83
11.1 Personal and Proprietary Information . . . . . . . . . . . 83
11.2 Abuse of Server Log Information . . . . . . . . . . . . . 83
11.3 Weak Authentication and Access Control . . . . . . . . . . 83
11.4 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 84
11.5 UTF-8 issues . . . . . . . . . . . . . . . . . . . . . . . 84
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 86
Normative References . . . . . . . . . . . . . . . . . . . 88
Informative References . . . . . . . . . . . . . . . . . . 89
Author's Address . . . . . . . . . . . . . . . . . . . . . 89
Intellectual Property and Copyright Statements . . . . . . 90
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.
skipping to change at page 9, line 29 skipping to change at page 7, line 29
The character set for all NNTP commands is UTF-8 [RFC2279]. Commands The character set for all NNTP commands is UTF-8 [RFC2279]. 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. arguments MUST NOT exceed 497 octets. A server MAY relax these limits
for commands defined in an extension.
Where this specification permits UTF-8 characters outside the range Where this specification permits UTF-8 characters outside the range
U+0000 to U+007F, implementations MUST NOT use the Byte Order Mark U+0000 to U+007F, implementations MUST NOT use the Byte Order Mark
(U+FEFF, encoding %xEF.BB.BF), and MUST use the Word Joiner (U+2060, (U+FEFF, encoding %xEF.BB.BF), and MUST use the Word Joiner (U+2060,
encoding %xE2.91.A0) for the meaning Zero Width No-Break Space, in encoding %xE2.91.A0) for the meaning Zero Width No-Break Space, in
command lines and the initial lines of responses, and SHOULD apply command lines and the initial lines of responses, and SHOULD apply
these same principles throughout. these same principles throughout.
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
skipping to change at page 10, line 4 skipping to change at page 8, line 5
be ignored by the server. Command and response parameters are case or be ignored by the server. Command and response parameters 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
other relevant specifications. other relevant specifications.
An NNTP server MUST implement all the commands in this specification An NNTP server MUST implement all the commands in this specification
except for those marked as optional and those in extensions. except for those marked as optional and those in extensions.
Each response MUST start with a three-digit response code that is Each response MUST start with a three-digit response code that is
sufficient to distinguish all responses. Certain valid responses are sufficient to distinguish all responses. Certain valid responses are
defined to be multi-line; for all others, the response is contained defined to be multi-line; for all others, the response is contained
in a single line. in a single line. The first or only line of the response MUST NOT
exceed 512 octets, which includes the response code and the
OUTSTANDING ISSUE terminating CRLF pair; an extension MAY specify a greater maximum for
commands that it defines, but not for any other command.
Should the initial response line be limited to 512 octets as well?
Possible text:
The first or only line of the response MUST NOT exceed 512 octets,
which includes the response code and the terminating CRLF pair.
The text further down about "does not place any limit on the
length" would need equivalent edits.
All multi-line responses MUST adhere to the following format: All multi-line responses MUST adhere to the following format:
1. The response consists of a sequence of one or more "lines", each 1. The response consists of a sequence of one or more "lines", each
being a stream of octets ending with a CRLF pair. Apart from being a stream of octets ending with a CRLF pair. Apart from
those line endings, the stream MUST NOT include the octets NUL, those line endings, the stream MUST NOT include the octets NUL,
LF, or CR. LF, or CR.
2. The first such line contains the response code as with a single 2. The first such line contains the response code as with a single
line response. line response.
skipping to change at page 11, line 7 skipping to change at page 8, line 48
CRLF pair of the terminating CRLF "." CRLF is, of course, part of CRLF pair of the terminating CRLF "." CRLF is, of course, part of
the last line of the response). the last line of the response).
Note that texts using an encoding (such as UTF-16 or UTF-32) that may Note that texts using an encoding (such as UTF-16 or UTF-32) that may
contain the octets NUL, LF, or CR other than a CRLF pair cannot be contain the octets NUL, LF, or CR other than a CRLF pair cannot be
reliably conveyed in the above format. However, except when stated reliably conveyed in the above format. However, except when stated
otherwise, this specification does not require the content to be otherwise, this specification does not require the content to be
UTF-8 and it is possible for octets above and below 128 to be mixed UTF-8 and it is possible for octets above and below 128 to be mixed
arbitrarily. arbitrarily.
This document does not place any limit on the length of a line. This document does not place any limit on the length of a subsequent
However, the standards that define the format of articles may do so. line in a multi-line response. However, the standards that define the
format of articles may do so.
An NNTP server MAY have an inactivity autologout timer. Such a timer An NNTP server MAY have an inactivity autologout timer. Such a timer
SHOULD be of at least three minutes duration, with the exception that SHOULD be of at least three minutes duration, with the exception that
there MAY be a shorter limit on how long the server is willing to there MAY be a shorter limit on how long the server is willing to
wait for the first command from the client. The receipt of any wait for the first command from the client. The receipt of any
command from the client during the timer interval SHOULD suffice to command from the client during the timer interval SHOULD suffice to
reset the autologout timer. Similarly, the receipt of any significant reset the autologout timer. Similarly, the receipt of any significant
amount of data from the client while in the midst of sending a amount of data from the client while in the midst of sending a
multi-line message to the server (such as during a POST or IHAVE multi-line message to the server (such as during a POST or IHAVE
command) SHOULD suffice to reset the autologout timer. When the timer command) SHOULD suffice to reset the autologout timer. When the timer
skipping to change at page 11, line 39 skipping to change at page 9, line 34
failure, or progress of the previous command. failure, or progress of the previous command.
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 correct, but couldn't be performed for some 4xx - Command was correct, but couldn't be performed for some
reason. reason.
5xx - Command unimplemented, or incorrect, or a serious program 5xx - Command unimplemented, or incorrect, or a serious program
error occurred. error occurred.
OUTSTANDING ISSUE
I proposed that we assign 6xx for extensions and future commands
to use for multiline responses, thus at least limiting (if not
eliminating) the problem clients have of working out whether one
is coming up. Nobody was violently against the idea, but nobody
was particularly in favour either.
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, setup, 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 authorization extensions x8x - Reserved for authentication and authorization extensions
x9x - Reserved for private use (non-standard extensions) x9x - Reserved for private use (non-standard extensions)
skipping to change at page 13, line 20 skipping to change at page 11, line 5
The server MUST respond to any command with the appropriate one of The server MUST respond to any command with the appropriate one of
the following generic responses if it represents the situation. the following generic responses if it represents the situation.
If the command is not recognized, or it is an optional command or If the command is not recognized, or it is an optional command or
extension that is not implemented by the server, the response code extension that is not implemented by the server, the response code
500 MUST be returned. 500 MUST be returned.
If there is a syntax error in the arguments of a recognized command, If there is a syntax error in the arguments of a recognized command,
including the case where more arguments are provided than the command including the case where more arguments are provided than the command
specifies, the response code 501 MUST be returned. Note that where a specifies or the command line is longer than the server accepts, the
command has variants depending on a second keyword (e.g. LIST ACTIVE response code 501 MUST be returned. The line MUST NOT be truncated or
and LIST NEWSGROUPS), then 501 MUST be used when the requested split and then interpreted. Note that where a command has variants
variant is not implemented but the base command is. depending on a second keyword (e.g. LIST ACTIVE and LIST NEWSGROUPS),
then 501 MUST be used when the requested variant is not implemented
but the base command is.
If the server experiences an internal fault or problem that means it If the server experiences an internal fault or problem that means it
is unable to carry out the command (for example, a necessary file is is unable to carry out the command (for example, a necessary file is
missing or a necessary service could not be contacted), the response missing or a necessary service could not be contacted), the response
code 403 MUST be returned. If the server recognises the command but code 403 MUST be returned. If the server recognises the command but
does not provide an optional feature (for example because it does not does not provide an optional feature (for example because it does not
store the required information), or only handles a subset of store the required information), or only handles a subset of
legitimate cases (see the HDR command (Section 8.6.1) for an legitimate cases (see the HDR command (Section 8.6.1) for an
example), the response code 503 MUST be returned. Note that where a example), the response code 503 MUST be returned. Note that where a
command is optional (e.g. LIST ACTIVE.TIMES) and is not provided by a command is optional (e.g. LIST ACTIVE.TIMES) and is not provided by a
server, this MAY be treated as an unimplemented command (response server, this MAY be treated as an unimplemented command (response
code 500 or 501) or as a working command where the information is not code 500 or 501) or as a working command where the information is not
available (response code 503). available (response code 503).
OUTSTANDING ISSUE
Do we need to add text like:
For backwards compatibility a server MAY return the response
code 503 where this specification requires the response code
403, and a client SHOULD be prepared for this. This waiver may
be removed in a future revision of this specification.
If the client is not authorized to use the specified facility when If the client is not authorized to use the specified facility when
the server is in its current state, then either the response code 480 the server is in its current state, then either the response code 480
or the response code 502 MUST be returned. The response code 480 or the response code 502 MUST be returned. The response code 480
SHOULD be used if a different command (for example, an extension used SHOULD be used if a different command (for example, an extension used
to present credentials) might change the server state so that the to present credentials) might change the server state so that the
command is permitted. The response code 502 SHOULD be used if the command is permitted. The response code 502 SHOULD be used if the
server wishes to indicate that it is necessary to terminate the server wishes to indicate that it is necessary to terminate the
connection and start a new one with the appropriate authority before connection and start a new one with the appropriate authority before
the command can be used. Since it is not always possible to clearly the command can be used. Since it is not always possible to clearly
distinguish these two cases, a server MAY issue either of these distinguish these two cases, a server MAY issue either of these
skipping to change at page 14, line 30 skipping to change at page 12, line 9
Do we need a more generic mechanism for "you must invoke extension Do we need a more generic mechanism for "you must invoke extension
X to do Y"? X to do Y"?
The best proposal made so far is that all 48x codes, if returned The best proposal made so far is that all 48x codes, if returned
from an existing command, mean "unavailable unless some from an existing command, mean "unavailable unless some
authentication or privacy extension is invoked". Does this tie in authentication or privacy extension is invoked". Does this tie in
with the issue of permitting existing commands not listed in an with the issue of permitting existing commands not listed in an
extension? extension?
I asked if anyone used 48x with *existing commands* to mean other
than "you are missing a privacy or authentication extension".
Effectively the answer is "no".
If the server has to terminate the connection for some reason, it If the server has to terminate the connection for some reason, it
MUST give a 400 response code to the next command and then MUST give a 400 response code to the next command and then
immediately close the TCP connection. It MAY give a 401 response code immediately close the TCP connection.
to any command to indicate that termination is imminent (following a
401 response, it MUST NOT close the TCP connection immediately).
OUTSTANDING ISSUE
It's not clear that we need 401; it appears to have been an
invention. If we do keep it, then text is needed to indicate what
happens with commands that change the status (for example, if
GROUP returns 401 what happens to the current selected newsgroup),
and how to make those commands work.
With the exception of mandatory commands and the 500 response, the With the exception of mandatory commands and the 500 response, the
client MUST be prepared to receive any of these responses for any client MUST be prepared to receive any of these responses for any
command. command.
3.2.1.1 Examples 3.2.1.1 Examples
Example of an unknown command: Example of an unknown command:
[C] MAIL [C] MAIL
skipping to change at page 16, line 19 skipping to change at page 13, line 40
[C] GROUP archive.local [C] GROUP archive.local
[S] 403 Archive server temporarily offline [S] 403 Archive server temporarily offline
Example of the server needing to close down immediately: Example of the server needing to close down immediately:
[C] ARTICLE 123 [C] ARTICLE 123
[S] 400 Power supply failed, running on UPS [S] 400 Power supply failed, running on UPS
[Server closes connection.] [Server closes connection.]
Example of imminent termination of the server:
[C] STAT 123
[S] 401 Pre-payment expired, you have 10 seconds
[C] STAT 123
[S] 423 No such article number in this group
[C] NEXT
[S] 400 Time expired
[Server closes connection.]
3.3 Pipelining 3.3 Pipelining
NNTP is designed to operate over a reliable bi-directional connection NNTP is designed to operate over a reliable bi-directional connection
such as TCP. Therefore, if a command does not depend on the response such as TCP. Therefore, if a command does not depend on the response
to the previous one, it should not matter if it is sent before that to the previous one, it should not matter if it is sent before that
response is received. Doing this is called "pipelining". However, response is received. Doing this is called "pipelining". However,
certain server implementations throw away all text received from the certain server implementations throw away all text received from the
client following certain commands before sending their response. If client following certain commands before sending their response. If
this happens, pipelining will be affected because one or more this happens, pipelining will be affected because one or more
commands will have been ignored or misinterpreted, and the client commands will have been ignored or misinterpreted, and the client
skipping to change at page 17, line 49 skipping to change at page 15, line 11
[C] NEXT [C] NEXT
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[S] 200 Server ready, posting allowed [S] 200 Server ready, posting allowed
[S] 223 3000237 <668929@example.org> retrieved [S] 223 3000237 <668929@example.org> retrieved
The DATE command has been thrown away by the server and so there is The DATE command has been thrown away by the server and so there is
no 111 response to match it. no 111 response to match it.
3.4 Articles 3.4 Articles
OUTSTANDING ISSUE
This section is new. If anyone has better wording, I won't
complain.
NNTP is intended to transfer articles between clients and servers. NNTP is intended to transfer articles between clients and servers.
For the purposes of this specification, articles are required to For the purposes of this specification, articles are required to
conform to the rules in this section and clients and servers MUST conform to the rules in this section and clients and servers MUST
correctly process any article received from the other that does so. correctly process any article received from the other that does so.
Note that this requirement applies only to the contents of Note that this requirement applies only to the contents of
communications over NNTP; it does not prevent the client or server communications over NNTP; it does not prevent the client or server
from subsequently rejecting an article for reasons of local policy. from subsequently rejecting an article for reasons of local policy.
In particular, where NNTP is used to transport articles that conform Also see Appendix B for further restrictions on the format of
to other specifications such as RFC 1036 [RFC1036] or RFC 2822 articles in some uses of NNTP.
[RFC2822], articles must meet both this specification and that other.
OUTSTANDING ISSUE
Need to add an appendix that spells out how this document
interacts with RFC 1036. That would allow us to remove some of the
convoluted wording about "other specifications".
An article consists of two parts: the headers and the body. They are An article consists of two parts: the headers and the body. They are
separated by a single empty line, or in other words by two separated by a single empty line, or in other words by two
consecutive CRLF pairs (if there is more than one empty line, the consecutive CRLF pairs (if there is more than one empty line, the
second and subsequent ones are part of the body). In order to meet second and subsequent ones are part of the body). In order to meet
the general requirements of NNTP, an article MUST NOT include the the general requirements of NNTP, an article MUST NOT include the
octet NUL, MUST NOT contain the octets LF and CR other than as part octet NUL, MUST NOT contain the octets LF and CR other than as part
of a CRLF pair, and MUST end with a CRLF pair. This specification of a CRLF pair, and MUST end with a CRLF pair. This specification
puts no further restrictions on the body; in particular, it MAY be puts no further restrictions on the body; in particular, it MAY be
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 CRLF
but is otherwise unrestricted; in particular, it MAY be empty. A but is otherwise unrestricted; in particular, it MAY be empty. A
header may be "folded"; that is, a CRLF pair may be placed before any header may be "folded"; that is, a CRLF pair may be placed before any
TAB or space in the line (including the space after the colon after TAB or space in the line; there MUST still be some other octet
the header name), except that there MUST be at least one octet other between any two CRLF pairs in a header line. (Note that folding means
than %x09 or %x20 between any two CRLF pairs in a header line. (Note that the header line occupies more than one line when displayed or
that folding means that the header line occupies more than one line transmitted; nevertheless it is still referred to as "a" header
when displayed or transmitted; nevertheless it is still referred to line.) The presence or absence of folding does not affect the meaning
as "a" header line.) The presence or absence of folding does not of the header line; that is, the CRLF pairs introduced by folding are
affect the meaning of the header line; that is, the CRLF pairs not considered part of the header value. Header lines SHOULD NOT be
introduced by folding are not considered part of the header value. folded before the space after the colon that follows the header name,
and should include at least one octet other than %x09 or %x20 between
CRLF pairs. However, if an article has been received from elsewhere
with one of these, clients and servers MAY transfer it to the other
without re-folding it.
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. Note that RFC 1036 an NNTP server MUST NOT have the same message-id. For the purposes of
[RFC1036] further requires that message-ids are globally unique for this specification, message-ids are opaque strings that MUST meet the
all time. following requirements:
For the purposes of this specification, message-ids are opaque
strings that MUST meet the following requirements:
o A message-id MUST begin with "<" and end with ">", and MUST NOT o A message-id MUST begin with "<" and end with ">", and MUST NOT
contain the latter except at the end. contain the latter except at the end.
o A message-id MUST be between 3 and 250 octets in length. o A message-id MUST be between 3 and 250 octets in length.
o A message-id MUST NOT contain octets other than printable US-ASCII o A message-id MUST NOT contain octets other than printable US-ASCII
characters. characters.
Two message-ids are the same if and only if they consist of the same Two message-ids are the same if and only if they consist of the same
sequence of octets. Other specifications may define two different sequence of octets.
sequences as being equal; an NNTP server that also conforms to such a
specification must consistently use only one or the other. As an
example, the message-ids:
<abcd@example.com>
<"abcd"@example.com>
<"ab\cd"@example.com>
are considered distinct by this specification even though they would
be considered semantically identical according to the specification
in RFC 2822 [RFC2822].
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 is also conforming to another is determined. If the server does not have any way to determine a
specification that contains a definition of message-id compatible message-id from the article itself, it MUST synthesise one (this
with this one, the server SHOULD use those message-ids). Many servers specification does not require the article to be changed as a
will extract the message-id from the contents of a header with name result).
"Message-ID", but this is not required by this document. If the
server does not have any way to determine a message-id from the
article itself, it MUST synthesise one (it need not modify the
article to add such a header unless required to by another
specification).
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 30, line 15 skipping to change at page 27, line 15
6.1.1.2 Description 6.1.1.2 Description
The required parameter is the name of the newsgroup to be selected The required parameter is the name of the newsgroup to be selected
(e.g. "news.software.b"). A list of valid newsgroups may be obtained (e.g. "news.software.b"). A list of valid newsgroups may be obtained
by using the LIST ACTIVE command (see Section 7.6.1). by using the LIST ACTIVE command (see Section 7.6.1).
The successful selection response will return the article numbers of The successful selection response will return the article numbers of
the first and last articles in the group at the moment of selection the first and last articles in the group at the moment of selection
(these numbers are referred to as the "reported low water mark" and (these numbers are referred to as the "reported low water mark" and
the "reported high water mark"), and an estimate of the number of the "reported high water mark"), and an estimate of the number of
articles on file in the group. articles in the group currently available.
If the group is not empty, the estimate MUST be at least the actual If the group is not empty, the estimate MUST be at least the actual
number of articles available, and MUST be no greater than one more number of articles available, and MUST be no greater than one more
than the difference between the reported low and high water marks. than the difference between the reported low and high water marks.
(Some implementations will actually count the number of articles on (Some implementations will actually count the number of articles
file. Others will just subtract the low water mark from the high currently stored. Others will just subtract the low water mark from
water mark and add one to get an estimate.) the high water mark and add one to get an estimate.)
If the group is empty, one of the following three situations will If the group is empty, one of the following three situations will
occur. Clients MUST accept all three cases; servers MUST NOT occur. Clients MUST accept all three cases; servers MUST NOT
represent an empty group in any other way. represent an empty group in any other way.
o The high water mark will be one less than the low water mark, and o The high water mark will be one less than the low water mark, and
the estimated article count will be zero. Servers SHOULD use this the estimated article count will be zero. Servers SHOULD use this
method to show an empty group. This is the only time that the high method to show an empty group. This is the only time that the high
water mark can be less than the low water mark. water mark can be less than the low water mark.
skipping to change at page 36, line 11 skipping to change at page 33, line 11
[1] The 420 response can only occur if no article number has been [1] The 420 response can only occur if no article number has been
specified. specified.
6.2.1.2 Description 6.2.1.2 Description
The ARTICLE command selects an article based on the arguments and The ARTICLE command selects an article based on the arguments and
presents the entire article (that is, the headers, an empty line, and presents the entire article (that is, the headers, an empty line, and
the body in that order). The command has two forms. the body in that order). The command has two forms.
In the first form, a message-id is specified (including the angle In the first form, a message-id is specified and the server presents
brackets), and the server presents the article with that message-id. the article with that message-id. In this case, the server MUST NOT
In this case, the server MUST NOT alter the current selected alter the current selected newsgroup or current article number. This
newsgroup or current article number. This is both to facilitate the is both to facilitate the presentation of articles that may be
presentation of articles that may be referenced within another referenced within another article being read, and because of the
article being read, and because of the semantic difficulties of semantic difficulties of determining the proper sequence and
determining the proper sequence and membership of an article that may membership of an article that may have been crossposted to more than
have been crossposted to more than one newsgroup. one newsgroup.
In the response, the article number is replaced with zero (that is, In the response, the article number is replaced with zero (that is,
the server is not required to determine whether the article is in the the server is not required to determine whether the article is in the
current group or what article number(s) it has). current group or what article number(s) it has).
In the second form, an article number may be specified. If so, and if In the second form, an article number may be specified. If so, and if
there is an article with that number in the currently selected there is an article with that number in the currently selected
newsgroup, the server MUST set the current article number to that newsgroup, the server MUST set the current article number to that
number. number.
skipping to change at page 36, line 51 skipping to change at page 33, line 51
article exists; in particular, it MUST NOT change it following an article exists; in particular, it MUST NOT change it following an
unsuccessful response. unsuccessful response.
Since the message-id is unique for each article, it may be used by a Since the message-id is unique for each article, it may be used by a
client to skip duplicate displays of articles that have been posted client to skip duplicate displays of articles that have been posted
more than once, or to more than one newsgroup. more than once, or to more than one newsgroup.
The article is returned as a multi-line response following the 220 The article is returned as a multi-line response following the 220
response code. response code.
If the current article number is invalid, a 420 response MUST be If the argument is a message-id and no such article exists, a 430
returned. If there is no article with the specified number, a 423 response MUST be returned. If the current article number is invalid,
response MUST be returned. If the current selected newsgroup is a 420 response MUST be returned. If there is no article with the
invalid, a 412 response MUST be returned. specified number, a 423 response MUST be returned. If the current
selected newsgroup is invalid, a 412 response MUST be returned.
6.2.1.3 Examples 6.2.1.3 Examples
Example of a successful retrieval of an article (using no article Example of a successful retrieval of an article (using no article
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] ARTICLE [C] ARTICLE
[S] 220 3000234 <45223423@example.com> [S] 220 3000234 <45223423@example.com>
skipping to change at page 45, line 5 skipping to change at page 42, line 5
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 unforseen 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. In other words, or transferred to other servers as appropriate, possibly following
articles not wanted by the server SHOULD be rejected with a 441 further processing. In other words, articles not wanted by the server
response and not accepted and silently discarded. SHOULD be rejected with a 441 response and not accepted and silently
discarded. However, the client SHOULD NOT assume that the article has
No attempt shall be made by the server to filter characters, fold or been successfully transferred unless it receives an affirmative
limit lines, or otherwise process incoming text. The intent is that response from the server, and SHOULD NOT assume that it is being made
the server just passes the incoming message to be posted to the available to other clients without explicitly checking (for example
server installation's news posting software, which is not defined by using the STAT command).
this document.
The client SHOULD NOT assume that the article has been successfully If the session is interrupted before the response is received, it is
transferred unless it receives an affirmative response from the possible that an affirmative response was sent but has been lost.
server. If the session is interrupted before the response is Therefore, in any subsequent session, the client SHOULD either check
received, it is possible that an affirmative response was sent but whether the article was successfully posted before resending or
has been lost. Therefore, in any subsequent session, the client ensure that the server will allocate the same message-id to the new
SHOULD either check whether the article was successfully posted attempt (see Appendix B.2) - the latter approach is preferred since
before resending or, if the client supplied a message-id in the the article might not have been made available for reading yet (for
original article, ensure it supplies the same message-id - the latter example, it may have to go through a moderation process).
approach is preferred since the article might not have been made
available for reading yet (for example, it may have to go through a
moderation process). In particular, if the article contained a header
with name "Message-ID", the client SHOULD ensure that the contents of
this header are identical when resending it and the server SHOULD
ensure that the re-sent article is recognised as a duplicate and not
assigned a different message-id to the original.
6.3.1.3 Examples 6.3.1.3 Examples
Example of a successful posting: Example of a successful posting:
[C] POST [C] POST
[S] 340 Input article; end with <CR-LF>.<CR-LF> [S] 340 Input article; end with <CR-LF>.<CR-LF>
[C] From: "Demo User" <nobody@example.net> [C] From: "Demo User" <nobody@example.net>
[C] Newsgroups: misc.test [C] Newsgroups: misc.test
[C] Subject: I am just a test article [C] Subject: I am just a test article
skipping to change at page 48, line 8 skipping to change at page 44, line 47
Example of successfully sending an article to another site: Example of successfully sending an article to another site:
[C] IHAVE <i.am.an.article.you.will.want@example.com> [C] IHAVE <i.am.an.article.you.will.want@example.com>
[S] 335 Send it; end with <CR-LF>.<CR-LF> [S] 335 Send it; end with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail [C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <nobody@example.com> [C] From: "Demo User" <nobody@example.com>
[C] Newsgroups: misc.test [C] Newsgroups: misc.test
[C] Subject: I am just a test article [C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500 [C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: An Example Com, San Jose, CA [C] Organization: An Example Com, San Jose, CA
[C] Message-ID: <i.am.a.test.article@example.com> [C] Message-ID: <i.am.an.article.you.will.want@example.com>
[C] [C]
[C] This is just a test article. [C] This is just a test article.
[C] . [C] .
[S] 235 Article transferred OK [S] 235 Article transferred OK
Example of sending an article to another site that rejects it. Note
Example of sending an article to another site that rejects it: that the message-id in the IHAVE command is not the same as the one
in the article headers; while this is bad practice and SHOULD NOT be
done, it is not forbidden.
[C] IHAVE <i.am.an.article.you.will.want@example.com> [C] IHAVE <i.am.an.article.you.will.want@example.com>
[S] 335 Send it; end with <CR-LF>.<CR-LF> [S] 335 Send it; end with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail [C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <nobody@example.com> [C] From: "Demo User" <nobody@example.com>
[C] Newsgroups: misc.test [C] Newsgroups: misc.test
[C] Subject: I am just a test article [C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500 [C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: An Example Com, San Jose, CA [C] Organization: An Example Com, San Jose, CA
[C] Message-ID: <i.am.a.test.article@example.com> [C] Message-ID: <i.am.an.article.you.have@example.com>
[C] [C]
[C] This is just a test article. [C] This is just a test article.
[C] . [C] .
[S] 437 Article rejected; don't send again [S] 437 Article rejected; don't send again
Example of sending an article to another site where the transfer Example of sending an article to another site where the transfer
fails: fails:
[C] IHAVE <i.am.an.article.you.will.want@example.com> [C] IHAVE <i.am.an.article.you.will.want@example.com>
[S] 335 Send it; end with <CR-LF>.<CR-LF> [S] 335 Send it; end with <CR-LF>.<CR-LF>
[C] Path: pathost!demo!somewhere!not-for-mail [C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <nobody@example.com> [C] From: "Demo User" <nobody@example.com>
[C] Newsgroups: misc.test [C] Newsgroups: misc.test
[C] Subject: I am just a test article [C] Subject: I am just a test article
[C] Date: 6 Oct 1998 04:38:40 -0500 [C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: An Example Com, San Jose, CA [C] Organization: An Example Com, San Jose, CA
[C] Message-ID: <i.am.a.test.article@example.com> [C] Message-ID: <i.am.an.article.you.will.want@example.com>
[C] [C]
[C] This is just a test article. [C] This is just a test article.
[C] . [C] .
[S] 436 Transfer failed [S] 436 Transfer failed
Example of sending an article to a site that already has it: Example of sending an article to a site that already has it:
[C] IHAVE <i.am.an.article.you.have@example.com> [C] IHAVE <i.am.an.article.you.have@example.com>
[S] 435 Duplicate [S] 435 Duplicate
Example of sending an article to a site that requests the article be Example of sending an article to a site that requests the article be
tried again later: tried again later:
[C] IHAVE <i.am.an.article.you.defer@example.com> [C] IHAVE <i.am.an.article.you.defer@example.com>
[S] 436 Retry later [S] 436 Retry later
7. Information commands 7. Information commands
This section lists other commands that may be used at any time This section lists other commands that may be used at any time
between the beginning of a session and its termination. Using these between the beginning of a session and its termination. Using these
skipping to change at page 56, line 35 skipping to change at page 52, line 35
extension or may be private to the server. A client SHOULD treat an extension or may be private to the server. A client SHOULD treat an
unrecognised status as giving no information. unrecognised status as giving no information.
The status of a newsgroup only indicates how posts to that newsgroup The status of a newsgroup only indicates how posts to that newsgroup
are normally processed and is not necessarily customised to the are normally processed and is not necessarily customised to the
specific client. For example, if the current client is forbidden from specific client. For example, if the current client is forbidden from
posting, then this will apply equally to groups with status "y". posting, then this will apply equally to groups with status "y".
Conversely, a client with special privileges (not defined by this Conversely, a client with special privileges (not defined by this
specification) might be able to post to a group with status "n". specification) might be able to post to a group with status "n".
If the optional wildmat parameter is specified, the list is limited If the optional wildmat parameter is specified, the response is
to only the groups whose names match the wildmat. If no wildmat is limited to only the groups (if any) whose names match the wildmat. If
specified, the keyword ACTIVE MAY be omitted without altering the no wildmat is specified, the keyword ACTIVE MAY be omitted without
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.fc-writers.recovery 4 1 y
skipping to change at page 57, line 37 skipping to change at page 53, line 37
LIST ACTIVE.TIMES [wildmat] LIST ACTIVE.TIMES [wildmat]
Responses Responses
215 Information follows (multiline) 215 Information follows (multiline)
Parameters Parameters
wildmat = groups of interest wildmat = groups of interest
7.6.2.2 Description 7.6.2.2 Description
The active.times file is maintained by some news transport systems to The active.times list is maintained by some news transport systems to
contain information about who created a particular newsgroup and contain information about who created a particular newsgroup and
when. Each line of this file consists of three fields separated from when. Each line of this list consists of three fields separated from
each other by one or more spaces. The first field is the name of the each other by one or more spaces. The first field is the name of the
newsgroup. The second is the time when this group was created on this newsgroup. The second is the time when this group was created on this
news server, measured in seconds since the start of January 1, 1970. news server, measured in seconds since the start of January 1, 1970.
The third is the email address of the entity that created the The third is plain text intended to describe the entity that created
newsgroup, and must be a mailbox as defined in RFC 2822 [RFC2822]. the newsgroup; it is often a mailbox as defined in RFC 2822
[RFC2822].
OUTSTANDING ISSUE
Should the third field simply be free-form, or should it be
recommended usage rather than mandatory? The problem with
"mailbox" is that mailbox requires that it be fully qualified, and
unqualified addresses are apparently very common for groups
created directly by the administrator.
The file 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, and MAY include groups not available on the server; in particular, it
the file MAY omit all groups created before the date and time of the MAY omit all groups created before the date and time of the oldest
oldest entry. The client MUST NOT assume that the list is complete or entry. The client MUST NOT assume that the list is complete or that
that it matches the list returned by LIST ACTIVE. The NEWGROUPS it matches the list returned by LIST ACTIVE. The NEWGROUPS command
command (Section 7.3) may provide a better way to access this (Section 7.3) may provide a better way to access this information and
information and the results of the two commands SHOULD be consistent the results of the two commands SHOULD be consistent (subject to the
(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 parameter is specified, the list is limited If the optional wildmat parameter is specified, the response is
to only the groups in the file whose names match the wildmat. Note limited to only the groups (if any) whose names match the wildmat and
that an empty list is a possible valid response, and indicates that for which the information is available. Note that an empty list is a
there are no groups in the file, or that match the wildmat. 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 59, line 11 skipping to change at page 55, line 4
[S] 501 Syntax Error [S] 501 Syntax Error
7.6.3 LIST DISTRIBUTIONS 7.6.3 LIST DISTRIBUTIONS
7.6.3.1 Usage 7.6.3.1 Usage
This command is optional. This command is optional.
Syntax Syntax
LIST DISTRIBUTIONS LIST DISTRIBUTIONS
Responses Responses
215 Information follows (multiline) 215 Information follows (multiline)
7.6.3.2 Description 7.6.3.2 Description
The distributions file is maintained by some news transport systems The distributions list is maintained by some news transport systems
to contain information about valid values for the content of the to contain information about valid values for the content of the
Distribution header in a news article and about what the various Distribution header in a news article and about what the various
values mean. Each line of this file consists of two fields separated values mean. Each line of this list consists of two fields separated
from each other by one or more spaces. The first field is a value and from each other by one or more spaces. The first field is a value and
the second is a short explanation of the meaning of that value. the second is a short explanation of the meaning of that value.
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.
7.6.3.3 Examples 7.6.3.3 Examples
Example of LIST DISTRIBUTIONS returning a list of distributions: Example of LIST DISTRIBUTIONS returning a list of distributions:
skipping to change at page 60, line 19 skipping to change at page 56, line 13
This command is optional. This command is optional.
Syntax Syntax
LIST DISTRIB.PATS LIST DISTRIB.PATS
Responses Responses
215 Information follows (multiline) 215 Information follows (multiline)
7.6.4.2 Description 7.6.4.2 Description
The distrib.pats file is maintained by some news transport systems to The distrib.pats list is maintained by some news transport systems to
choose a value for the content of the Distribution header of a news choose a value for the content of the Distribution header of a news
article being posted. Each line of this file consists of three fields article being posted. Each line of this list consists of three fields
separated from each other by a colon (":"). The first field is a separated from each other by a colon (":"). The first field is a
weight, the second field is a wildmat (which may be a simple group weight, the second field is a wildmat (which may be a simple group
name), and the third field is a value for the Distribution header name), and the third field is a value for the Distribution header
content. content.
The client MAY use this information to construct an appropriate The client MAY use this information to construct an appropriate
Distribution header given the name of a newsgroup. To do so, it Distribution header given the name of a newsgroup. To do so, it
should determine the lines whose second field matches the newsgroup should determine the lines whose second field matches the newsgroup
name, select from among them the line with the highest weight (with 0 name, select from among them the line with the highest weight (with 0
being the lowest), and use the value of the third field to construct being the lowest), and use the value of the third field to construct
skipping to change at page 61, line 29 skipping to change at page 57, line 23
LIST NEWSGROUPS [wildmat] LIST NEWSGROUPS [wildmat]
Responses Responses
215 Information follows (multiline) 215 Information follows (multiline)
Parameters Parameters
wildmat = groups of interest wildmat = groups of interest
7.6.5.2 Description 7.6.5.2 Description
The newsgroups file is maintained by some news transport systems to The newsgroups list is maintained by some news transport systems to
contain the name of each newsgroup that is available on the server contain the name of each newsgroup that is available on the server
and a short description about the purpose of the group. Each line of and a short description about the purpose of the group. Each line of
this file consists of two fields separated from each other by one or this list consists of two fields separated from each other by one or
more space or TAB characters (usual practice is a single TAB). The 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. Note that an empty list is a possible valid description of the group.
response, and indicates that there are currently no valid newsgroups.
The file 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 parameter is specified, the list is limited If the optional wildmat parameter is specified, the response is
to only the groups in the file whose names match the wildmat. Note limited to only the groups (if any) whose names match the wildmat and
that an empty list is a possible valid response, and indicates that for which the information is available. Note that an empty list is a
there are no groups in the file, or that match the wildmat. 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 34 skipping to change at page 59, line 34
Given this environment, the framework for extensions described in Given this environment, the framework for extensions described in
this document consists of: this document consists of:
o a mechanism for clients to determine a server's available o a mechanism for clients to determine a server's available
extensions extensions
o a registry of NNTP service extensions o a registry of NNTP service extensions
The LIST EXTENSIONS command is described in this document (see The LIST EXTENSIONS command is described in this document (see
Section 5.3) and is the mechanism for clients to use to determine Section 5.3) and is the mechanism for clients to use to determine
what extensions are available. what extensions are available. Except where stated otherwise, the
commands in this document are understood (even if not supported) by
all servers and are not described in the list of features returned by
the LIST EXTENSIONS command.
The IANA shall maintain a registry of NNTP service extensions. The IANA shall maintain a registry of NNTP service extensions.
An extension is identified by a unique extension-label, which is a An extension is identified by a unique extension-label, which is a
string of 1 to 12 uppercase US-ASCII letters. The extension-label string of 1 to 12 uppercase US-ASCII letters. The extension-label
will often be the name of a new command that the extension adds. will often be the name of a new command that the extension adds.
However this is not a requirement: an extension might not add any new However this is not a requirement: an extension might not add any new
commands or keywords. commands or keywords.
An extension is either a private extension or else it is included in An extension is either a private extension or else it is included in
skipping to change at page 64, line 4 skipping to change at page 60, line 6
commands or keywords. commands or keywords.
An extension is either a private extension or else it is included in An extension is either a private extension or else it is included in
the IANA registry and is defined in an RFC. Such RFCs either must be the IANA registry and is defined in an RFC. Such RFCs either must be
on the standards-track or must define an IESG-approved experimental on the standards-track or must define an IESG-approved experimental
protocol. protocol.
The definition of an extension must include: The definition of an extension must include:
o a descriptive name for the extension o a descriptive name for the extension
o the extension-label (which is returned by LIST EXTENSIONS to o the extension-label (which is returned by LIST EXTENSIONS to
indicate to the client that the server supports this particular indicate to the client that the server supports this particular
extension) extension) - the extension-label of a registered extension MUST
NOT begin with "X";
o the syntax, values, and meanings of any parameters following the o the syntax, values, and meanings of any parameters following the
extension-label in the output of LIST EXTENSIONS extension-label in the output of LIST EXTENSIONS
o any new NNTP commands associated with the extension o any new NNTP commands associated with the extension - the names of
commands associated with registered extensions MUST NOT begin with
"X";
o the syntax and possible values of parameters associated with the o the syntax and possible values of parameters associated with the
new NNTP commands new NNTP commands
o the response codes and possible values of parameters for the o the response codes and possible values of parameters for the
responses of the new NNTP commands responses of the new NNTP commands
o any new parameters the extension associates with any other o any new parameters 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 behavior of a server and
NNTP client NNTP client
o any increase in the maximum length of commands over the value o any increase in the maximum length of commands and initial
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)
The extension-label of private extensions MUST begin with "X". The A private extension need not be included in the output of LIST
extension-label of registered extensions MUST NOT begin with "X". EXTENSIONS. A server MAY provide additional keywords - either for new
commands or new variants of existing commands - as part of a private
A server MUST NOT provide any extension, whether or not listed in the extension. To avoid the risk of a clash with a future registered
output from LIST EXTENSIONS, unless it is either a registered extension, the names of private extensions and commands defined by
extension or a private extension. them SHOULD begin with "X".
OUTSTANDING ISSUE
As worded, this forbids commands like MODE SLAVE that servers
already provide but that aren't part of an existing extension. We
can't simply make these illegal.
The wording about starting keywords with an X could be reduced to
a SHOULD, except for backwards compatibility (with a pointer to
RFC 2980). But is that the right answer?
Except where stated otherwise, the commands in this document are
understood (even if not supported) by all servers and are not
described in the list of features returned by the LIST EXTENSIONS
command.
A server MAY provide additional keywords - either for new commands or
new variants of existing commands - as part of a private extension.
These new keywords MUST begin with "X".
A server MUST NOT send different response codes to basic NNTP A server MUST NOT send different response codes to basic NNTP
commands documented here or commands documented in registered commands documented here or commands documented in registered
extensions in response to the availability or use of a private extensions in response to the availability or use of a private
extension. extension.
8.1 Initial IANA registry 8.1 Initial IANA registry
The IANA's initial registry of NNTP service extensions consists of The IANA's initial registry of NNTP service extensions consists of
these entries: these entries:
Extension Label Added behavior Extension Label Added behavior
Specific article numbers LISTGROUP Defined in this document Specific article numbers LISTGROUP Defined in this document
Overview support OVER Defined in this document Overview support OVER Defined in this document
Header pattern matching HDR Defined in this document Batched header retrieval HDR Defined in this document
8.2 Standard extensions 8.2 Standard extensions
Each of the following sections describes an extension that a server Each of the following sections describes an extension that a server
MAY provide. If the server provides the extension, it MUST include MAY provide. If the server provides the extension, it MUST include
the appropriate extension label in the response to LIST EXTENSIONS. the appropriate extension label in the response to LIST EXTENSIONS.
If it does not provide it, it MUST NOT include the appropriate If it does not provide it, it MUST NOT include the appropriate
extension label. The descriptions of facilities in each section are extension label. The descriptions of facilities in each section are
written as if the extension is provided. If it is not provided, the written as if the extension is provided. If it is not provided, the
entire section should be ignored. entire section should be ignored.
skipping to change at page 67, line 46 skipping to change at page 63, line 35
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).
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.)
This specification defines two metadata items: ":bytes" and ":lines". This specification defines two metadata items: ":bytes" and ":lines".
Implementations and other extensions may define other metadata items. Other metadata items may be defined by extensions. The names of
metadata items defined by registered extensions MUST NOT begin with
OUTSTANDING ISSUE ":x-". To avoid the risk of a clash with a future registered
extension, the names of metadata items defined by private extensions
Do we need a separate private namespace? For example, we could SHOULD begin with ":x-".
reserve :name for extensions and ::name for implementation use.
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 MUST
equal the number of octets in the entire article - headers, body, and equal the number of octets in the entire article - headers, body, and
separating empty line - except that each CRLF pair MAY (but SHOULD separating empty line - except that each CRLF pair MAY (but SHOULD
NOT) be counted as a single octet. NOT) be counted as a single octet.
OUTSTANDING ISSUE
Should this be called ":octets" instead?
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. The information stored in the
database may change over time. The LIST OVERVIEW.FMT command database may change over time. If the database records the content or
describes the information that would be stored for an article absence of a given field (that is, a header or metadata item) for all
arriving at the same time as the command was executed. articles, it is said to be "consistent" for that field. If it records
the content of a header for some articles but not for others that
nevertheless included that 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 database is consistent at that moment. It MAY omit such fields
(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 or which are not stored in the database. Therefore if a
header appears in the LIST OVERVIEW.FMT output but not the OVER
output for a given article, that header does not appear in the
article, and similarly for metadata items.
These rules assume the fields being stored in the database remain
constant for long periods of time, with the database therefore being
consistent. When the set of fields to be stored is changed, it will
be inconsistent until either the database is rebuilt or the only
articles remaining are those received during the change. Therefore
the output from LIST OVERVIEW.FMT needs to be altered twice: before
any fields stop being stored, they MUST be removed from the output,
then when the database is once more known to be consistent, the new
fields SHOULD be added to the output.
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 [range] OVER [range]
Responses Responses
First form (message-id specified)
224 Overview information follows (multiline)
430 No article found with that message-id
Second form (optional range specified)
224 Overview information follows (multiline) 224 Overview information follows (multiline)
412 No newsgroup selected 412 No newsgroup selected
420 Current article number is invalid 420 Current article number is invalid [1]
423 No articles in that range 423 No articles in that range
Parameters Parameters
message-id = Article message-id
range = Article(s) to return information for range = Article(s) to return information for
[1] The 420 response can only occur if no article number has been
specified.
8.5.1.2 Description 8.5.1.2 Description
The OVER command returns the contents of the headers and metadata in The OVER command returns the contents of the headers and metadata in
the database for the article(s) specified from the current selected the database for the article(s) specified.
newsgroup.
The optional range argument may be any of the following: In the first form the article is specified by message-id. In the
second form articles in the current selected newsgroup are specified
using the optional range argument, which 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 no argument is specified, then the current article number is used. If no argument is specified, then 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 224 response code. If the current selected response following the 224 response code. If the argument is a
newsgroup is invalid, a 412 response MUST be returned. If there are message-id and no such article exists, a 430 response MUST be
no articles in the range specified, a 423 response MUST be returned. returned. If the current selected newsgroup is invalid, a 412
If OVER is sent without any arguments and the current article number response MUST be returned. If there are no articles in the range
is invalid, a 420 response MUST be returned. specified, a 423 response MUST be returned. If OVER is sent without
any arguments and the current article number is invalid, a 420
response MUST be returned.
For a successful response, the output consists of one line per For a successful response, the output consists of one line per
article, sorted in numerical order of article number. Each line article, sorted in numerical order of article number (note that
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
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.
The first 8 fields MUST be the following, in order: The first 8 fields MUST be the following, in order:
article number "0" (first form) or article number (second form)
Subject header content Subject header content
From header content From header content
Date header content Date header content
Message-ID header content Message-ID header content
References header content References header content
:bytes metadata item :bytes metadata item
:lines metadata item :lines metadata item
If the article is specified by message-id rather than by article
range, the article number is given as "0".
Any subsequent fields are the contents of the other headers and Any subsequent fields are the contents of the other headers and
metadata held in the database. metadata held in the database.
For the five mandatory headers, the content of each field MUST be For the five mandatory headers, the content of each field MUST be
based on the content of the header (that is, with the header name and based on the content of the header (that is, with the header name and
following colon and space removed). If the article does not contain following colon and space removed). If the article does not contain
that header, or if the content is empty, the field MUST be empty. For that header, or if the content is empty, the field MUST be empty. For
the two mandatory metadata items, the content of the field MUST be the two mandatory metadata items, the content of the field MUST be
just the value, with no other text. just the value, with no other text.
skipping to change at page 70, line 39 skipping to change at page 67, line 19
become two spaces, since the CR and first LF will be removed by the become two spaces, since the CR and first LF will be removed by the
unfolding process). This will encourage robustness in the face of unfolding process). This will encourage robustness in the face of
non-conforming data; it is also possible that future versions of this non-conforming data; it is also possible that future versions of this
specification may permit these characters to appear in articles. specification may permit these characters to appear in articles.
The server SHOULD NOT produce output for articles that no longer The server SHOULD NOT produce output for articles that no longer
exist. exist.
8.5.1.3 Examples 8.5.1.3 Examples
In the first two examples, TAB has been replaced by vertical bar and In the first three examples, TAB has been replaced by vertical bar
some lines have been folded for readability. and some lines have been folded for readability.
Example of a successful retrieval of overview information for an Example of a successful retrieval of overview information for an
article (using no article number): article (using no article number):
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] OVER [C] OVER
[S] 224 Overview information follows [S] 224 Overview information follows
[S] 300234|I am just a test article|"Demo User" [S] 300234|I am just a test article|"Demo User"
<nobody@example.com>|6 Oct 1998 04:38:40 -0500| <nobody@example.com>|6 Oct 1998 04:38:40 -0500|
<45223423@example.com>|<45454@example.net>|1234| <45223423@example.com>|<45454@example.net>|1234|
17|Xref: news.example.com misc.test:3000363 17|Xref: news.example.com misc.test:3000363
[S] . [S] .
Example of a successful retrieval of overview information for an
article by message-id:
[C] OVER <45223423@example.com>
[S] 224 Overview information follows
[S] 0|I am just a test article|"Demo User"
<nobody@example.com>|6 Oct 1998 04:38:40 -0500|
<45223423@example.com>|<45454@example.net>|1234|
17|Xref: news.example.com misc.test:3000363
[S] .
Note that the article number has been replaced by "0".
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 8 skipping to change at page 69, line 4
selected newsgroup is empty: selected newsgroup is empty:
[C] GROUP example.empty.newsgroup [C] GROUP example.empty.newsgroup
[S] 211 0 0 0 example.empty.newsgroup [S] 211 0 0 0 example.empty.newsgroup
[C] OVER [C] OVER
[S] 420 No current article selected [S] 420 No current article selected
8.5.2 LIST OVERVIEW.FMT 8.5.2 LIST OVERVIEW.FMT
8.5.2.1 Usage 8.5.2.1 Usage
This command is optional.
Syntax Syntax
LIST OVERVIEW.FMT LIST OVERVIEW.FMT
Responses Responses
215 Information follows (multiline) 215 Information follows (multiline)
8.5.2.2 Description 8.5.2.2 Description
OUTSTANDING ISSUE
Should this be optional even when the OVER extension is provided?
Or even just removed entirely? What do we want to require about
the OVER contents being consistent with the output of this
command?
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. The fields MUST be listed in the order that they will the database for which it is consistent (as described above).
be returned by the OVER command for a newly-received article (the
information stored for articles may change over time).
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 be exactly:
Subject: Subject:
From: From:
Date: Date:
Message-ID: Message-ID:
skipping to change at page 74, line 7 skipping to change at page 70, line 46
[S] Distribution:full [S] Distribution:full
[S] . [S] .
Example of LIST OVERVIEW.FMT returning an error: Example of LIST OVERVIEW.FMT returning an error:
[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 one new command: HDR. The label for this This extension provides two new commands: HDR and LIST HEADERS. The
extension is HDR. label for this extension is HDR.
OUTSTANDING ISSUE
There is ongoing discussion about whether this extension should The HDR extension provides access to specific headers and metadata
have a parameter and, if so, what it means. items (collectively "fields") of articles or groups of articles. In
the case of headers, an implementation MAY restrict the use of this
extension to a specific list of headers or MAY allow it to be used
with any header. In the latter case it MUST use the parameter "ALL"
following the extension label in the output of LIST EXTENSIONS; in
the former case it MUST NOT use any parameter.
8.6.1 HDR 8.6.1 HDR
8.6.1.1 Usage 8.6.1.1 Usage
Syntax Syntax
HDR header range HDR header range
HDR header message-id HDR header message-id
HDR header HDR header
skipping to change at page 75, line 27 skipping to change at page 72, line 21
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
The message-id argument indicates a specific article. As shown by the The message-id argument indicates a specific article. As shown by the
syntax, the range and message-id arguments are mutually exclusive; if syntax, the range and message-id arguments are mutually exclusive; if
neither is specified, the current article number is used. 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 exists. The line consists each article where the relevant header line or metadata item exists.
of the article number, a space, and then the contents of the header The line consists of the article number, a space, and then the
(without the header name or the colon and space that follow it) or contents of the header (without the header name or the colon and
metadata item. If the article is specified by message-id rather than space that follow it) or metadata item. If the article is specified
by article range, the article number is given as "0". by message-id rather than by article range, 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 15 skipping to change at page 73, line 10
If the optional argument is a message-id and no such article exists, If the optional argument is a message-id and no such article exists,
a 430 response MUST be returned. If the optional argument is not a a 430 response MUST be returned. If the optional argument is not a
message-id and the current selected newsgroup is invalid, a 412 message-id and the current selected newsgroup is invalid, a 412
response MUST be returned. If the optional argument is an article response MUST be returned. If the optional argument is an article
number or number range and no article with that number or in that number or number range and no article with that number or in that
number range exists in the current selected newsgroup, a 423 response number range exists in the current selected newsgroup, a 423 response
MUST be returned. If HDR is sent without any arguments and the MUST be returned. If HDR is sent without any arguments and the
current article number is invalid, a 420 response MUST be returned. current article number is invalid, a 420 response 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 (such as those present in the overview database). If metadata items. If so, it MUST respond with a 503 response to
so, it MUST respond with a 503 response to attempts to request other attempts to request other headers, rather than returning erroneous
headers, rather than returning erroneous results such as a successful results such as a successful empty response.
empty response.
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):
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] HDR Subject 3000234-300238 [C] HDR Subject 3000234-300238
[S] 225 Headers follow [S] 225 Headers follow
skipping to change at page 78, line 5 skipping to change at page 74, line 44
[S] 423 No articles in that range [S] 423 No articles in that range
Example of an unsuccessful retrieval of headers because the server Example of an unsuccessful retrieval of headers because the server
does not allow HDR commands for that header: does not allow HDR commands for that header:
[C] GROUP misc.test [C] GROUP misc.test
[S] 211 1234 3000234 3002322 misc.test [S] 211 1234 3000234 3002322 misc.test
[C] HDR Content-Type 3000234-300238 [C] HDR Content-Type 3000234-300238
[S] 503 HDR not permitted on Content-Type [S] 503 HDR not permitted on Content-Type
8.6.2 LIST HEADERS
8.6.2.1 Usage
Syntax
LIST HEADERS
Responses
215 Header and metadata list follows (multiline)
8.6.2.2 Description
The LIST HEADERS command returns a list of headers and metadata items
that may be retrieved using the HDR command.
The information is returned as a multi-line response following the
215 response code and contains one line for each header or metadata
item name (excluding the colon in the former case). If the
implementation allows any header to be retrieved (also indicated by
the "ALL" parameter to the extension label) it MUST NOT include any
header names in the list but MUST include the special entry ":" (a
single colon on its own); it MUST still list any metadata items that
are available. The order of items in the list is not significant; the
server need not even consistently return the same order. The list MAY
be empty (though in this circumstance there is little point in
providing the extension).
If the list of available fields is not the same for all articles (for
example, because the HDR command uses the same database as the OVER
command and the set of fields being stored has recently changed),
then the response should indicate the situation for a newly-arrived
article.
An implementation that also supports the OVER extension SHOULD at
least permit all the headers and metadata items listed in the output
from the LIST OVERVIEW.FMT command.
8.6.2.3 Examples
Example of an implementation providing access to only a few headers:
[C] LIST EXTENSIONS
[S] 202 extensions supported:
[S] HDR
[S] .
[C] LIST HEADERS
[S] 215 headers supported:
[S] Subject
[S] Message-ID
[S] Xref
[S] .
Example of an implementation providing access to the same fields as
the first example in Section 8.5.2.3:
[C] LIST EXTENSIONS
[S] 202 extensions supported:
[S] OVER
[S] HDR
[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] Xref
[S] :bytes
[S] :lines
[S] .
Example of an implementation providing access to all headers:
[C] LIST EXTENSIONS
[S] 202 extensions supported:
[S] HDR ALL
[S] .
[C] LIST HEADERS
[S] 215 metadata items supported:
[S] :
[S] :bytes
[S] :lines
[S] :article-number
[S] .
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
skipping to change at page 80, line 14 skipping to change at page 79, line 14
9.2 Responses 9.2 Responses
This syntax defines the non-terminal "response", which represents This syntax defines the non-terminal "response", which represents
what is sent from the server to the client in response to a command. what is sent from the server to the client in response to a command.
response = simple-response / multiline-response response = simple-response / multiline-response
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 parameters [ SP trailing-comment ] CRLF simple-response = 3DIGIT parameters [ SP trailing-comment ] CRLF
trailing-comment = *U-CHAR trailing-comment = *U-CHAR
parameters = *( SP parameter ) ; How many depends on the response parameters = *( SP parameter ) ; How many depends on the response
parameter = 1*A-CHAR parameter = 1*A-CHAR
9.3 Articles 9.3 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-content = *( P-CHAR / [CRLF] WS )
body = *(*B-CHAR CRLF) body = *(*B-CHAR CRLF)
header = header-name ":" header-tail CRLF
header-tail = SP header-content-u / CRLF SP header-content-f
header-content-u = *( header-gap header-text) *WS
header-content-f = *WS header-text header-content-u
header-gap = *WS [CRLF] 1*WS
header-text = 1*P-CHAR
9.4 General non-terminals 9.4 General non-terminals
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
skipping to change at page 86, line 16 skipping to change at page 85, line 16
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.
The author gratefully acknowledges the work of Marshall Rose & John The author gratefully acknowledges the work of the DRUMS working
G. Meyers in RFC 1939 [RFC1939] and the work of the DRUMS working
group, specifically RFC 1869 [RFC1869], which is the basis of the group, specifically RFC 1869 [RFC1869], which is the basis of the
NNTP extensions mechanism detailed in this document. NNTP extensions mechanism detailed in this document.
OUTSTANDING ISSUE
Why RFC 1939?
The author gratefully acknowledges the authors of RFC 2616 [RFC2616] The author gratefully acknowledges the authors of RFC 2616 [RFC2616]
for providing specific and relevant examples of security issues that for providing specific and relevant examples of security issues that
should be considered for HTTP. Since many of the same considerations should be considered for HTTP. Since many of the same considerations
exist for NNTP, those examples that are relevant have been included exist for NNTP, those examples that are relevant have been included
here with some minor rewrites. here with some minor rewrites.
The author gratefully acknowledges the comments and additional The author gratefully acknowledges the comments and additional
information provided by the following individuals in preparing one or information provided by the following individuals in preparing one or
more of the progenitors of this document: more of the progenitors of this document:
skipping to change at page 89, line 14 skipping to change at page 88, line 14
Informative References Informative References
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987. USENET messages", RFC 1036, December 1987.
[RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869, Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
November 1995. November 1995.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[SALZ1992] [SALZ1992]
Salz, R., "Manual Page for wildmat(3) from the INN 1.4 Salz, R., "Manual Page for wildmat(3) from the INN 1.4
distribution, Revision 1.10", April 1992. distribution, Revision 1.10", April 1992.
skipping to change at page 90, line 4 skipping to change at page 89, line 4
Clive D.W. Feather Clive D.W. Feather
Thus plc Thus plc
322 Regents Park Road 322 Regents Park Road
London N3 2QQ London N3 2QQ
GB GB
Phone: +44 20 8495 6138 Phone: +44 20 8495 6138
Fax: +44 870 051 9937 Fax: +44 870 051 9937
URI: http://www.davros.org/ URI: http://www.davros.org/
Appendix A. Future Directions
It has been proposed that the response code range 6xx is used for
multiline responses. While existing commands and extensions do not
use this, it would at least limit the problem clients would face in
dealing with an unknown response.
Appendix B. Interaction with other specifications
NNTP is most often used for transferring articles that conform to RFC
1036 [RFC1036] (such articles are called "Usenet articles" here). It
is also sometimes used for transferring email messages that conform
to RFC 2822 [RFC2822] (such articles are called "email articles"
here). In this situation, articles must conform both to this
specification and to that other one; this appendix describes some
relevant issues.
B.1 Header folding
NNTP allows a header line to be folded (by inserting a CRLF pair)
before any space or TAB character.
Both email and Usenet articles are required to have at least one
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
TABs. Usenet articles are further required to have the header name,
colon, and following space all on the first line; folding may only
happen beyond that space. Finally, some non-conforming software will
remove trailing spaces and TABs from a line. Therefore it might be
inadvisable to fold a header after a space or TAB.
For maximum safety, header lines SHOULD conform to the following
syntax rather than that in Section 9.3.
header = header-name ":" SP [header-content] CRLF
header-content = [WS] 1*P-CHAR *( [CRLF] WS 1*P-CHAR )
B.2 Message-IDs
Every article handled by an NNTP server MUST have a unique
message-id. For the purposes of this specification, a message-id is
an arbitrary opaque string that is merely needs to meet certain
syntactic requirements and is just a way to refer to the article.
Because there is a significant risk of old articles being reinjected
into the global Usenet system, RFC 1036 [RFC1036] requires that
message-ids are globally unique for all time.
This specification states that message-ids are the same if and only
if they consist of the same sequence of octets. Other specifications
may define two different sequences as being equal because they are
putting an interpretation on particular characters. RFC 2822
[RFC2822] has a concept of "quoted" and "escaped" characters. It
therefore considers the three messages-ids:
<abcd@example.com>
<"abcd"@example.com>
<"ab\cd"@example.com>
as being identical. Therefore an NNTP implementation handing email
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,
such as when a client checks the results of a NEWNEWS command against
an internal database of message-ids.
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
derived from some external source. If the server is also conforming
to another specification that contains a definition of message-id
compatible with this one, the server SHOULD use those message-ids. A
common approach, and one that SHOULD be used for email and Usenet
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
entire header contents; it may be necessary to strip off comments and
undo quoting, or to reduce "equivalent" message-ids to a canonical
form.
If an article is obtained though the IHAVE command, there will be a
message-id provided with the command. The server MAY either use it or
determine one from the article contents. However, whichever it does
it SHOULD ensure that, if the IHAVE command is repeated with the same
argument and article, it will be recognised as a duplicate.
If an article does not contain a message-id that the server can
identify, it MUST synthesise one. This could, for example, be a
simple sequence number or based on the date and time that the article
arrived. When handling email or Usenet articles, a Message-ID header
SHOULD be added to ensure global consistency and uniqueness.
B.3 Article posting
As far as NNTP is concerned, the POST and IHAVE commands provide the
same basic facilities in a slightly different way. However they have
rather different intentions.
The IHAVE command is intended for transmitting conforming articles
between a system of NNTP servers, with all articles perhaps also
conforming to another specification (e.g. all articles are Usenet
articles). It is expected that the client will have already done any
necessary validation (or has in turn obtained the article from a
third party which has done so); therefore the contents SHOULD be left
unchanged.
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
being transferred might not be a conforming email or Usenet article,
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
that this is done by a separate piece of software on the server
installation. If so, the NNTP server SHOULD pass the incoming article
to that software unaltered, making no attempt to filter characters,
fold or limit lines, or otherwise process the incoming text.
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
important to ensure - as far as possible - that the same message-id
is allocated to both attempts so that the server, or other servers,
can recognise the two articles as being duplicates. In the case of
email or Usenet articles, therefore, the posted article SHOULD
contain a header with name "Message-ID" and the contents of this
header SHOULD be identical on each attempt. The server SHOULD ensure
that two POSTed articles with the same contents for this header are
recognised as identical and the same message-id allocated, whether or
not those contents are suitable for use as the message-id.
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 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; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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