diff options
| author | Matěj Cepl <mcepl@cepl.eu> | 2023-01-02 22:54:56 +0100 |
|---|---|---|
| committer | Matěj Cepl <mcepl@cepl.eu> | 2023-05-25 10:56:00 +0200 |
| commit | 974100c32e45bd07ced44e9b179558a184fbb7d7 (patch) | |
| tree | 15b074939ef241436822bc31af57032b276183a9 /docs/RFC 3977 - Network News Transfer Protocol (NNTP).html | |
| parent | ed0912fb0f3d34e28d9a2ea392103a937f91bba9 (diff) | |
| download | pygn-974100c32e45bd07ced44e9b179558a184fbb7d7.tar.gz | |
Convert documentation from .maff to plain HTML.
Diffstat (limited to 'docs/RFC 3977 - Network News Transfer Protocol (NNTP).html')
| -rw-r--r-- | docs/RFC 3977 - Network News Transfer Protocol (NNTP).html | 7068 |
1 files changed, 7068 insertions, 0 deletions
diff --git a/docs/RFC 3977 - Network News Transfer Protocol (NNTP).html b/docs/RFC 3977 - Network News Transfer Protocol (NNTP).html new file mode 100644 index 0000000..7ded014 --- /dev/null +++ b/docs/RFC 3977 - Network News Transfer Protocol (NNTP).html @@ -0,0 +1,7068 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/"> +<meta http-equiv="content-type" content="text/html; charset=UTF-8"> + <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> + <meta name="robots" content="index,follow"> + <meta name="creator" content="rfcmarkup version 1.109"> + <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> +<meta name="DC.Relation.Replaces" content="rfc977"> +<meta name="DC.Identifier" content="urn:ietf:rfc:3977"> +<meta name="DC.Date.Issued" content="October, 2006"> +<meta name="DC.Creator" content="Clive D.W. Feather <clive@demon.net>"> +<meta name="DC.Description.Abstract" content="The Network News Transfer Protocol (NNTP) has been in use in the\nInternet for a decade, and remains one of the most popular protocols\n(by volume) in use today. This document is a replacement for RFC 977,\nand officially updates the protocol specification. It clarifies some\nvagueness in RFC 977, includes some new base functionality, and\nprovides a specific mechanism to add standardized extensions to NNTP.\n[STANDARDS-TRACK]"> +<meta name="DC.Title" content="Network News Transfer Protocol (NNTP)"> + + <link rel="icon" href="index_files/rfc.png" type="image/png"> + <link rel="shortcut icon" href="index_files/rfc.png" type="image/png"> + <title>RFC 3977 - Network News Transfer Protocol (NNTP)</title> + + + <style type="text/css"><!--
+/* Effective stylesheet produced by snapshot save */
+body { margin: 0px 8px; font-size: 1em; }
+h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { line-height: 0pt; display: inline; white-space: pre; font-family: monospace; font-size: 1em; font-weight: bold; }
+pre { font-size: 1em; margin-top: 0px; margin-bottom: 0px; }
+.pre { white-space: pre; font-family: monospace; }
+.newpage { page-break-before: always; }
+.invisible { text-decoration: none; color: white; }
+a.selflink { color: black; text-decoration: none; }
+@media print {
+ body { font-family: monospace; font-size: 10.5pt; }
+ h1, h2, h3, h4, h5, h6 { font-size: 1em; }
+ a:link, a:visited { color: inherit; text-decoration: none; }
+ .noprint { display: none; }
+}
+@media screen {
+ .grey, .grey a:link, .grey a:visited { color: rgb(119, 119, 119); }
+ .docinfo { background-color: rgb(238, 238, 238); }
+ .top { border-top: 7px solid rgb(238, 238, 238); }
+ .bgblue { background-color: rgb(102, 102, 255); }
+ .legend { font-size: 90%; }
+}
+--></style> + <!--[if IE]> + <style> + body { + font-size: 13px; + margin: 10px 10px; + } + </style> + <![endif]--> + + <script type="text/javascript"><!--
+/* Script removed by snapshot save */
+--></script> +</head> +<body onload=""> + <div style="height: 13px;"> + <div onmouseover="" onclick="" onmouseout="" style="height: 6px; position: absolute;" class="pre noprint docinfo bgblue" title="Click for colour legend."> </div> + <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="" onmouseout=""> + </div> + </div> +<span class="pre noprint docinfo top">[<a href="https://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="https://tools.ietf.org/rfc/rfc3977.txt" title="Plaintext version of this document">txt</a>|<a href="https://tools.ietf.org/pdf/rfc3977" title="PDF version of this document">pdf</a>] [<a href="https://tools.ietf.org/html/draft-ietf-nntpext-base" title="draft-ietf-nntpext-base">draft-ietf-nntpex...</a>] [<a href="https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc3977" title="Inline diff (wdiff)">Diff1</a>] [<a href="https://tools.ietf.org/rfcdiff?url2=rfc3977" title="Side-by-side diff">Diff2</a>] [<a href="https://www.rfc-editor.org/errata_search.php?rfc=3977">Errata</a>] </span><br> +<span class="pre noprint docinfo"> </span><br> +<span class="pre noprint docinfo">Updated by: <a href="https://tools.ietf.org/html/rfc6048">6048</a> PROPOSED STANDARD</span><br> +<span class="pre noprint docinfo"> <span style="color: #C00;">Errata Exist</span></span><br> +<pre>Network Working Group C. Feather +Request for Comments: 3977 THUS plc +Obsoletes: <a href="https://tools.ietf.org/html/rfc977">977</a> October 2006 +Updates: <a href="https://tools.ietf.org/html/rfc2980">2980</a> +Category: Standards Track + + + <span class="h1"><h1>Network News Transfer Protocol (NNTP)</h1></span> + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Network News Transfer Protocol (NNTP) has been in use in the + Internet for a decade, and remains one of the most popular protocols + (by volume) in use today. This document is a replacement for + <a href="https://tools.ietf.org/html/rfc977">RFC 977</a>, and officially updates the protocol specification. It + clarifies some vagueness in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a>, includes some new base + functionality, and provides a specific mechanism to add standardized + extensions to NNTP. + +Table of Contents + + <a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a> + <a href="#section-1.1">1.1</a>. Author's Note . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a> + <a href="#section-2">2</a>. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a> + <a href="#section-3">3</a>. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a> + <a href="#section-3.1">3.1</a>. Commands and Responses . . . . . . . . . . . . . . . . . <a href="#page-6">6</a> + <a href="#section-3.1.1">3.1.1</a>. Multi-line Data Blocks . . . . . . . . . . . . . . . . <a href="#page-8">8</a> + <a href="#section-3.2">3.2</a>. Response Codes . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a> + <a href="#section-3.2.1">3.2.1</a>. Generic Response Codes . . . . . . . . . . . . . . . <a href="#page-10">10</a> + <a href="#section-3.2.1.1">3.2.1.1</a>. Examples . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a> + <a href="#section-3.3">3.3</a>. Capabilities and Extensions . . . . . . . . . . . . . . . <a href="#page-14">14</a> + <a href="#section-3.3.1">3.3.1</a>. Capability Descriptions . . . . . . . . . . . . . . . <a href="#page-14">14</a> + <a href="#section-3.3.2">3.3.2</a>. Standard Capabilities . . . . . . . . . . . . . . . . <a href="#page-15">15</a> + <a href="#section-3.3.3">3.3.3</a>. Extensions . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a> + <a href="#section-3.3.4">3.3.4</a>. Initial IANA Register . . . . . . . . . . . . . . . . <a href="#page-18">18</a> + <a href="#section-3.4">3.4</a>. Mandatory and Optional Commands . . . . . . . . . . . . . <a href="#page-20">20</a> + + + +<span class="grey">Feather Standards Track [Page 1]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + <a href="#section-3.4.1">3.4.1</a>. Reading and Transit Servers . . . . . . . . . . . . . <a href="#page-21">21</a> + <a href="#section-3.4.2">3.4.2</a>. Mode Switching . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a> + <a href="#section-3.5">3.5</a>. Pipelining . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a> + <a href="#section-3.5.1">3.5.1</a>. Examples . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a> + <a href="#section-3.6">3.6</a>. Articles . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a> + <a href="#section-4">4</a>. The WILDMAT Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a> + <a href="#section-4.1">4.1</a>. Wildmat Syntax . . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a> + <a href="#section-4.2">4.2</a>. Wildmat Semantics . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a> + <a href="#section-4.3">4.3</a>. Extensions . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a> + <a href="#section-4.4">4.4</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a> + <a href="#section-5">5</a>. Session Administration Commands . . . . . . . . . . . . . . . <a href="#page-28">28</a> + <a href="#section-5.1">5.1</a>. Initial Connection . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a> + <a href="#section-5.2">5.2</a>. CAPABILITIES . . . . . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a> + <a href="#section-5.3">5.3</a>. MODE READER . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a> + <a href="#section-5.4">5.4</a>. QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a> + <a href="#section-6">6</a>. Article Posting and Retrieval . . . . . . . . . . . . . . . . <a href="#page-35">35</a> + <a href="#section-6.1">6.1</a>. Group and Article Selection . . . . . . . . . . . . . . . <a href="#page-36">36</a> + <a href="#section-6.1.1">6.1.1</a>. GROUP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-36">36</a> + <a href="#section-6.1.2">6.1.2</a>. LISTGROUP . . . . . . . . . . . . . . . . . . . . . . <a href="#page-39">39</a> + <a href="#section-6.1.3">6.1.3</a>. LAST . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-42">42</a> + <a href="#section-6.1.4">6.1.4</a>. NEXT . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-44">44</a> + <a href="#section-6.2">6.2</a>. Retrieval of Articles and Article Sections . . . . . . . <a href="#page-45">45</a> + <a href="#section-6.2.1">6.2.1</a>. ARTICLE . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-46">46</a> + <a href="#section-6.2.2">6.2.2</a>. HEAD . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-49">49</a> + <a href="#section-6.2.3">6.2.3</a>. BODY . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-51">51</a> + <a href="#section-6.2.4">6.2.4</a>. STAT . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-53">53</a> + <a href="#section-6.3">6.3</a>. Article Posting . . . . . . . . . . . . . . . . . . . . . <a href="#page-56">56</a> + <a href="#section-6.3.1">6.3.1</a>. POST . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-56">56</a> + <a href="#section-6.3.2">6.3.2</a>. IHAVE . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-58">58</a> + <a href="#section-7">7</a>. Information Commands . . . . . . . . . . . . . . . . . . . . <a href="#page-61">61</a> + <a href="#section-7.1">7.1</a>. DATE . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-61">61</a> + <a href="#section-7.2">7.2</a>. HELP . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-62">62</a> + <a href="#section-7.3">7.3</a>. NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-63">63</a> + <a href="#section-7.4">7.4</a>. NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-64">64</a> + <a href="#section-7.5">7.5</a>. Time . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-65">65</a> + <a href="#section-7.5.1">7.5.1</a>. Examples . . . . . . . . . . . . . . . . . . . . . . <a href="#page-66">66</a> + <a href="#section-7.6">7.6</a>. The LIST Commands . . . . . . . . . . . . . . . . . . . . <a href="#page-66">66</a> + <a href="#section-7.6.1">7.6.1</a>. LIST . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-67">67</a> + <a href="#section-7.6.2">7.6.2</a>. Standard LIST Keywords . . . . . . . . . . . . . . . <a href="#page-69">69</a> + <a href="#section-7.6.3">7.6.3</a>. LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . <a href="#page-70">70</a> + <a href="#section-7.6.4">7.6.4</a>. LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . <a href="#page-71">71</a> + <a href="#section-7.6.5">7.6.5</a>. LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . <a href="#page-72">72</a> + <a href="#section-7.6.6">7.6.6</a>. LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . <a href="#page-73">73</a> + <a href="#section-8">8</a>. Article Field Access Commands . . . . . . . . . . . . . . . . <a href="#page-73">73</a> + <a href="#section-8.1">8.1</a>. Article Metadata . . . . . . . . . . . . . . . . . . . . <a href="#page-74">74</a> + <a href="#section-8.1.1">8.1.1</a>. The :bytes Metadata Item . . . . . . . . . . . . . . <a href="#page-74">74</a> + <a href="#section-8.1.2">8.1.2</a>. The :lines Metadata Item . . . . . . . . . . . . . . <a href="#page-75">75</a> + <a href="#section-8.2">8.2</a>. Database Consistency . . . . . . . . . . . . . . . . . . <a href="#page-75">75</a> + + + +<span class="grey">Feather Standards Track [Page 2]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + <a href="#section-8.3">8.3</a>. OVER . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-76">76</a> + <a href="#section-8.4">8.4</a>. LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . . <a href="#page-81">81</a> + <a href="#section-8.5">8.5</a>. HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-83">83</a> + <a href="#section-8.6">8.6</a>. LIST HEADERS . . . . . . . . . . . . . . . . . . . . . . <a href="#page-87">87</a> + <a href="#section-9">9</a>. Augmented BNF Syntax for NNTP . . . . . . . . . . . . . . . . <a href="#page-90">90</a> + <a href="#section-9.1">9.1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . <a href="#page-90">90</a> + <a href="#section-9.2">9.2</a>. Commands . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-92">92</a> + <a href="#section-9.3">9.3</a>. Command Continuation . . . . . . . . . . . . . . . . . . <a href="#page-93">93</a> + <a href="#section-9.4">9.4</a>. Responses . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-93">93</a> + <a href="#section-9.4.1">9.4.1</a>. Generic Responses . . . . . . . . . . . . . . . . . . <a href="#page-93">93</a> + <a href="#section-9.4.2">9.4.2</a>. Initial Response Line Contents . . . . . . . . . . . <a href="#page-94">94</a> + <a href="#section-9.4.3">9.4.3</a>. Multi-line Response Contents . . . . . . . . . . . . <a href="#page-94">94</a> + <a href="#section-9.5">9.5</a>. Capability Lines . . . . . . . . . . . . . . . . . . . . <a href="#page-95">95</a> + <a href="#section-9.6">9.6</a>. LIST Variants . . . . . . . . . . . . . . . . . . . . . . <a href="#page-96">96</a> + <a href="#section-9.7">9.7</a>. Articles . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-97">97</a> + <a href="#section-9.8">9.8</a>. General Non-terminals . . . . . . . . . . . . . . . . . . <a href="#page-97">97</a> + <a href="#section-9.9">9.9</a>. Extensions and Validation . . . . . . . . . . . . . . . . <a href="#page-99">99</a> + <a href="#section-10">10</a>. Internationalisation Considerations . . . . . . . . . . . . .<a href="#page-100">100</a> + <a href="#section-10.1">10.1</a>. Introduction and Historical Situation . . . . . . . . . .<a href="#page-100">100</a> + <a href="#section-10.2">10.2</a>. This Specification . . . . . . . . . . . . . . . . . . .<a href="#page-101">101</a> + <a href="#section-10.3">10.3</a>. Outstanding Issues . . . . . . . . . . . . . . . . . . .<a href="#page-102">102</a> + <a href="#section-11">11</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . .<a href="#page-103">103</a> + <a href="#section-12">12</a>. Security Considerations . . . . . . . . . . . . . . . . . . .<a href="#page-103">103</a> + <a href="#section-12.1">12.1</a>. Personal and Proprietary Information . . . . . . . . . .<a href="#page-104">104</a> + <a href="#section-12.2">12.2</a>. Abuse of Server Log Information . . . . . . . . . . . . .<a href="#page-104">104</a> + <a href="#section-12.3">12.3</a>. Weak Authentication and Access Control . . . . . . . . .<a href="#page-104">104</a> + <a href="#section-12.4">12.4</a>. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . .<a href="#page-104">104</a> + <a href="#section-12.5">12.5</a>. UTF-8 Issues . . . . . . . . . . . . . . . . . . . . . .<a href="#page-105">105</a> + <a href="#section-12.6">12.6</a>. Caching of Capability Lists . . . . . . . . . . . . . . .<a href="#page-106">106</a> + <a href="#section-13">13</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .<a href="#page-107">107</a> + <a href="#section-14">14</a>. References . . . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-110">110</a> + <a href="#section-14.1">14.1</a>. Normative References . . . . . . . . . . . . . . . . . .<a href="#page-110">110</a> + <a href="#section-14.2">14.2</a>. Informative References . . . . . . . . . . . . . . . . .<a href="#page-110">110</a> + <a href="#appendix-A">A</a>. Interaction with Other Specifications . . . . . . . . . . . .<a href="#page-112">112</a> + <a href="#appendix-A.1">A.1</a>. Header Folding . . . . . . . . . . . . . . . . . . . . .<a href="#page-112">112</a> + <a href="#appendix-A.2">A.2</a>. Message-IDs . . . . . . . . . . . . . . . . . . . . . . .<a href="#page-112">112</a> + <a href="#appendix-A.3">A.3</a>. Article Posting . . . . . . . . . . . . . . . . . . . . .<a href="#page-114">114</a> + <a href="#appendix-B">B</a>. Summary of Commands . . . . . . . . . . . . . . . . . . . . .<a href="#page-115">115</a> + <a href="#appendix-C">C</a>. Summary of Response Codes . . . . . . . . . . . . . . . . . .<a href="#page-117">117</a> + <a href="#appendix-D">D</a>. Changes from <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> . . . . . . . . . . . . . . . . . . . .<a href="#page-121">121</a> + +<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</h2></span> + + This document specifies the Network News Transfer Protocol (NNTP), + which is used for the distribution, inquiry, retrieval, and posting + of Netnews articles using a reliable stream-based mechanism. For + news-reading clients, NNTP enables retrieval of news articles that + + + + +<span class="grey">Feather Standards Track [Page 3]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + are stored in a central database, giving subscribers the ability to + select only those articles they wish to read. + + The Netnews model provides for indexing, cross-referencing, and + expiration of aged messages. NNTP is designed for efficient + transmission of Netnews articles over a reliable full duplex + communication channel. + + Although the protocol specification in this document is largely + compatible with the version specified in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> [<a href="https://tools.ietf.org/html/rfc977" title='"Network News Transfer Protocol"'>RFC977</a>], a number + of changes are summarised in <a href="#appendix-D">Appendix D</a>. In particular: + + o the default character set is changed from US-ASCII [<a href="#ref-ANSI1986" title='"Coded Character Set - 7-bit American Standard Code for Information Interchange"'>ANSI1986</a>] to + UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>] (note that US-ASCII is a subset of UTF-8); + + o a number of commands that were optional in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> or that have + been taken from <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> [<a href="https://tools.ietf.org/html/rfc2980" title='"Common NNTP Extensions"'>RFC2980</a>] are now mandatory; and + + o a CAPABILITIES command has been added to allow clients to + determine what functionality is available from a server. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a> [<a href="https://tools.ietf.org/html/rfc2119" title='"Key words for use in RFCs to Indicate Requirement Levels"'>RFC2119</a>]. + + An implementation is not compliant if it fails to satisfy one or more + of the MUST requirements for this protocol. An implementation that + satisfies all the MUST and all the SHOULD requirements for its + protocols is said to be "unconditionally compliant"; one that + satisfies all the MUST requirements but not all the SHOULD + requirements for NNTP is said to be "conditionally compliant". + + For the remainder of this document, the terms "client" and "client + host" refer to a host making use of the NNTP service, while the terms + "server" and "server host" refer to a host that offers the NNTP + service. + +<span class="h3"><h3><a class="selflink" name="section-1.1" href="#section-1.1">1.1</a>. Author's Note</h3></span> + + This document is written in XML using an NNTP-specific DTD. Custom + software is used to convert this to <a href="https://tools.ietf.org/html/rfc2629">RFC 2629</a> [<a href="https://tools.ietf.org/html/rfc2629" title='"Writing I-Ds and RFCs using XML"'>RFC2629</a>] format, and + then the public "xml2rfc" package to further reduce this to text, + nroff source, and HTML. + + No perl was used in producing this document. + + + + + + +<span class="grey">Feather Standards Track [Page 4]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>. Notation</h2></span> + + The following notational conventions are used in this document. + + UPPERCASE indicates literal text to be included in the + command. + + lowercase indicates a token described elsewhere. + + [<a name="ref-brackets" id="ref-brackets">brackets</a>] indicate that the enclosed material is optional. + + elliptical indicates that the argument may be repeated any + ... marks number of times (it must occur at least once). + + vertical|bar indicates a choice of two mutually exclusive + arguments (exactly one must be provided). + + The name "message-id" for a command or response argument indicates + that it is the message-id of an article as described in <a href="#section-3.6">Section 3.6</a>, + including the angle brackets. + + The name "wildmat" for an argument indicates that it is a wildmat as + defined in <a href="#section-4">Section 4</a>. If the argument does not meet the requirements + of that section (for example, if it does not fit the grammar of + <a href="#section-4.1">Section 4.1</a>), the NNTP server MAY place some interpretation on it + (not specified by this document) or otherwise MUST treat it as a + syntax error. + + Responses for each command will be described in tables listing the + required format of a response followed by the meaning that should be + ascribed to that response. + + The terms "NUL", "TAB", "LF", "CR, and "space" refer to the octets + %x00, %x09, %x0A, %x0D, and %x20, respectively (that is, the octets + with those codes in US-ASCII [<a href="#ref-ANSI1986" title='"Coded Character Set - 7-bit American Standard Code for Information Interchange"'>ANSI1986</a>] and thus in UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>]). + The term "CRLF" or "CRLF pair" means the sequence CR immediately + followed by LF (that is, %x0D.0A). A "printable US-ASCII character" + is an octet in the range %x21-7E. Quoted characters refer to the + octets with those codes in US-ASCII (so "." and "<" refer to %x2E and + %x3C) and will always be printable US-ASCII characters; similarly, + "digit" refers to the octets %x30-39. + + A "keyword" MUST consist only of US-ASCII letters, digits, and the + characters dot (".") and dash ("-") and MUST begin with a letter. + Keywords MUST be at least three characters in length. + + + + + + +<span class="grey">Feather Standards Track [Page 5]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Examples in this document are not normative but serve to illustrate + usages, arguments, and responses. In the examples, a "[<a href="#ref-C" title='"Demo User"'>C</a>]" will be + used to represent the client host and an "[S]" will be used to + represent the server host. Most of the examples do not rely on a + particular server state. In some cases, however, they do assume that + the currently selected newsgroup (see the GROUP command, + <a href="#section-6.1.1">Section 6.1.1</a>) is invalid; when so, this is indicated at the start of + the example. Examples may use commands or other keywords not defined + in this specification (such as an XENCRYPT command). These will be + used to illustrate some point and do not imply that any such command + is defined elsewhere or needs to exist in any particular + implementation. + + Terms that might be read as specifying details of a client or server + implementation, such as "database", are used simply to ease + description. Provided that implementations conform to the protocol + and format specifications in this document, no specific technique is + mandated. + +<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>. Basic Concepts</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. Commands and Responses</h3></span> + + NNTP operates over any reliable bi-directional 8-bit-wide data stream + channel. When the connection is established, the NNTP server host + MUST send a greeting. The client host and server host then exchange + commands and responses (respectively) until the connection is closed + or aborted. If the connection used is TCP, then the server host + starts the NNTP service by listening on a TCP port. When a client + host wishes to make use of the service, it MUST establish a TCP + connection with the server host by connecting to that host on the + same port on which the server is listening. + + The character set for all NNTP commands is UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>]. Commands + in NNTP MUST consist of a keyword, which MAY be followed by one or + more arguments. A CRLF pair MUST terminate all commands. Multiple + commands MUST NOT be on the same line. Unless otherwise noted + elsewhere in this document, arguments SHOULD consist of printable US- + ASCII characters. Keywords and arguments MUST each be separated by + one or more space or TAB characters. Command lines MUST NOT exceed + 512 octets, which includes the terminating CRLF pair. The 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 + of 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, + encoding %xE2.91.A0) for the meaning Zero Width No-Break Space in + + + +<span class="grey">Feather Standards Track [Page 6]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + command lines and the initial lines of responses. Implementations + SHOULD apply these same principles throughout. + + The term "character" means a single Unicode code point. + Implementations are not required to carry out Unicode normalisation. + Thus, U+0084 (A-dieresis) is one character, while U+0041 U+0308 (A + composed with dieresis) is two; the two need not be treated as + equivalent. + + Commands may have variants; if so, they use a second keyword + immediately after the first to indicate which variant is required. + The only such commands in this specification are LIST and MODE. Note + that such variants are sometimes referred to as if they were commands + in their own right: "the LIST ACTIVE" command should be read as + shorthand for "the ACTIVE variant of the LIST command". + + Keywords are case insensitive; the case of keywords for commands MUST + be ignored by the server. Command and response arguments are case or + language specific only when stated, either in this document or in + other relevant specifications. + + In some cases, a command involves more data than just a single line. + The further data may be sent either immediately after the command + line (there are no instances of this in this specification, but there + are in extensions such as [<a href="#ref-NNTP-STREAM" title='"Network News Transfer Protocol (NNTP) Extension for Streaming Feeds"'>NNTP-STREAM</a>]) or following a request from + the server (indicated by a 3xx response). + + Each response MUST start with a three-digit response code that is + sufficient to distinguish all responses. Certain valid responses are + defined to be multi-line; for all others, the response is contained + in a single line. The initial line of the response MUST NOT exceed + 512 octets, which includes the response code and the terminating CRLF + pair; an extension MAY specify a greater maximum for commands that it + defines, but not for any other command. Single-line responses + consist of an initial line only. Multi-line responses consist of an + initial line followed by a multi-line data block. + + An NNTP server MAY have an inactivity autologout timer. Such a timer + 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 wait for the first command from the client. The receipt of any + command from the client during the timer interval SHOULD suffice to + reset the autologout timer. Similarly, the receipt of any + significant amount of data from a client that is sending a multi-line + data block (such as during a POST or IHAVE command) SHOULD suffice to + reset the autologout timer. When the timer expires, the server + SHOULD close the connection without sending any response to the + client. + + + +<span class="grey">Feather Standards Track [Page 7]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Multi-line Data Blocks</h4></span> + + A multi-line data block is used in certain commands and responses. + It MUST adhere to the following rules: + + 1. The block consists of a sequence of zero or more "lines", each + being a stream of octets ending with a CRLF pair. Apart from + those line endings, the stream MUST NOT include the octets NUL, + LF, or CR. + + 2. In a multi-line response, the block immediately follows the CRLF + at the end of the initial line of the response. When used in any + other context, the specific command will define when the block is + sent. + + 3. If any line of the data block begins with the "termination octet" + ("." or %x2E), that line MUST be "dot-stuffed" by prepending an + additional termination octet to that line of the block. + + 4. The lines of the block MUST be followed by a terminating line + consisting of a single termination octet followed by a CRLF pair + in the normal way. Thus, unless it is empty, a multi-line block + is always terminated with the five octets CRLF "." CRLF + (%x0D.0A.2E.0D.0A). + + 5. When a multi-line block is interpreted, the "dot-stuffing" MUST + be undone; i.e., the recipient MUST ensure that, in any line + beginning with the termination octet followed by octets other + than a CRLF pair, that initial termination octet is disregarded. + + 6. Likewise, the terminating line ("." CRLF or %x2E.0D.0A) MUST NOT + be considered part of the multi-line block; i.e., the recipient + MUST ensure that any line beginning with the termination octet + followed immediately by a CRLF pair is disregarded. (The first + CRLF pair of the terminating CRLF "." CRLF of a non-empty block + is, of course, part of the last line of the block.) + + 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 + reliably conveyed in the above format (that is, they violate the MUST + requirement above). However, except when stated otherwise, this + specification does not require the content to be UTF-8, and therefore + (subject to that same requirement) it MAY include octets above and + below 128 mixed arbitrarily. + + This document does not place any limit on the length of a line in a + multi-line block. However, the standards that define the format of + articles may do so. + + + +<span class="grey">Feather Standards Track [Page 8]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h3"><h3><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. Response Codes</h3></span> + + Each response MUST begin with a three-digit status indicator. These + are status reports from the server and indicate the response to the + last command received from the client. + + The first digit of the response broadly indicates the success, + failure, or progress of the previous command: + + 1xx - Informative message + 2xx - Command completed OK + 3xx - Command OK so far; send the rest of it + 4xx - Command was syntactically correct but failed for some reason + 5xx - Command unknown, unsupported, unavailable, or syntax error + + The next digit in the code indicates the function response category: + + x0x - Connection, setup, and miscellaneous messages + x1x - Newsgroup selection + x2x - Article selection + x3x - Distribution functions + x4x - Posting + x8x - Reserved for authentication and privacy extensions + x9x - Reserved for private use (non-standard extensions) + + Certain responses contain arguments such as numbers and names in + addition to the status indicator. In those cases, to simplify + interpretation by the client, the number and type of such arguments + is fixed for each response code, as is whether the code is + single-line or multi-line. Any extension MUST follow this principle + as well. Note that, for historical reasons, the 211 response code is + an exception to this in that the response may be single-line or + multi-line depending on the command (GROUP or LISTGROUP) that + generated it. In all other cases, the client MUST only use the + status indicator itself to determine the nature of the response. The + exact response codes that can be returned by any given command are + detailed in the description of that command. + + Arguments MUST be separated from the numeric status indicator and + from each other by a single space. All numeric arguments MUST be in + base 10 (decimal) format and MAY have leading zeros. String + arguments MUST contain at least one character and MUST NOT contain + TAB, LF, CR, or space. The server MAY add any text after the + response code or last argument, as appropriate, and the client MUST + NOT make decisions based on this text. Such text MUST be separated + from the numeric status indicator or the last argument by at least + one space. + + + + +<span class="grey">Feather Standards Track [Page 9]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + The server MUST respond to any command with the appropriate generic + response (given in <a href="#section-3.2.1">Section 3.2.1</a>) if it represents the situation. + Otherwise, each recognized command MUST return one of the response + codes specifically listed in its description or in an extension. A + server MAY provide extensions to this specification, including new + commands, new variants or features of existing commands, and other + ways of changing the internal state of the server. However, the + server MUST NOT produce any other responses to a client that does not + invoke any of the additional features. (Therefore, a client that + restricts itself to this specification will only receive the + responses that are listed.) + + If a client receives an unexpected response, it SHOULD use the first + digit of the response to determine the result. For example, an + unexpected 2xx should be taken as success, and an unexpected 4xx or + 5xx as failure. + + Response codes not specified in this document MAY be used for any + installation-specific additional commands also not specified. These + SHOULD be chosen to fit the pattern of x9x specified above. + + Neither this document nor any registered extension (see + <a href="#section-3.3.3">Section 3.3.3</a>) will specify any response codes of the x9x pattern. + (Implementers of extensions are accordingly cautioned not to use such + responses for extensions that may subsequently be submitted for + registration.) + +<span class="h4"><h4><a class="selflink" name="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Generic Response Codes</h4></span> + + The server MUST respond to any command with the appropriate one of + the following generic responses if it represents the situation. + + If the command is not recognized, or if it is an optional command + that is not implemented by the server, the response code 500 MUST be + returned. + + If there is a syntax error in the arguments of a recognized command, + including the case where more arguments are provided than the command + specifies or the command line is longer than the server accepts, the + response code 501 MUST be returned. The line MUST NOT be truncated + or split and then interpreted. Note that where a command has + variants depending on a second keyword (e.g., LIST ACTIVE and LIST + NEWSGROUPS), 501 MUST be used when the base command is implemented + but the requested variant is not, and 500 MUST be used only when the + base command itself is not implemented. + + If an argument is required to be a base64-encoded string [<a href="https://tools.ietf.org/html/rfc4648" title='"The Base16, Base32, and Base64 Data Encodings"'>RFC4648</a>] + (there are no such arguments in this specification, but there may be + + + +<span class="grey">Feather Standards Track [Page 10]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + in extensions) and is not validly encoded, the response code 504 MUST + be returned. + + 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 + missing or a necessary service could not be contacted), the response + code 403 MUST be returned. If the server recognizes the command but + does not provide an optional feature (for example, because it does + not store the required information), or if it only handles a subset + of legitimate cases (see the HDR command, <a href="#section-8.5">Section 8.5</a>, for an + example), the response code 503 MUST be returned. + + If the client is not authorized to use the specified facility when + the server is in its current state, then the appropriate one of the + following response codes MUST be used. + + 502: It is necessary to terminate the connection and to start a new + one with the appropriate authority before the command can be used. + Historically, some mode-switching servers (see <a href="#section-3.4.1">Section 3.4.1</a>) used + this response to indicate that this command will become available + after the MODE READER command (<a href="#section-5.3">Section 5.3</a>) is used, but this + usage does not conform to this specification and MUST NOT be used. + Note that the server MUST NOT close the connection immediately + after a 502 response except at the initial connection + (<a href="#section-5.1">Section 5.1</a>) and with the MODE READER command. + + 480: The client must authenticate itself to the server (that is, it + must provide information as to the identity of the client) before + the facility can be used on this connection. This will involve + the use of an authentication extension such as [<a href="#ref-NNTP-AUTH" title='"Network News Transfer Protocol (NNTP) Extension for Authentication"'>NNTP-AUTH</a>]. + + 483: The client must negotiate appropriate privacy protection on the + connection. This will involve the use of a privacy extension such + as [<a href="#ref-NNTP-TLS" title='"Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)"'>NNTP-TLS</a>]. + + 401: The client must change the state of the connection in some other + manner. The first argument of the response MUST be the capability + label (see <a href="#section-5.2">Section 5.2</a>) of the facility that provides the + necessary mechanism (usually an extension, which may be a private + extension). The server MUST NOT use this response code except as + specified by the definition of the capability in question. + + If the server has to terminate the connection for some reason, it + MUST give a 400 response code to the next command and then + immediately close the connection. Following a 400 response, clients + SHOULD NOT simply reconnect immediately and retry the same actions. + Rather, a client SHOULD either use an exponentially increasing delay + between retries (e.g., double the waiting time after each 400 + + + +<span class="grey">Feather Standards Track [Page 11]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + response) or present any associated text to the user for them to + decide whether and when to retry. + + The client MUST be prepared to receive any of these responses for any + command (except, of course, that the server MUST NOT generate a 500 + response code for mandatory commands). + +<span class="h5"><h5><a class="selflink" name="section-3.2.1.1" href="#section-3.2.1.1">3.2.1.1</a>. Examples</h5></span> + + Example of an unknown command: + + [<a name="ref-C" id="ref-C">C</a>] MAIL + [S] 500 Unknown command + + Example of an unsupported command: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] NEWNEWS + [S] LIST ACTIVE NEWSGROUPS + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] OVER + [S] 500 Unknown command + + Example of an unsupported variant: + + [<a name="ref-C" id="ref-C">C</a>] MODE POSTER + [S] 501 Unknown MODE option + + Example of a syntax error: + + [<a name="ref-C" id="ref-C">C</a>] ARTICLE a.message.id@no.angle.brackets + [S] 501 Syntax error + + Example of an overlong command line: + + [<a name="ref-C" id="ref-C">C</a>] HEAD 53 54 55 + [S] 501 Too many arguments + + Example of a bad wildmat: + + [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE u[ks].* + [S] 501 Syntax error + + + + + + +<span class="grey">Feather Standards Track [Page 12]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of a base64-encoding error (the second argument is meant to + be base64 encoded): + + [<a name="ref-C" id="ref-C">C</a>] XENCRYPT RSA abcd=efg + [S] 504 Base64 encoding error + + Example of an attempt to access a facility not available to this + connection: + + [<a name="ref-C" id="ref-C">C</a>] MODE READER + [S] 200 Reader mode, posting permitted + [<a href="#ref-C" title='"Demo User"'>C</a>] IHAVE <i.am.an.article.you.will.want@example.com> + [S] 500 Permission denied + + Example of an attempt to access a facility requiring authentication: + + [<a name="ref-C" id="ref-C">C</a>] GROUP secret.group + [S] 480 Permission denied + + Example of a successful attempt following such authentication: + + [<a name="ref-C" id="ref-C">C</a>] XSECRET fred flintstone + [S] 290 Password for fred accepted + [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP secret.group + [S] 211 5 1 20 secret.group selected + + Example of an attempt to access a facility requiring privacy: + + [<a name="ref-C" id="ref-C">C</a>] GROUP secret.group + [S] 483 Secure connection required + [<a href="#ref-C" title='"Demo User"'>C</a>] XENCRYPT + [Client and server negotiate encryption on the link] + [S] 283 Encrypted link established + [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP secret.group + [S] 211 5 1 20 secret.group selected + + Example of a need to change mode before a facility is used: + + [<a name="ref-C" id="ref-C">C</a>] GROUP binary.group + [S] 401 XHOST Not on this virtual host + [<a href="#ref-C" title='"Demo User"'>C</a>] XHOST binary.news.example.org + [S] 290 binary.news.example.org virtual host selected + [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP binary.group + [S] 211 5 1 77 binary.group selected + + + + + + + +<span class="grey">Feather Standards Track [Page 13]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of a temporary failure: + + [<a name="ref-C" id="ref-C">C</a>] GROUP archive.local + [S] 403 Archive server temporarily offline + + Example of the server needing to close down immediately: + + [<a name="ref-C" id="ref-C">C</a>] ARTICLE 123 + [S] 400 Power supply failed, running on UPS + [Server closes connection.] + +<span class="h3"><h3><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>. Capabilities and Extensions</h3></span> + + Not all NNTP servers provide exactly the same facilities, both + because this specification allows variation and because servers may + provide extensions. A set of facilities that are related are called + a "capability". This specification provides a way to determine what + capabilities are available, includes a list of standard capabilities, + and includes a mechanism (the extension mechanism) for defining new + capabilities. + +<span class="h4"><h4><a class="selflink" name="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Capability Descriptions</h4></span> + + A client can determine the available capabilities of the server by + using the CAPABILITIES command (<a href="#section-5.2">Section 5.2</a>). This returns a + capability list, which is a list of capability lines. Each line + describes one available capability. + + Each capability line consists of one or more tokens, which MUST be + separated by one or more space or TAB characters. A token is a + string of 1 or more printable UTF-8 characters (that is, either + printable US-ASCII characters or any UTF-8 sequence outside the US- + ASCII range, but not space or TAB). Unless stated otherwise, tokens + are case insensitive. Each capability line consists of the + following: + + o The capability label, which is a keyword indicating the + capability. A capability label may be defined by this + specification or a successor, or by an extension. + + o The label is then followed by zero or more tokens, which are + arguments of the capability. The form and meaning of these tokens + is specific to each capability. + + The server MUST ensure that the capability list accurately reflects + the capabilities (including extensions) currently available. If a + capability is only available with the server in a certain state (for + example, only after authentication), the list MUST only include the + + + +<span class="grey">Feather Standards Track [Page 14]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + capability label when the server is in that state. Similarly, if + only some of the commands in an extension will be available, or if + the behaviour of the extension will change in some other manner, + according to the state of the server, this MUST be indicated by + different arguments in the capability line. + + Note that a capability line can only begin with a letter. Lines + beginning with other characters are reserved for future versions of + this specification. In order to interoperate with such versions, + clients MUST be prepared to receive lines beginning with other + characters and MUST ignore any they do not understand. + +<span class="h4"><h4><a class="selflink" name="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Standard Capabilities</h4></span> + + The following capabilities are defined by this specification. + + VERSION + This capability MUST be advertised by all servers and MUST be the + first capability in the capability list; it indicates the + version(s) of NNTP that the server supports. There must be at + least one argument; each argument is a decimal number and MUST NOT + have a leading zero. Version numbers are assigned only in RFCs + that update or replace this specification; servers MUST NOT create + their own version numbers. + + The version number of this specification is 2. + + READER + This capability indicates that the server implements the various + commands useful for reading clients. + + IHAVE + This capability indicates that the server implements the IHAVE + command. + + POST + This capability indicates that the server implements the POST + command. + + NEWNEWS + This capability indicates that the server implements the NEWNEWS + command. + + HDR + This capability indicates that the server implements the header + access commands (HDR and LIST HEADERS). + + + + + +<span class="grey">Feather Standards Track [Page 15]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + OVER + This capability indicates that the server implements the overview + access commands (OVER and LIST OVERVIEW.FMT). If and only if the + server supports the message-id form of the OVER command, there + must be a single argument MSGID. + + LIST + This capability indicates that the server implements at least one + variant of the LIST command. There MUST be one argument for each + variant of the LIST command supported by the server, giving the + keyword for that variant. + + IMPLEMENTATION + This capability MAY be provided by a server. If so, the arguments + SHOULD be used to provide information such as the server software + name and version number. The client MUST NOT use this line to + determine capabilities of the server. (While servers often + provide this information in the initial greeting, clients need to + guess whether this is the case; this capability makes it clear + what the information is.) + + MODE-READER + This capability indicates that the server is mode-switching + (<a href="#section-3.4.2">Section 3.4.2</a>) and that the MODE READER command needs to be used + to enable the READER capability. + +<span class="h4"><h4><a class="selflink" name="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Extensions</h4></span> + + Although NNTP is widely and robustly deployed, some parts of the + Internet community might wish to extend the NNTP service. It must be + emphasized that any extension to NNTP should not be considered + lightly. NNTP's strength comes primarily from its simplicity. + Experience with many protocols has shown that: + + Protocols with few options tend towards ubiquity, whilst protocols + with many options tend towards obscurity. + + This means that each and every extension, regardless of its benefits, + must be carefully scrutinized with respect to its implementation, + deployment, and interoperability costs. In many cases, the cost of + extending the NNTP service will likely outweigh the benefit. + + An extension is a package of associated facilities, often but not + always including one or more new commands. Each extension MUST + define at least one new capability label (this will often, but need + not, be the name of one of these new commands). While any additional + capability information can normally be specified using arguments to + + + + +<span class="grey">Feather Standards Track [Page 16]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-17" id="page-17" href="#page-17" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + that label, an extension MAY define more than one capability label. + However, this SHOULD be limited to exceptional circumstances. + + An extension is either a private extension, or its capabilities are + included in the IANA registry of capabilities (see <a href="#section-3.3.4">Section 3.3.4</a>) and + it is defined in an RFC (in which case it is a "registered + extension"). Such RFCs either must be on the standards track or must + define an IESG-approved experimental protocol. + + The definition of an extension must include the following: + + o a descriptive name for the extension. + + o the capability label or labels defined by the extension (the + capability label of a registered extension MUST NOT begin with + "X"). + + o The syntax, values, and meanings of any arguments for each + capability label defined by the extension. + + o Any new NNTP commands associated with the extension (the names of + commands associated with registered extensions MUST NOT begin with + "X"). + + o The syntax and possible values of arguments associated with the + new NNTP commands. + + o The response codes and possible values of arguments for the + responses of the new NNTP commands. + + o Any new arguments the extension associates with any other + pre-existing NNTP commands. + + o Any increase in the maximum length of commands and initial + response lines over the value specified in this document. + + o A specific statement about the effect on pipelining that this + extension may have (if any). + + o A specific statement about the circumstances when use of this + extension can alter the contents of the capabilities list (other + than the new capability labels it defines). + + o A specific statement about the circumstances under which the + extension can cause any pre-existing command to produce a 401, + 480, or 483 response. + + + + + +<span class="grey">Feather Standards Track [Page 17]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-18" id="page-18" href="#page-18" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + o A description of how the use of MODE READER on a mode-switching + server interacts with the extension. + + o A description of how support for the extension affects the + behaviour of a server and NNTP client in any other manner not + outlined above. + + o Formal syntax as described in <a href="#section-9.9">Section 9.9</a>. + + A private extension MAY or MAY NOT be included in the capabilities + list. If it is, the capability label MUST begin with "X". A server + MAY provide additional keywords (for new commands and also for new + variants of existing commands) as part of a private extension. To + avoid the risk of a clash with a future registered extension, these + keywords SHOULD begin with "X". + + If the server advertises a capability defined by a registered + extension, it MUST implement the extension so as to fully conform + with the specification (for example, it MUST implement all the + commands that the extension describes as mandatory). If it does not + implement the extension as specified, it MUST NOT list the extension + in the capabilities list under its registered name. In that case, it + MAY, but SHOULD NOT, provide a private extension (not listed, or + listed with a different name) that implements part of the extension + or implements the commands of the extension with a different meaning. + + A server MUST NOT send different response codes to basic NNTP + commands documented here or to commands documented in registered + extensions in response to the availability or use of a private + extension. + +<span class="h4"><h4><a class="selflink" name="section-3.3.4" href="#section-3.3.4">3.3.4</a>. Initial IANA Register</h4></span> + + IANA will maintain a registry of NNTP capability labels. All + capability labels in the registry MUST be keywords and MUST NOT begin + with X. + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 18]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-19" id="page-19" href="#page-19" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + The initial content of the registry consists of these entries: + + +-------------------+--------------------------+--------------------+ + | Label | Meaning | Definition | + +-------------------+--------------------------+--------------------+ + | AUTHINFO | Authentication | [<a href="#ref-NNTP-AUTH" title='"Network News Transfer Protocol (NNTP) Extension for Authentication"'>NNTP-AUTH</a>] | + | | | | + | HDR | Batched header retrieval | <a href="#section-3.3.2">Section 3.3.2</a>, | + | | | <a href="#section-8.5">Section 8.5</a>, and | + | | | <a href="#section-8.6">Section 8.6</a> | + | | | | + | IHAVE | IHAVE command available | <a href="#section-3.3.2">Section 3.3.2</a> and | + | | | <a href="#section-6.3.2">Section 6.3.2</a> | + | | | | + | IMPLEMENTATION | Server | <a href="#section-3.3.2">Section 3.3.2</a> | + | | implementation-specific | | + | | information | | + | | | | + | LIST | LIST command variants | <a href="#section-3.3.2">Section 3.3.2</a> and | + | | | <a href="#section-7.6.1">Section 7.6.1</a> | + | | | | + | MODE-READER | Mode-switching server | <a href="#section-3.4.2">Section 3.4.2</a> | + | | and MODE READER command | | + | | available | | + | | | | + | NEWNEWS | NEWNEWS command | <a href="#section-3.3.2">Section 3.3.2</a> and | + | | available | <a href="#section-7.4">Section 7.4</a> | + | | | | + | OVER | Overview support | <a href="#section-3.3.2">Section 3.3.2</a>, | + | | | <a href="#section-8.3">Section 8.3</a>, and | + | | | <a href="#section-8.4">Section 8.4</a> | + | | | | + | POST | POST command available | <a href="#section-3.3.2">Section 3.3.2</a> and | + | | | <a href="#section-6.3.1">Section 6.3.1</a> | + | | | | + | READER | Reader commands | <a href="#section-3.3.2">Section 3.3.2</a> | + | | available | | + | | | | + | SASL | Supported SASL | [<a href="#ref-NNTP-AUTH" title='"Network News Transfer Protocol (NNTP) Extension for Authentication"'>NNTP-AUTH</a>] | + | | mechanisms | | + | | | | + | STARTTLS | Transport layer security | [<a href="#ref-NNTP-TLS" title='"Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)"'>NNTP-TLS</a>] | + | | | | + | STREAMING | Streaming feeds | [<a href="#ref-NNTP-STREAM" title='"Network News Transfer Protocol (NNTP) Extension for Streaming Feeds"'>NNTP-STREAM</a>] | + | | | | + | VERSION | Supported NNTP versions | <a href="#section-3.3.2">Section 3.3.2</a> | + +-------------------+--------------------------+--------------------+ + + + + +<span class="grey">Feather Standards Track [Page 19]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-20" id="page-20" href="#page-20" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h3"><h3><a class="selflink" name="section-3.4" href="#section-3.4">3.4</a>. Mandatory and Optional Commands</h3></span> + + For a number of reasons, not all the commands in this specification + are mandatory. However, it is equally undesirable for every command + to be optional, since this means that a client will have no idea what + facilities are available. Therefore, as a compromise, some of the + commands in this specification are mandatory (they must be supported + by all servers) while the remainder are not. The latter are then + subdivided into bundles, each indicated by a single capability label. + + o If the label is included in the capability list returned by the + server, the server MUST support all commands in that bundle. + + o If the label is not included, the server MAY support none or some + of the commands but SHOULD NOT support all of them. In general, + there will be no way for a client to determine which commands are + supported without trying them. + + The bundles have been chosen to provide useful functionality, and + therefore server authors are discouraged from implementing only part + of a bundle. + + The description of each command will either indicate that it is + mandatory, or will give, using the term "indicating capability", the + capability label indicating whether the bundle including this command + is available. + + Where a server does not implement a command, it MUST always generate + a 500 generic response code (or a 501 generic response code in the + case of a variant of a command depending on a second keyword where + the base command is recognised). Otherwise, the command MUST be + fully implemented as specified; a server MUST NOT only partially + implement any of the commands in this specification. (Client authors + should note that some servers not conforming to this specification + will return a 502 generic response code to some commands that are not + implemented.) + + Note: some commands have cases that require other commands to be used + first. If the former command is implemented but the latter is not, + the former MUST still generate the relevant specific response code. + For example, if ARTICLE (<a href="#section-6.2.1">Section 6.2.1</a>) is implemented but GROUP + (<a href="#section-6.1.1">Section 6.1.1</a>) is not, the correct response to "ARTICLE 1234" + remains 412. + + + + + + + + +<span class="grey">Feather Standards Track [Page 20]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-21" id="page-21" href="#page-21" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Reading and Transit Servers</h4></span> + + NNTP is traditionally used in two different ways. The first use is + "reading", where the client fetches articles from a large store + maintained by the server for immediate or later presentation to a + user and sends articles created by that user back to the server (an + action called "posting") to be stored and distributed to other stores + and users. The second use is for the bulk transfer of articles from + one store to another. Since the hosts making this transfer tend to + be peers in a network that transmit articles among one another, and + not end-user systems, this process is called "peering" or "transit". + (Even so, one host is still the client and the other is the server). + + In practice, these two uses are so different that some server + implementations are optimised for reading or for transit and, as a + result, do not offer the other facility or only offer limited + features. Other implementations are more general and offer both. + This specification allows for this by bundling the relevant commands + accordingly: the IHAVE command is designed for transit, while the + commands indicated by the READER capability are designed for reading + clients. + + Except as an effect of the MODE READER command (<a href="#section-5.3">Section 5.3</a>) on a + mode-switching server, once a server advertises either or both of the + IHAVE or READER capabilities, it MUST continue to advertise them for + the entire session. + + A server MAY provide different modes of behaviour (transit, reader, + or a combination) to different client connections and MAY use + external information, such as the IP address of the client, to + determine which mode to provide to any given connection. + + The official TCP port for the NNTP service is 119. However, if a + host wishes to offer separate servers for transit and reading + clients, port 433 SHOULD be used for the transit server and 119 for + the reading server. + +<span class="h4"><h4><a class="selflink" name="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Mode Switching</h4></span> + + An implementation MAY, but SHOULD NOT, provide both transit and + reader facilities on the same server but require the client to select + which it wishes to use. Such an arrangement is called a + "mode-switching" server. + + + + + + + + +<span class="grey">Feather Standards Track [Page 21]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-22" id="page-22" href="#page-22" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + A mode-switching server has two modes: + + o Transit mode, which applies after the initial connection. + + * It MUST advertise the MODE-READER capability. + + * It MUST NOT advertise the READER capability. + + However, the server MAY cease to advertise the MODE-READER + capability after the client uses any command except CAPABILITIES. + + o Reading mode, after a successful MODE READER command (see <a href="#section-5.3">Section</a> + <a href="#section-5.3">5.3</a>). + + * It MUST NOT advertise the MODE-READER capability. + + * It MUST advertise the READER capability. + + * It MAY NOT advertise the IHAVE capability, even if it was + advertising it in transit mode. + + A client SHOULD only issue a MODE READER command to a server if it is + advertising the MODE-READER capability. If the server does not + support CAPABILITIES (and therefore does not conform to this + specification), the client MAY use the following heuristic: + + o If the client wishes to use any "reader" commands, it SHOULD use + the MODE READER command immediately after the initial connection. + + o Otherwise, it SHOULD NOT use the MODE READER command. + + In each case, it should be prepared for some commands to be + unavailable that would have been available if it had made the other + choice. + +<span class="h3"><h3><a class="selflink" name="section-3.5" href="#section-3.5">3.5</a>. Pipelining</h3></span> + + NNTP is designed to operate over a reliable bi-directional + connection, 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 response is received. Doing this is called "pipelining". + However, certain server implementations throw away all text received + from the client following certain commands before sending their + response. If this happens, pipelining will be affected because one + or more commands will have been ignored or misinterpreted, and the + client will be matching the wrong responses to each command. Since + there are significant benefits to pipelining, but also circumstances + where it is reasonable or common for servers to behave in the above + + + +<span class="grey">Feather Standards Track [Page 22]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-23" id="page-23" href="#page-23" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + manner, this document puts certain requirements on both clients and + servers. + + Except where stated otherwise, a client MAY use pipelining. That is, + it may send a command before receiving the response for the previous + command. The server MUST allow pipelining and MUST NOT throw away + any text received after a command. Irrespective of whether + pipelining is used, the server MUST process commands in the order + they are sent. + + If the specific description of a command says it "MUST NOT be + pipelined", that command MUST end any pipeline of commands. That is, + the client MUST NOT send any following command until it receives the + CRLF at the end of the response from the command. The server MAY + ignore any data received after the command and before the CRLF at the + end of the response is sent to the client. + + The initial connection must not be part of a pipeline; that is, the + client MUST NOT send any command until it receives the CRLF at the + end of the greeting. + + If the client uses blocking system calls to send commands, it MUST + ensure that the amount of text sent in pipelining does not cause a + deadlock between transmission and reception. The amount of text + involved will depend on window sizes in the transmission layer; + typically, it is 4k octets for TCP. (Since the server only sends + data in response to commands from the client, the converse problem + does not occur.) + +<span class="h4"><h4><a class="selflink" name="section-3.5.1" href="#section-3.5.1">3.5.1</a>. Examples</h4></span> + + Example of correct use of pipelining: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT + [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT + [S] 211 1234 3000234 3002322 misc.test + [S] 223 3000234 <45223423@example.com> retrieved + [S] 223 3000237 <668929@example.org> retrieved + + Example of incorrect use of pipelining (the MODE READER command may + not be pipelined): + + [<a name="ref-C" id="ref-C">C</a>] MODE READER + [<a href="#ref-C" title='"Demo User"'>C</a>] DATE + [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT + [S] 200 Server ready, posting allowed + [S] 223 3000237 <668929@example.org> retrieved + + + +<span class="grey">Feather Standards Track [Page 23]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-24" id="page-24" href="#page-24" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + The DATE command has been thrown away by the server, so there is no + 111 response to match it. + +<span class="h3"><h3><a class="selflink" name="section-3.6" href="#section-3.6">3.6</a>. Articles</h3></span> + + NNTP is intended to transfer articles between clients and servers. + For the purposes of this specification, articles are required to + conform to the rules in this section, and clients and servers MUST + correctly process any article received from the other that does so. + Note that this requirement applies only to the contents of + communications over NNTP; it does not prevent the client or server + from subsequently rejecting an article for reasons of local policy. + Also see <a href="#appendix-A">Appendix A</a> for further restrictions on the format of + articles in some uses of NNTP. + + 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 + 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 + 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 + 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 + empty. + + 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 + 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 + 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; it MAY be empty. A header may be "folded"; that is, a CRLF + pair may be placed before any TAB or space in the line. There MUST + still be some other octet between any two CRLF pairs in a header + line. (Note that folding means that the header line occupies more + than one line when displayed or transmitted; nevertheless, it is + still referred to as "a" header line.) The presence or absence of + folding does not affect the meaning of the header line; that is, the + CRLF pairs introduced by folding are not considered part of the + header content. Header lines SHOULD NOT be 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 that fails to satisfy this requirement has been + received from elsewhere, clients and servers MAY transfer it to each + other without re-folding it. + + + + + + +<span class="grey">Feather Standards Track [Page 24]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-25" id="page-25" href="#page-25" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + The content of a header SHOULD be in UTF-8. However, if an + implementation receives an article from elsewhere that uses octets in + the range 128 to 255 in some other manner, it MAY pass it to a client + or server without modification. Therefore, implementations MUST be + prepared to receive such headers, and data derived from them (e.g., + in the responses from the OVER command, <a href="#section-8.3">Section 8.3</a>), and MUST NOT + assume that they are always UTF-8. Any external processing of those + headers, including identifying the encoding used, is outside the + scope of this document. + + Each article MUST have a unique message-id; two articles offered by + an NNTP server MUST NOT have the same message-id. For the purposes + of this specification, message-ids are opaque strings that MUST meet + the following requirements: + + o A message-id MUST begin with "<", end with ">", and MUST NOT + 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 NOT contain octets other than printable US-ASCII + characters. + + Two message-ids are the same if and only if they consist of the same + sequence of octets. + + This specification does not describe how the message-id of an article + is determined. If the server does not have any way to determine a + message-id from the article itself, it MUST synthesize one (this + specification does not require that the article be changed as a + result). See also <a href="#appendix-A.2">Appendix A.2</a>. + +<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>. The WILDMAT Format</h2></span> + + The WILDMAT format described here is based on the version first + developed by Rich Salz [<a href="#ref-SALZ1992" title='"Manual Page for wildmat(3) from the INN 1.4 distribution, Revision 1.10"'>SALZ1992</a>], which was in turn derived from the + format used in the UNIX "find" command to articulate file names. It + was developed to provide a uniform mechanism for matching patterns in + the same manner that the UNIX shell matches filenames. + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 25]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-26" id="page-26" href="#page-26" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h3"><h3><a class="selflink" name="section-4.1" href="#section-4.1">4.1</a>. Wildmat Syntax</h3></span> + + A wildmat is described by the following ABNF [<a href="https://tools.ietf.org/html/rfc4234" title='"Augmented BNF for Syntax Specifications: ABNF"'>RFC4234</a>] syntax, which + is an extract of that in <a href="#section-9.8">Section 9.8</a>. + + wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) + wildmat-pattern = 1*wildmat-item + wildmat-item = wildmat-exact / wildmat-wild + wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / + UTF8-non-ascii ; exclude ! * , ? [ \ ] + wildmat-wild = "*" / "?" + + Note: the characters ",", "\", "[", and "]" are not allowed in + wildmats, while * and ? are always wildcards. This should not be a + problem, since these characters cannot occur in newsgroup names, + which is the only current use of wildmats. Backslash is commonly + used to suppress the special meaning of characters, whereas brackets + are used to introduce sets. However, these usages are not universal, + and interpretation of these characters in the context of UTF-8 + strings is potentially complex and differs from existing practice, so + they were omitted from this specification. A future extension to + this specification may provide semantics for these characters. + +<span class="h3"><h3><a class="selflink" name="section-4.2" href="#section-4.2">4.2</a>. Wildmat Semantics</h3></span> + + A wildmat is tested against a string and either matches or does not + match. To do this, each constituent <wildmat-pattern> is matched + against the string, and the rightmost pattern that matches is + identified. If that <wildmat-pattern> is not preceded with "!", the + whole wildmat matches. If it is preceded by "!", or if no <wildmat- + pattern> matches, the whole wildmat does not match. + + For example, consider the wildmat "a*,!*b,*c*": + + o The string "aaa" matches because the rightmost match is with "a*". + + o The string "abb" does not match because the rightmost match is + with "*b". + + o The string "ccb" matches because the rightmost match is with + "*c*". + + o The string "xxx" does not match because no <wildmat-pattern> + matches. + + A <wildmat-pattern> matches a string if the string can be broken into + components, each of which matches the corresponding <wildmat-item> in + the pattern. The matches must be in the same order, and the whole + + + +<span class="grey">Feather Standards Track [Page 26]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-27" id="page-27" href="#page-27" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + string must be used in the match. The pattern is "anchored"; that + is, the first and last characters in the string must match the first + and last item, respectively (unless that item is an asterisk matching + zero characters). + + A <wildmat-exact> matches the same character (which may be more than + one octet in UTF-8). + + "?" matches exactly one character (which may be more than one octet). + + "*" matches zero or more characters. It can match an empty string, + but it cannot match a subsequence of a UTF-8 sequence that is not + aligned to the character boundaries. + +<span class="h3"><h3><a class="selflink" name="section-4.3" href="#section-4.3">4.3</a>. Extensions</h3></span> + + An NNTP server or extension MAY extend the syntax or semantics of + wildmats provided that all wildmats that meet the requirements of + <a href="#section-4.1">Section 4.1</a> have the meaning ascribed to them by <a href="#section-4.2">Section 4.2</a>. Future + editions of this document may also extend wildmats. + +<span class="h3"><h3><a class="selflink" name="section-4.4" href="#section-4.4">4.4</a>. Examples</h3></span> + + In these examples, $ and @ are used to represent the two octets %xC2 + and %xA3, respectively; $@ is thus the UTF-8 encoding for the pound + sterling symbol, shown as # in the descriptions. + + Wildmat Description of strings that match + abc The one string "abc" + abc,def The two strings "abc" and "def" + $@ The one character string "#" + a* Any string that begins with "a" + a*b Any string that begins with "a" and ends with "b" + a*,*b Any string that begins with "a" or ends with "b" + a*,!*b Any string that begins with "a" and does not end with + "b" + a*,!*b,c* Any string that begins with "a" and does not end with + "b", and any string that begins with "c" no matter + what it ends with + a*,c*,!*b Any string that begins with "a" or "c" and does not + end with "b" + ?a* Any string with "a" as its second character + ??a* Any string with "a" as its third character + *a? Any string with "a" as its penultimate character + *a?? Any string with "a" as its antepenultimate character + + + + + + +<span class="grey">Feather Standards Track [Page 27]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-28" id="page-28" href="#page-28" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>. Session Administration Commands</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-5.1" href="#section-5.1">5.1</a>. Initial Connection</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Usage</h4></span> + + This command MUST NOT be pipelined. + + Responses [<a href="#ref-1">1</a>] + 200 Service available, posting allowed + 201 Service available, posting prohibited + 400 Service temporarily unavailable [<a href="#ref-2">2</a>] + 502 Service permanently unavailable [<a href="#ref-2">2</a>] + + [<a name="ref-1" id="ref-1">1</a>] These are the only valid response codes for the initial greeting; + the server MUST not return any other generic response code. + + [<a name="ref-2" id="ref-2">2</a>] Following a 400 or 502 response, the server MUST immediately + close the connection. + +<span class="h4"><h4><a class="selflink" name="section-5.1.2" href="#section-5.1.2">5.1.2</a>. Description</h4></span> + + There is no command presented by the client upon initial connection + to the server. The server MUST present an appropriate response code + as a greeting to the client. This response informs the client + whether service is available and whether the client is permitted to + post. + + If the server will accept further commands from the client including + POST, the server MUST present a 200 greeting code. If the server + will accept further commands from the client, but the client is not + authorized to post articles using the POST command, the server MUST + present a 201 greeting code. + + Otherwise, the server MUST present a 400 or 502 greeting code and + then immediately close the connection. 400 SHOULD be used if the + issue is only temporary (for example, because of load) and the client + can expect to be able to connect successfully at some point in the + future without making any changes. 502 MUST be used if the client is + not permitted under any circumstances to interact with the server, + and MAY be used if the server has insufficient information to + determine whether the issue is temporary or permanent. + + Note: the distinction between the 200 and 201 response codes has + turned out in practice to be insufficient; for example, some servers + do not allow posting until the client has authenticated, while other + clients assume that a 201 response means that posting will never be + possible even after authentication. Therefore, clients SHOULD use + + + +<span class="grey">Feather Standards Track [Page 28]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-29" id="page-29" href="#page-29" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + the CAPABILITIES command (<a href="#section-5.2">Section 5.2</a>) rather than rely on this + response. + +<span class="h4"><h4><a class="selflink" name="section-5.1.3" href="#section-5.1.3">5.1.3</a>. Examples</h4></span> + + Example of a normal connection from an authorized client that then + terminates the session (see <a href="#section-5.4">Section 5.4</a>): + + [Initial connection set-up completed.] + [S] 200 NNTP Service Ready, posting permitted + [<a href="#ref-C" title='"Demo User"'>C</a>] QUIT + [S] 205 NNTP Service exits normally + [Server closes connection.] + + Example of a normal connection from an authorized client that is not + permitted to post, which also immediately terminates the session: + + [Initial connection set-up completed.] + [S] 201 NNTP Service Ready, posting prohibited + [<a href="#ref-C" title='"Demo User"'>C</a>] QUIT + [S] 205 NNTP Service exits normally + [Server closes connection.] + + Example of a normal connection from an unauthorized client: + + [Initial connection set-up completed.] + [S] 502 NNTP Service permanently unavailable + [Server closes connection.] + + Example of a connection from a client if the server is unable to + provide service: + + [Initial connection set-up completed.] + [S] 400 NNTP Service temporarily unavailable + [Server closes connection.] + +<span class="h3"><h3><a class="selflink" name="section-5.2" href="#section-5.2">5.2</a>. CAPABILITIES</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Usage</h4></span> + + This command is mandatory. + + Syntax + CAPABILITIES [keyword] + + Responses + 101 Capability list follows (multi-line) + + + + +<span class="grey">Feather Standards Track [Page 29]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-30" id="page-30" href="#page-30" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Parameters + keyword additional feature, see description + +<span class="h4"><h4><a class="selflink" name="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Description</h4></span> + + The CAPABILITIES command allows a client to determine the + capabilities of the server at any given time. + + This command MAY be issued at any time; the server MUST NOT require + it to be issued in order to make use of any capability. The response + generated by this command MAY change during a session because of + other state information (which, in turn, may be changed by the + effects of other commands or by external events). An NNTP client is + only able to get the current and correct information concerning + available capabilities at any point during a session by issuing a + CAPABILITIES command at that point of that session and processing the + response. + + The capability list is returned as a multi-line data block following + the 101 response code. Each capability is described by a separate + capability line. The server MUST NOT list the same capability twice + in the response, even with different arguments. Except that the + VERSION capability MUST be the first line, the order in which the + capability lines appears is not significant; the server need not even + consistently return the same order. + + While some capabilities are likely to be always available or never + available, others (notably extensions) will appear and disappear + depending on server state changes within the session or on external + events between sessions. An NNTP client MAY cache the results of + this command, but MUST NOT rely on the correctness of any cached + results, whether from earlier in this session or from a previous + session, MUST cope gracefully with the cached status being out of + date, and SHOULD (if caching results) provide a way to force the + cached information to be refreshed. Furthermore, a client MUST NOT + use cached results in relation to security, privacy, and + authentication extensions. See <a href="#section-12.6">Section 12.6</a> for further discussion + of this topic. + + The keyword argument is not used by this specification. It is + provided so that extensions or revisions to this specification can + include extra features for this command without requiring the + CAPABILITIES command to be used twice (once to determine if the extra + features are available, and a second time to make use of them). If + the server does not recognise the argument (and it is a keyword), it + MUST respond with the 101 response code as if the argument had been + omitted. If an argument is provided that the server does recognise, + it MAY use the 101 response code or MAY use some other response code + + + +<span class="grey">Feather Standards Track [Page 30]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-31" id="page-31" href="#page-31" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + (which will be defined in the specification of that feature). If the + argument is not a keyword, the 501 generic response code MUST be + returned. The server MUST NOT generate any other response code to + the CAPABILITIES command. + +<span class="h4"><h4><a class="selflink" name="section-5.2.3" href="#section-5.2.3">5.2.3</a>. Examples</h4></span> + + Example of a minimal response (a read-only server): + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] LIST ACTIVE NEWSGROUPS + [S] . + + Example of a response from a server that has a range of facilities + and that also describes itself: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] IHAVE + [S] POST + [S] NEWNEWS + [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES OVERVIEW.FMT + [S] IMPLEMENTATION INN 4.2 2004-12-25 + [S] OVER MSGID + [S] STREAMING + [S] XSECRET + [S] . + + Example of a server that supports more than one version of NNTP: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 3 + [S] READER + [S] LIST ACTIVE NEWSGROUPS + [S] . + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 31]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-32" id="page-32" href="#page-32" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of a client attempting to use a feature of the CAPABILITIES + command that the server does not support: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES AUTOUPDATE + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] IHAVE + [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS + [S] OVER MSGID + [S] HDR + [S] NEWNEWS + [S] . + +<span class="h3"><h3><a class="selflink" name="section-5.3" href="#section-5.3">5.3</a>. MODE READER</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-5.3.1" href="#section-5.3.1">5.3.1</a>. Usage</h4></span> + + Indicating capability: MODE-READER + + This command MUST NOT be pipelined. + + Syntax + MODE READER + + Responses + 200 Posting allowed + 201 Posting prohibited + 502 Reading service permanently unavailable [<a href="#ref-1">1</a>] + + [<a name="ref-1" id="ref-1">1</a>] Following a 502 response the server MUST immediately close the + connection. + +<span class="h4"><h4><a class="selflink" name="section-5.3.2" href="#section-5.3.2">5.3.2</a>. Description</h4></span> + + The MODE READER command instructs a mode-switching server to switch + modes, as described in <a href="#section-3.4.2">Section 3.4.2</a>. + + If the server is mode-switching, it switches from its transit mode to + its reader mode, indicating this by changing the capability list + accordingly. It MUST then return a 200 or 201 response with the same + meaning as for the initial greeting (as described in <a href="#section-5.1.1">Section 5.1.1</a>). + Note that the response need not be the same as that presented during + the initial greeting. The client MUST NOT issue MODE READER more + than once in a session or after any security or privacy commands are + issued. When the MODE READER command is issued, the server MAY reset + its state to that immediately after the initial connection before + switching mode. + + + +<span class="grey">Feather Standards Track [Page 32]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-33" id="page-33" href="#page-33" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + If the server is not mode-switching, then the following apply: + + o If it advertises the READER capability, it MUST return a 200 or + 201 response with the same meaning as for the initial greeting; in + this case, the command MUST NOT affect the server state in any + way. + + o If it does not advertise the READER capability, it MUST return a + 502 response and then immediately close the connection. + +<span class="h4"><h4><a class="selflink" name="section-5.3.3" href="#section-5.3.3">5.3.3</a>. Examples</h4></span> + + Example of use of the MODE READER command on a transit-only server + (which therefore does not providing reading facilities): + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] IHAVE + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] MODE READER + [S] 502 Transit service only + [Server closes connection.] + + Example of use of the MODE READER command on a server that provides + reading facilities: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] LIST ACTIVE NEWSGROUPS + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] MODE READER + [S] 200 Reader mode, posting permitted + [<a href="#ref-C" title='"Demo User"'>C</a>] IHAVE <i.am.an.article.you.have@example.com> + [S] 500 Permission denied + [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + + Note that in both of these situations, the client SHOULD NOT use MODE + READER. + + + + + + + + + +<span class="grey">Feather Standards Track [Page 33]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-34" id="page-34" href="#page-34" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of use of the MODE READER command on a mode-switching server: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] IHAVE + [S] MODE-READER + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] MODE READER + [S] 200 Reader mode, posting permitted + [<a href="#ref-C" title='"Demo User"'>C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] NEWNEWS + [S] LIST ACTIVE NEWSGROUPS + [S] STARTTLS + [S] . + + In this case, the server offers (but does not require) TLS privacy in + its reading mode but not in its transit mode. + + Example of use of the MODE READER command where the client is not + permitted to post: + + [<a name="ref-C" id="ref-C">C</a>] MODE READER + [S] 201 NNTP Service Ready, posting prohibited + +<span class="h3"><h3><a class="selflink" name="section-5.4" href="#section-5.4">5.4</a>. QUIT</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-5.4.1" href="#section-5.4.1">5.4.1</a>. Usage</h4></span> + + This command is mandatory. + + Syntax + QUIT + + Responses + 205 Connection closing + +<span class="h4"><h4><a class="selflink" name="section-5.4.2" href="#section-5.4.2">5.4.2</a>. Description</h4></span> + + The client uses the QUIT command to terminate the session. The + server MUST acknowledge the QUIT command and then close the + connection to the client. This is the preferred method for a client + to indicate that it has finished all of its transactions with the + NNTP server. + + + + +<span class="grey">Feather Standards Track [Page 34]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-35" id="page-35" href="#page-35" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + If a client simply disconnects (or if the connection times out or + some other fault occurs), the server MUST gracefully cease its + attempts to service the client, disconnecting from its end if + necessary. + + The server MUST NOT generate any response code to the QUIT command + other than 205 or, if any arguments are provided, 501. + +<span class="h4"><h4><a class="selflink" name="section-5.4.3" href="#section-5.4.3">5.4.3</a>. Examples</h4></span> + + [<a name="ref-C" id="ref-C">C</a>] QUIT + [S] 205 closing connection + [Server closes connection.] + +<span class="h2"><h2><a class="selflink" name="section-6" href="#section-6">6</a>. Article Posting and Retrieval</h2></span> + + News-reading clients have available a variety of mechanisms to + retrieve articles via NNTP. The news articles are stored and indexed + using three types of keys. The first type of key is the message-id + of an article and is globally unique. The second type of key is + composed of a newsgroup name and an article number within that + newsgroup. On a particular server, there MUST only be one article + with a given number within any newsgroup, and an article MUST NOT + have two different numbers in the same newsgroup. An article can be + cross-posted to multiple newsgroups, so there may be multiple keys + that point to the same article on the same server; these MAY have + different numbers in each newsgroup. However, this type of key is + not required to be globally unique, so the same key MAY refer to + different articles on different servers. (Note that the terms + "group" and "newsgroup" are equivalent.) + + The final type of key is the arrival timestamp, giving the time that + the article arrived at the server. The server MUST ensure that + article numbers are issued in order of arrival timestamp; that is, + articles arriving later MUST have higher numbers than those that + arrive earlier. The server SHOULD allocate the next sequential + unused number to each new article. + + Article numbers MUST lie between 1 and 2,147,483,647, inclusive. The + client and server MAY use leading zeroes in specifying article + numbers but MUST NOT use more than 16 digits. In some situations, + the value zero replaces an article number to show some special + situation. + + Note that it is likely that the article number limit of 2,147,483,647 + will be increased by a future revision or extension to this + specification. While servers MUST NOT send article numbers greater + than this current limit, client and server developers are advised to + + + +<span class="grey">Feather Standards Track [Page 35]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-36" id="page-36" href="#page-36" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + use internal structures and datatypes capable of handling larger + values in anticipation of such a change. + +<span class="h3"><h3><a class="selflink" name="section-6.1" href="#section-6.1">6.1</a>. Group and Article Selection</h3></span> + + The following commands are used to set the "currently selected + newsgroup" and the "current article number", which are used by + various commands. At the start of an NNTP session, both of these + values are set to the special value "invalid". + +<span class="h4"><h4><a class="selflink" name="section-6.1.1" href="#section-6.1.1">6.1.1</a>. GROUP</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.1.1.1" href="#section-6.1.1.1">6.1.1.1</a>. Usage</h5></span> + + Indicating capability: READER + + Syntax + GROUP group + + Responses + 211 number low high group Group successfully selected + 411 No such newsgroup + + Parameters + group Name of newsgroup + number Estimated number of articles in the group + low Reported low water mark + high Reported high water mark + +<span class="h5"><h5><a class="selflink" name="section-6.1.1.2" href="#section-6.1.1.2">6.1.1.2</a>. Description</h5></span> + + The GROUP command selects a newsgroup as the currently selected + newsgroup and returns summary information about it. + + The required argument is the name of the newsgroup to be selected + (e.g., "news.software.nntp"). A list of valid newsgroups may be + obtained by using the LIST ACTIVE command (see <a href="#section-7.6.3">Section 7.6.3</a>). + + The successful selection response will return the article numbers of + 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 + the "reported high water mark") and an estimate of the number of + articles in the group currently available. + + 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 + than the difference between the reported low and high water marks. + (Some implementations will actually count the number of articles + + + +<span class="grey">Feather Standards Track [Page 36]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-37" id="page-37" href="#page-37" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + currently stored. Others will just subtract the low water mark from + the high water mark and add one to get an estimate.) + + If the group is empty, one of the following three situations will + occur. Clients MUST accept all three cases; servers MUST NOT + represent an empty group in any other way. + + 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 + method to show an empty group. This is the only time that the + high water mark can be less than the low water mark. + + o All three numbers will be zero. + + o The high water mark is greater than or equal to the low water + mark. The estimated article count might be zero or non-zero; if + it is non-zero, the same requirements apply as for a non-empty + group. + + The set of articles in a group may change after the GROUP command is + carried out: + + o Articles may be removed from the group. + + o Articles may be reinstated in the group with the same article + number, but those articles MUST have numbers no less than the + reported low water mark (note that this is a reinstatement of the + previous article, not a new article reusing the number). + + o New articles may be added with article numbers greater than the + reported high water mark. (If an article that was the one with + the highest number has been removed and the high water mark has + been adjusted accordingly, the next new article will not have the + number one greater than the reported high water mark.) + + Except when the group is empty and all three numbers are zero, + whenever a subsequent GROUP command for the same newsgroup is issued, + either by the same client or a different client, the reported low + water mark in the response MUST be no less than that in any previous + response for that newsgroup in this session, and it SHOULD be no less + than that in any previous response for that newsgroup ever sent to + any client. Any failure to meet the latter condition SHOULD be + transient only. The client may make use of the low water mark to + remove all remembered information about articles with lower numbers, + as these will never recur. This includes the situation when the high + water mark is one less than the low water mark. No similar + assumption can be made about the high water mark, as this can + + + + +<span class="grey">Feather Standards Track [Page 37]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-38" id="page-38" href="#page-38" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + decrease if an article is removed and then increase again if it is + reinstated or if new articles arrive. + + When a valid group is selected by means of this command, the + currently selected newsgroup MUST be set to that group, and the + current article number MUST be set to the first article in the group + (this applies even if the group is already the currently selected + newsgroup). If an empty newsgroup is selected, the current article + number is made invalid. If an invalid group is specified, the + currently selected newsgroup and current article number MUST NOT be + changed. + + The GROUP or LISTGROUP command (see <a href="#section-6.1.2">Section 6.1.2</a>) MUST be used by a + client, and a successful response received, before any other command + is used that depends on the value of the currently selected newsgroup + or current article number. + + If the group specified is not available on the server, a 411 response + MUST be returned. + +<span class="h5"><h5><a class="selflink" name="section-6.1.1.3" href="#section-6.1.1.3">6.1.1.3</a>. Examples</h5></span> + + Example for a group known to the server: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + + Example for a group unknown to the server: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.is.sob.bradner.or.barber + [S] 411 example.is.sob.bradner.or.barber is unknown + + Example of an empty group using the preferred response: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.currently.empty.newsgroup + [S] 211 0 4000 3999 example.currently.empty.newsgroup + + Example of an empty group using an alternative response: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.currently.empty.newsgroup + [S] 211 0 0 0 example.currently.empty.newsgroup + + Example of an empty group using a different alternative response: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.currently.empty.newsgroup + [S] 211 0 4000 4321 example.currently.empty.newsgroup + + + + + +<span class="grey">Feather Standards Track [Page 38]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-39" id="page-39" href="#page-39" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example reselecting the currently selected newsgroup: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 234 567 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT 444 + [S] 223 444 <123456@example.net> retrieved + [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP misc.test + [S] 211 1234 234 567 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT + [S] 223 234 <different@example.net> retrieved + +<span class="h4"><h4><a class="selflink" name="section-6.1.2" href="#section-6.1.2">6.1.2</a>. LISTGROUP</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.1.2.1" href="#section-6.1.2.1">6.1.2.1</a>. Usage</h5></span> + + Indicating capability: READER + + Syntax + LISTGROUP [group [range]] + + Responses + 211 number low high group Article numbers follow (multi-line) + 411 No such newsgroup + 412 No newsgroup selected [<a href="#ref-1">1</a>] + + Parameters + group Name of newsgroup + range Range of articles to report + number Estimated number of articles in the group + low Reported low water mark + high Reported high water mark + + [<a name="ref-1" id="ref-1">1</a>] The 412 response can only occur if no group has been specified. + +<span class="h5"><h5><a class="selflink" name="section-6.1.2.2" href="#section-6.1.2.2">6.1.2.2</a>. Description</h5></span> + + The LISTGROUP command selects a newsgroup in the same manner as the + GROUP command (see <a href="#section-6.1.1">Section 6.1.1</a>) but also provides a list of article + numbers in the newsgroup. If no group is specified, the currently + selected newsgroup is used. + + On success, a list of article numbers is returned as a multi-line + data block following the 211 response code (the arguments on the + initial response line are the same as for the GROUP command). The + list contains one number per line and is in numerical order. It + lists precisely those articles that exist in the group at the moment + of selection (therefore, an empty group produces an empty list). If + the optional range argument is specified, only articles within the + + + +<span class="grey">Feather Standards Track [Page 39]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-40" id="page-40" href="#page-40" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + range are included in the list (therefore, the list MAY be empty even + if the group is not). + + The range argument may be any of the following: + + o An article number. + + o An article number followed by a dash to indicate all following. + + o An article number followed by a dash followed by another article + number. + + In the last case, if the second number is less than the first number, + then the range contains no articles. Omitting the range is + equivalent to the range 1- being specified. + + If the group specified is not available on the server, a 411 response + MUST be returned. If no group is specified and the currently + selected newsgroup is invalid, a 412 response MUST be returned. + + Except that the group argument is optional, that a range argument can + be specified, and that a multi-line data block follows the 211 + response code, the LISTGROUP command is identical to the GROUP + command. In particular, when successful, the command sets the + current article number to the first article in the group, if any, + even if this is not within the range specified by the second + argument. + + Note that the range argument is a new feature in this specification + and servers that do not support CAPABILITIES (and therefore do not + conform to this specification) are unlikely to support it. + +<span class="h5"><h5><a class="selflink" name="section-6.1.2.3" href="#section-6.1.2.3">6.1.2.3</a>. Examples</h5></span> + + Example of LISTGROUP being used to select a group: + + [<a name="ref-C" id="ref-C">C</a>] LISTGROUP misc.test + [S] 211 2000 3000234 3002322 misc.test list follows + [S] 3000234 + [S] 3000237 + [S] 3000238 + [S] 3000239 + [S] 3002322 + [S] . + + + + + + + +<span class="grey">Feather Standards Track [Page 40]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-41" id="page-41" href="#page-41" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of LISTGROUP on an empty group: + + [<a name="ref-C" id="ref-C">C</a>] LISTGROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup list follows + [S] . + + Example of LISTGROUP on a valid, currently selected newsgroup: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 2000 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] LISTGROUP + [S] 211 2000 3000234 3002322 misc.test list follows + [S] 3000234 + [S] 3000237 + [S] 3000238 + [S] 3000239 + [S] 3002322 + [S] . + + Example of LISTGROUP with a range: + + [<a name="ref-C" id="ref-C">C</a>] LISTGROUP misc.test 3000238-3000248 + [S] 211 2000 3000234 3002322 misc.test list follows + [S] 3000238 + [S] 3000239 + [S] . + + Example of LISTGROUP with an empty range: + + [<a name="ref-C" id="ref-C">C</a>] LISTGROUP misc.test 12345678- + [S] 211 2000 3000234 3002322 misc.test list follows + [S] . + + Example of LISTGROUP with an invalid range: + + [<a name="ref-C" id="ref-C">C</a>] LISTGROUP misc.test 9999-111 + [S] 211 2000 3000234 3002322 misc.test list follows + [S] . + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 41]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-42" id="page-42" href="#page-42" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-6.1.3" href="#section-6.1.3">6.1.3</a>. LAST</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.1.3.1" href="#section-6.1.3.1">6.1.3.1</a>. Usage</h5></span> + + Indicating capability: READER + + Syntax + LAST + + Responses + 223 n message-id Article found + 412 No newsgroup selected + 420 Current article number is invalid + 422 No previous article in this group + + Parameters + n Article number + message-id Article message-id + +<span class="h5"><h5><a class="selflink" name="section-6.1.3.2" href="#section-6.1.3.2">6.1.3.2</a>. Description</h5></span> + + If the currently selected newsgroup is valid, the current article + number MUST be set to the previous article in that newsgroup (that + is, the highest existing article number less than the current article + number). If successful, a response indicating the new current + article number and the message-id of that article MUST be returned. + No article text is sent in response to this command. + + There MAY be no previous article in the group, although the current + article number is not the reported low water mark. There MUST NOT be + a previous article when the current article number is the reported + low water mark. + + Because articles can be removed and added, the results of multiple + LAST and NEXT commands MAY not be consistent over the life of a + particular NNTP session. + + If the current article number is already the first article of the + newsgroup, a 422 response MUST be returned. If the current article + number is invalid, a 420 response MUST be returned. If the currently + selected newsgroup is invalid, a 412 response MUST be returned. In + all three cases, the currently selected newsgroup and current article + number MUST NOT be altered. + + + + + + + + +<span class="grey">Feather Standards Track [Page 42]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-43" id="page-43" href="#page-43" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h5"><h5><a class="selflink" name="section-6.1.3.3" href="#section-6.1.3.3">6.1.3.3</a>. Examples</h5></span> + + Example of a successful article retrieval using LAST: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT + [S] 223 3000237 <668929@example.org> retrieved + [<a href="#ref-C" title='"Demo User"'>C</a>] LAST + [S] 223 3000234 <45223423@example.com> retrieved + + Example of an attempt to retrieve an article without having selected + a group (via the GROUP command) first: + + [Assumes currently selected newsgroup is invalid.] + [<a href="#ref-C" title='"Demo User"'>C</a>] LAST + [S] 412 no newsgroup selected + + Example of an attempt to retrieve an article using the LAST command + when the current article number is that of the first article in the + group: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] LAST + [S] 422 No previous article to retrieve + + Example of an attempt to retrieve an article using the LAST command + when the currently selected newsgroup is empty: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] LAST + [S] 420 No current article selected + + + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 43]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-44" id="page-44" href="#page-44" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-6.1.4" href="#section-6.1.4">6.1.4</a>. NEXT</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.1.4.1" href="#section-6.1.4.1">6.1.4.1</a>. Usage</h5></span> + + Indicating capability: READER + + Syntax + NEXT + + Responses + 223 n message-id Article found + 412 No newsgroup selected + 420 Current article number is invalid + 421 No next article in this group + + Parameters + n Article number + message-id Article message-id + +<span class="h5"><h5><a class="selflink" name="section-6.1.4.2" href="#section-6.1.4.2">6.1.4.2</a>. Description</h5></span> + + If the currently selected newsgroup is valid, the current article + number MUST be set to the next article in that newsgroup (that is, + the lowest existing article number greater than the current article + number). If successful, a response indicating the new current + article number and the message-id of that article MUST be returned. + No article text is sent in response to this command. + + If the current article number is already the last article of the + newsgroup, a 421 response MUST be returned. In all other aspects + (apart, of course, from the lack of 422 response), this command is + identical to the LAST command (<a href="#section-6.1.3">Section 6.1.3</a>). + +<span class="h5"><h5><a class="selflink" name="section-6.1.4.3" href="#section-6.1.4.3">6.1.4.3</a>. Examples</h5></span> + + Example of a successful article retrieval using NEXT: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT + [S] 223 3000237 <668929@example.org> retrieved + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 44]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-45" id="page-45" href="#page-45" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of an attempt to retrieve an article without having selected + a group (via the GROUP command) first: + + [Assumes currently selected newsgroup is invalid.] + [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT + [S] 412 no newsgroup selected + + Example of an attempt to retrieve an article using the NEXT command + when the current article number is that of the last article in the + group: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT 3002322 + [S] 223 3002322 <411@example.net> retrieved + [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT + [S] 421 No next article to retrieve + + Example of an attempt to retrieve an article using the NEXT command + when the currently selected newsgroup is empty: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] NEXT + [S] 420 No current article selected + +<span class="h3"><h3><a class="selflink" name="section-6.2" href="#section-6.2">6.2</a>. Retrieval of Articles and Article Sections</h3></span> + + The ARTICLE, BODY, HEAD, and STAT commands are very similar. They + differ only in the parts of the article that are presented to the + client and in the successful response code. The ARTICLE command is + described here in full, while the other three commands are described + in terms of the differences. As specified in <a href="#section-3.6">Section 3.6</a>, an article + consists of two parts: the article headers and the article body. + + When responding to one of these commands, the server MUST present the + entire article or appropriate part and MUST NOT attempt to alter or + translate it in any way. + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 45]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-46" id="page-46" href="#page-46" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-6.2.1" href="#section-6.2.1">6.2.1</a>. ARTICLE</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.2.1.1" href="#section-6.2.1.1">6.2.1.1</a>. Usage</h5></span> + + Indicating capability: READER + + Syntax + ARTICLE message-id + ARTICLE number + ARTICLE + + Responses + + First form (message-id specified) + 220 0|n message-id Article follows (multi-line) + 430 No article with that message-id + + Second form (article number specified) + 220 n message-id Article follows (multi-line) + 412 No newsgroup selected + 423 No article with that number + + Third form (current article number used) + 220 n message-id Article follows (multi-line) + 412 No newsgroup selected + 420 Current article number is invalid + + Parameters + number Requested article number + n Returned article number + message-id Article message-id + +<span class="h5"><h5><a class="selflink" name="section-6.2.1.2" href="#section-6.2.1.2">6.2.1.2</a>. Description</h5></span> + + The ARTICLE command selects an article according to the arguments and + presents the entire article (that is, the headers, an empty line, and + the body, in that order) to the client. The command has three forms. + + In the first form, a message-id is specified, and the server presents + the article with that message-id. In this case, the server MUST NOT + alter the currently selected newsgroup or current article number. + This is both to facilitate the presentation of articles that may be + referenced within another article being read, and because of the + semantic difficulties of determining the proper sequence and + membership of an article that may have been cross-posted to more than + one newsgroup. + + + + + +<span class="grey">Feather Standards Track [Page 46]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-47" id="page-47" href="#page-47" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + In the response, the article number MUST be replaced with zero, + unless there is a currently selected newsgroup and the article is + present in that group, in which case the server MAY use the article's + number in that group. (The server is not required to determine + whether the article is in the currently selected newsgroup or, if so, + what article number it has; the client MUST always be prepared for + zero to be specified.) The server MUST NOT provide an article number + unless use of that number in a second ARTICLE command immediately + following this one would return the same article. Even if the server + chooses to return article numbers in these circumstances, it need not + do so consistently; it MAY return zero to any such command (also see + the STAT examples, <a href="#section-6.2.4.3">Section 6.2.4.3</a>). + + In the second form, an article number is specified. If there is an + article with that number in the currently selected newsgroup, the + server MUST set the current article number to that number. + + In the third form, the article indicated by the current article + number in the currently selected newsgroup is used. + + Note that a previously valid article number MAY become invalid if the + article has been removed. A previously invalid article number MAY + become valid if the article has been reinstated, but this article + number MUST be no less than the reported low water mark for that + group. + + The server MUST NOT change the currently selected newsgroup as a + result of this command. The server MUST NOT change the current + article number except when an article number argument was provided + and the article exists; in particular, it MUST NOT change it + following an unsuccessful response. + + 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 + more than once, or to more than one newsgroup. + + The article is returned as a multi-line data block following the 220 + response code. + + If the argument is a message-id and no such article exists, a 430 + response MUST be returned. If the argument is a number or is omitted + and the currently selected newsgroup is invalid, a 412 response MUST + be returned. If the argument is a number and that article does not + exist in the currently selected newsgroup, a 423 response MUST be + returned. If the argument is omitted and the current article number + is invalid, a 420 response MUST be returned. + + + + + +<span class="grey">Feather Standards Track [Page 47]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-48" id="page-48" href="#page-48" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h5"><h5><a class="selflink" name="section-6.2.1.3" href="#section-6.2.1.3">6.2.1.3</a>. Examples</h5></span> + + Example of a successful retrieval of an article (explicitly not using + an article number): + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] ARTICLE + [S] 220 3000234 <45223423@example.com> + [S] Path: pathost!demo!whitehouse!not-for-mail + [S] From: "Demo User" <nobody@example.net> + [S] Newsgroups: misc.test + [S] Subject: I am just a test article + [S] Date: 6 Oct 1998 04:38:40 -0500 + [S] Organization: An Example Net, Uncertain, Texas + [S] Message-ID: <45223423@example.com> + [S] + [S] This is just a test article. + [S] . + + Example of a successful retrieval of an article by message-id: + + [<a name="ref-C" id="ref-C">C</a>] ARTICLE <45223423@example.com> + [S] 220 0 <45223423@example.com> + [S] Path: pathost!demo!whitehouse!not-for-mail + [S] From: "Demo User" <nobody@example.net> + [S] Newsgroups: misc.test + [S] Subject: I am just a test article + [S] Date: 6 Oct 1998 04:38:40 -0500 + [S] Organization: An Example Net, Uncertain, Texas + [S] Message-ID: <45223423@example.com> + [S] + [S] This is just a test article. + [S] . + + Example of an unsuccessful retrieval of an article by message-id: + + [<a name="ref-C" id="ref-C">C</a>] ARTICLE <i.am.not.there@example.com> + [S] 430 No Such Article Found + + Example of an unsuccessful retrieval of an article by number: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 news.groups + [<a href="#ref-C" title='"Demo User"'>C</a>] ARTICLE 300256 + [S] 423 No article with that number + + + + + +<span class="grey">Feather Standards Track [Page 48]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-49" id="page-49" href="#page-49" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of an unsuccessful retrieval of an article by number because + no newsgroup was selected first: + + [Assumes currently selected newsgroup is invalid.] + [<a href="#ref-C" title='"Demo User"'>C</a>] ARTICLE 300256 + [S] 412 No newsgroup selected + + Example of an attempt to retrieve an article when the currently + selected newsgroup is empty: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] ARTICLE + [S] 420 No current article selected + +<span class="h4"><h4><a class="selflink" name="section-6.2.2" href="#section-6.2.2">6.2.2</a>. HEAD</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.2.2.1" href="#section-6.2.2.1">6.2.2.1</a>. Usage</h5></span> + + This command is mandatory. + + Syntax + HEAD message-id + HEAD number + HEAD + + Responses + + First form (message-id specified) + 221 0|n message-id Headers follow (multi-line) + 430 No article with that message-id + + Second form (article number specified) + 221 n message-id Headers follow (multi-line) + 412 No newsgroup selected + 423 No article with that number + + Third form (current article number used) + 221 n message-id Headers follow (multi-line) + 412 No newsgroup selected + 420 Current article number is invalid + + Parameters + number Requested article number + n Returned article number + message-id Article message-id + + + + + +<span class="grey">Feather Standards Track [Page 49]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-50" id="page-50" href="#page-50" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h5"><h5><a class="selflink" name="section-6.2.2.2" href="#section-6.2.2.2">6.2.2.2</a>. Description</h5></span> + + The HEAD command behaves identically to the ARTICLE command except + that, if the article exists, the response code is 221 instead of 220 + and only the headers are presented (the empty line separating the + headers and body MUST NOT be included). + +<span class="h5"><h5><a class="selflink" name="section-6.2.2.3" href="#section-6.2.2.3">6.2.2.3</a>. Examples</h5></span> + + Example of a successful retrieval of the headers of an article + (explicitly not using an article number): + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] HEAD + [S] 221 3000234 <45223423@example.com> + [S] Path: pathost!demo!whitehouse!not-for-mail + [S] From: "Demo User" <nobody@example.net> + [S] Newsgroups: misc.test + [S] Subject: I am just a test article + [S] Date: 6 Oct 1998 04:38:40 -0500 + [S] Organization: An Example Net, Uncertain, Texas + [S] Message-ID: <45223423@example.com> + [S] . + + Example of a successful retrieval of the headers of an article by + message-id: + + [<a name="ref-C" id="ref-C">C</a>] HEAD <45223423@example.com> + [S] 221 0 <45223423@example.com> + [S] Path: pathost!demo!whitehouse!not-for-mail + [S] From: "Demo User" <nobody@example.net> + [S] Newsgroups: misc.test + [S] Subject: I am just a test article + [S] Date: 6 Oct 1998 04:38:40 -0500 + [S] Organization: An Example Net, Uncertain, Texas + [S] Message-ID: <45223423@example.com> + [S] . + + Example of an unsuccessful retrieval of the headers of an article by + message-id: + + [<a name="ref-C" id="ref-C">C</a>] HEAD <i.am.not.there@example.com> + [S] 430 No Such Article Found + + + + + + + +<span class="grey">Feather Standards Track [Page 50]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-51" id="page-51" href="#page-51" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of an unsuccessful retrieval of the headers of an article by + number: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] HEAD 300256 + [S] 423 No article with that number + + Example of an unsuccessful retrieval of the headers of an article by + number because no newsgroup was selected first: + + [Assumes currently selected newsgroup is invalid.] + [<a href="#ref-C" title='"Demo User"'>C</a>] HEAD 300256 + [S] 412 No newsgroup selected + + Example of an attempt to retrieve the headers of an article when the + currently selected newsgroup is empty: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] HEAD + [S] 420 No current article selected + +<span class="h4"><h4><a class="selflink" name="section-6.2.3" href="#section-6.2.3">6.2.3</a>. BODY</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.2.3.1" href="#section-6.2.3.1">6.2.3.1</a>. Usage</h5></span> + + Indicating capability: READER + + Syntax + BODY message-id + BODY number + BODY + + Responses + + First form (message-id specified) + 222 0|n message-id Body follows (multi-line) + 430 No article with that message-id + + Second form (article number specified) + 222 n message-id Body follows (multi-line) + 412 No newsgroup selected + 423 No article with that number + + + + + + + +<span class="grey">Feather Standards Track [Page 51]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-52" id="page-52" href="#page-52" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Third form (current article number used) + 222 n message-id Body follows (multi-line) + 412 No newsgroup selected + 420 Current article number is invalid + + Parameters + number Requested article number + n Returned article number + message-id Article message-id + +<span class="h5"><h5><a class="selflink" name="section-6.2.3.2" href="#section-6.2.3.2">6.2.3.2</a>. Description</h5></span> + + The BODY command behaves identically to the ARTICLE command except + that, if the article exists, the response code is 222 instead of 220 + and only the body is presented (the empty line separating the headers + and body MUST NOT be included). + +<span class="h5"><h5><a class="selflink" name="section-6.2.3.3" href="#section-6.2.3.3">6.2.3.3</a>. Examples</h5></span> + + Example of a successful retrieval of the body of an article + (explicitly not using an article number): + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] BODY + [S] 222 3000234 <45223423@example.com> + [S] This is just a test article. + [S] . + + Example of a successful retrieval of the body of an article by + message-id: + + [<a name="ref-C" id="ref-C">C</a>] BODY <45223423@example.com> + [S] 222 0 <45223423@example.com> + [S] This is just a test article. + [S] . + + Example of an unsuccessful retrieval of the body of an article by + message-id: + + [<a name="ref-C" id="ref-C">C</a>] BODY <i.am.not.there@example.com> + [S] 430 No Such Article Found + + + + + + + + + +<span class="grey">Feather Standards Track [Page 52]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-53" id="page-53" href="#page-53" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of an unsuccessful retrieval of the body of an article by + number: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] BODY 300256 + [S] 423 No article with that number + + Example of an unsuccessful retrieval of the body of an article by + number because no newsgroup was selected first: + + [Assumes currently selected newsgroup is invalid.] + [<a href="#ref-C" title='"Demo User"'>C</a>] BODY 300256 + [S] 412 No newsgroup selected + + Example of an attempt to retrieve the body of an article when the + currently selected newsgroup is empty: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] BODY + [S] 420 No current article selected + +<span class="h4"><h4><a class="selflink" name="section-6.2.4" href="#section-6.2.4">6.2.4</a>. STAT</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.2.4.1" href="#section-6.2.4.1">6.2.4.1</a>. Usage</h5></span> + + This command is mandatory. + + Syntax + STAT message-id + STAT number + STAT + + Responses + + First form (message-id specified) + 223 0|n message-id Article exists + 430 No article with that message-id + + Second form (article number specified) + 223 n message-id Article exists + 412 No newsgroup selected + 423 No article with that number + + + + + + + +<span class="grey">Feather Standards Track [Page 53]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-54" id="page-54" href="#page-54" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Third form (current article number used) + 223 n message-id Article exists + 412 No newsgroup selected + 420 Current article number is invalid + + Parameters + number Requested article number + n Returned article number + message-id Article message-id + +<span class="h5"><h5><a class="selflink" name="section-6.2.4.2" href="#section-6.2.4.2">6.2.4.2</a>. Description</h5></span> + + The STAT command behaves identically to the ARTICLE command except + that, if the article exists, it is NOT presented to the client and + the response code is 223 instead of 220. Note that the response is + NOT multi-line. + + This command allows the client to determine whether an article exists + and, in the second and third forms, what its message-id is, without + having to process an arbitrary amount of text. + +<span class="h5"><h5><a class="selflink" name="section-6.2.4.3" href="#section-6.2.4.3">6.2.4.3</a>. Examples</h5></span> + + Example of STAT on an existing article (explicitly not using an + article number): + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT + [S] 223 3000234 <45223423@example.com> + + Example of STAT on an existing article by message-id: + + [<a name="ref-C" id="ref-C">C</a>] STAT <45223423@example.com> + [S] 223 0 <45223423@example.com> + + Example of STAT on an article not on the server by message-id: + + [<a name="ref-C" id="ref-C">C</a>] STAT <i.am.not.there@example.com> + [S] 430 No Such Article Found + + Example of STAT on an article not in the server by number: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT 300256 + [S] 423 No article with that number + + + + +<span class="grey">Feather Standards Track [Page 54]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-55" id="page-55" href="#page-55" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of STAT on an article by number when no newsgroup was + selected first: + + [Assumes currently selected newsgroup is invalid.] + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT 300256 + [S] 412 No newsgroup selected + + Example of STAT on an article when the currently selected newsgroup + is empty: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT + [S] 420 No current article selected + + Example of STAT by message-id on a server that sometimes reports the + actual article number: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT + [S] 223 3000234 <45223423@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT <45223423@example.com> + [S] 223 0 <45223423@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT <45223423@example.com> + [S] 223 3000234 <45223423@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT <45223423@example.com> + [S] 223 0 <45223423@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] GROUP alt.crossposts + [S] 211 9999 111111 222222 alt.crossposts + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT <45223423@example.com> + [S] 223 123456 <45223423@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] STAT + [S] 223 111111 <23894720@example.com> + + The first STAT command establishes the identity of an article in the + group. The second and third show that the server may, but need not, + give the article number when the message-id is specified. The fourth + STAT command shows that zero must be specified if the article isn't + in the currently selected newsgroup. The fifth shows that the + number, if provided, must be that relating to the currently selected + newsgroup. The last one shows that the current article number is + still not changed by the use of STAT with a message-id even if it + returns an article number. + + + + + +<span class="grey">Feather Standards Track [Page 55]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-56" id="page-56" href="#page-56" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h3"><h3><a class="selflink" name="section-6.3" href="#section-6.3">6.3</a>. Article Posting</h3></span> + + Article posting is done in one of two ways: individual article + posting from news-reading clients using POST, and article transfer + from other news servers using IHAVE. + +<span class="h4"><h4><a class="selflink" name="section-6.3.1" href="#section-6.3.1">6.3.1</a>. POST</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.3.1.1" href="#section-6.3.1.1">6.3.1.1</a>. Usage</h5></span> + + Indicating capability: POST + + This command MUST NOT be pipelined. + + Syntax + POST + + Responses + + Initial responses + 340 Send article to be posted + 440 Posting not permitted + + Subsequent responses + 240 Article received OK + 441 Posting failed + +<span class="h5"><h5><a class="selflink" name="section-6.3.1.2" href="#section-6.3.1.2">6.3.1.2</a>. Description</h5></span> + + If posting is allowed, a 340 response MUST be returned to indicate + that the article to be posted should be sent. If posting is + prohibited for some installation-dependent reason, a 440 response + MUST be returned. + + If posting is permitted, the article MUST be in the format specified + in <a href="#section-3.6">Section 3.6</a> and MUST be sent by the client to the server as a + multi-line data block (see <a href="#section-3.1.1">Section 3.1.1</a>). Thus a single dot (".") + on a line indicates the end of the text, and lines starting with a + dot in the original text have that dot doubled during transmission. + + Following the presentation of the termination sequence by the client, + the server MUST return a response indicating success or failure of + the article transfer. Note that response codes 340 and 440 are used + in direct response to the POST command while 240 and 441 are returned + after the article is sent. + + + + + + +<span class="grey">Feather Standards Track [Page 56]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-57" id="page-57" href="#page-57" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + A response of 240 SHOULD indicate that, barring unforeseen server + errors, the posted article will be made available on the server + and/or transferred to other servers, as appropriate, possibly + following further processing. In other words, articles not wanted by + the server SHOULD be rejected with a 441 response, rather than being + accepted and then discarded silently. However, the client SHOULD NOT + assume that the article has been successfully transferred unless it + receives an affirmative response from the server and SHOULD NOT + assume that it is being made available to other clients without + explicitly checking (for example, using the STAT command). + + If the session is interrupted before the response is received, it is + possible that an affirmative response was sent but has been lost. + Therefore, in any subsequent session, the client SHOULD either check + whether the article was successfully posted before resending or + ensure that the server will allocate the same message-id to the new + attempt (see <a href="#appendix-A.2">Appendix A.2</a>). The latter 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). + +<span class="h5"><h5><a class="selflink" name="section-6.3.1.3" href="#section-6.3.1.3">6.3.1.3</a>. Examples</h5></span> + + Example of a successful posting: + + [<a name="ref-C" id="ref-C">C</a>] POST + [S] 340 Input article; end with <CR-LF>.<CR-LF> + [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.net> + [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article + [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Net + [<a href="#ref-C" title='"Demo User"'>C</a>] + [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. + [<a href="#ref-C" title='"Demo User"'>C</a>] . + [S] 240 Article received OK + + Example of an unsuccessful posting: + + [<a name="ref-C" id="ref-C">C</a>] POST + [S] 340 Input article; end with <CR-LF>.<CR-LF> + [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.net> + [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article + [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Net + [<a href="#ref-C" title='"Demo User"'>C</a>] + [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. + [<a href="#ref-C" title='"Demo User"'>C</a>] . + [S] 441 Posting failed + + + + +<span class="grey">Feather Standards Track [Page 57]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-58" id="page-58" href="#page-58" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of an attempt to post when posting is not allowed: + + [Initial connection set-up completed.] + [S] 201 NNTP Service Ready, posting prohibited + [<a href="#ref-C" title='"Demo User"'>C</a>] POST + [S] 440 Posting not permitted + +<span class="h4"><h4><a class="selflink" name="section-6.3.2" href="#section-6.3.2">6.3.2</a>. IHAVE</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-6.3.2.1" href="#section-6.3.2.1">6.3.2.1</a>. Usage</h5></span> + + Indicating capability: IHAVE + + This command MUST NOT be pipelined. + + Syntax + IHAVE message-id + + Responses + + Initial responses + 335 Send article to be transferred + 435 Article not wanted + 436 Transfer not possible; try again later + + Subsequent responses + 235 Article transferred OK + 436 Transfer failed; try again later + 437 Transfer rejected; do not retry + + Parameters + message-id Article message-id + +<span class="h5"><h5><a class="selflink" name="section-6.3.2.2" href="#section-6.3.2.2">6.3.2.2</a>. Description</h5></span> + + The IHAVE command informs the server that the client has an article + with the specified message-id. If the server desires a copy of that + article, a 335 response MUST be returned, instructing the client to + send the entire article. If the server does not want the article + (if, for example, the server already has a copy of it), a 435 + response MUST be returned, indicating that the article is not wanted. + Finally, if the article isn't wanted immediately but the client + should retry later if possible (if, for example, another client is in + the process of sending the same article to the server), a 436 + response MUST be returned. + + + + + + +<span class="grey">Feather Standards Track [Page 58]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-59" id="page-59" href="#page-59" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + If transmission of the article is requested, the client MUST send the + entire article, including headers and body, to the server as a + multi-line data block (see <a href="#section-3.1.1">Section 3.1.1</a>). Thus, a single dot (".") + on a line indicates the end of the text, and lines starting with a + dot in the original text have that dot doubled during transmission. + The server MUST return a 235 response, indicating that the article + was successfully transferred; a 436 response, indicating that the + transfer failed but should be tried again later; or a 437 response, + indicating that the article was rejected. + + This function differs from the POST command in that it is intended + for use in transferring already-posted articles between hosts. It + SHOULD NOT be used when the client is a personal news-reading + program, since use of this command indicates that the article has + already been posted at another site and is simply being forwarded + from another host. However, despite this, the server MAY elect not + to post or forward the article if, after further examination of the + article, it deems it inappropriate to do so. Reasons for such + subsequent rejection of an article may include problems such as + inappropriate newsgroups or distributions, disc space limitations, + article lengths, garbled headers, and the like. These are typically + restrictions enforced by the server host's news software and not + necessarily by the NNTP server itself. + + The client SHOULD NOT assume that the article has been successfully + transferred unless it receives an affirmative response from the + server. A lack of response (such as a dropped network connection or + a network timeout) SHOULD be treated the same as a 436 response. + + Because some news server software may not immediately be able to + determine whether an article is suitable for posting or forwarding, + an NNTP server MAY acknowledge the successful transfer of the article + (with a 235 response) but later silently discard it. + + + + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 59]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-60" id="page-60" href="#page-60" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h5"><h5><a class="selflink" name="section-6.3.2.3" href="#section-6.3.2.3">6.3.2.3</a>. Examples</h5></span> + + Example of successfully sending an article to another site: + + [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.will.want@example.com> + [S] 335 Send it; end with <CR-LF>.<CR-LF> + [<a href="#ref-C" title='"Demo User"'>C</a>] Path: pathost!demo!somewhere!not-for-mail + [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article + [<a href="#ref-C" title='"Demo User"'>C</a>] Date: 6 Oct 1998 04:38:40 -0500 + [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Com, San Jose, CA + [<a href="#ref-C" title='"Demo User"'>C</a>] Message-ID: <i.am.an.article.you.will.want@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] + [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. + [<a href="#ref-C" title='"Demo User"'>C</a>] . + [S] 235 Article transferred OK + + Example of sending an article to another site that rejects it. Note + 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. + + [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.will.want@example.com> + [S] 335 Send it; end with <CR-LF>.<CR-LF> + [<a href="#ref-C" title='"Demo User"'>C</a>] Path: pathost!demo!somewhere!not-for-mail + [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article + [<a href="#ref-C" title='"Demo User"'>C</a>] Date: 6 Oct 1998 04:38:40 -0500 + [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Com, San Jose, CA + [<a href="#ref-C" title='"Demo User"'>C</a>] Message-ID: <i.am.an.article.you.have@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] + [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. + [<a href="#ref-C" title='"Demo User"'>C</a>] . + [S] 437 Article rejected; don't send again + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 60]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-61" id="page-61" href="#page-61" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of sending an article to another site where the transfer + fails: + + [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.will.want@example.com> + [S] 335 Send it; end with <CR-LF>.<CR-LF> + [<a href="#ref-C" title='"Demo User"'>C</a>] Path: pathost!demo!somewhere!not-for-mail + [<a href="#ref-C" title='"Demo User"'>C</a>] From: "Demo User" <nobody@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] Newsgroups: misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] Subject: I am just a test article + [<a href="#ref-C" title='"Demo User"'>C</a>] Date: 6 Oct 1998 04:38:40 -0500 + [<a href="#ref-C" title='"Demo User"'>C</a>] Organization: An Example Com, San Jose, CA + [<a href="#ref-C" title='"Demo User"'>C</a>] Message-ID: <i.am.an.article.you.will.want@example.com> + [<a href="#ref-C" title='"Demo User"'>C</a>] + [<a href="#ref-C" title='"Demo User"'>C</a>] This is just a test article. + [<a href="#ref-C" title='"Demo User"'>C</a>] . + [S] 436 Transfer failed + + Example of sending an article to a site that already has it: + + [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.have@example.com> + [S] 435 Duplicate + + Example of sending an article to a site that requests that the + article be tried again later: + + [<a name="ref-C" id="ref-C">C</a>] IHAVE <i.am.an.article.you.defer@example.com> + [S] 436 Retry later + +<span class="h2"><h2><a class="selflink" name="section-7" href="#section-7">7</a>. Information Commands</h2></span> + + This section lists other commands that may be used at any time + between the beginning of a session and its termination. Using these + commands does not alter any state information, but the response + generated from their use may provide useful information to clients. + +<span class="h3"><h3><a class="selflink" name="section-7.1" href="#section-7.1">7.1</a>. DATE</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-7.1.1" href="#section-7.1.1">7.1.1</a>. Usage</h4></span> + + Indicating capability: READER + + Syntax + DATE + + Responses + 111 yyyymmddhhmmss Server date and time + + + + + +<span class="grey">Feather Standards Track [Page 61]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-62" id="page-62" href="#page-62" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Parameters + yyyymmddhhmmss Current UTC date and time on server + +<span class="h4"><h4><a class="selflink" name="section-7.1.2" href="#section-7.1.2">7.1.2</a>. Description</h4></span> + + This command exists to help clients find out the current Coordinated + Universal Time [<a href="#ref-TF.686-1" title='"Glossary, ITU-R Recommendation TF.686-1"'>TF.686-1</a>] from the server's perspective. This + command SHOULD NOT be used as a substitute for NTP [<a href="https://tools.ietf.org/html/rfc1305" title='"Network Time Protocol (Version 3) Specification, Implementation and Analysis"'>RFC1305</a>] but to + provide information that might be useful when using the NEWNEWS + command (see <a href="#section-7.4">Section 7.4</a>). + + The DATE command MUST return a timestamp from the same clock as is + used for determining article arrival and group creation times (see + <a href="#section-6">Section 6</a>). This clock SHOULD be monotonic, and adjustments SHOULD + be made by running it fast or slow compared to "real" time rather + than by making sudden jumps. A system providing NNTP service SHOULD + keep the system clock as accurate as possible, either with NTP or by + some other method. + + The server MUST return a 111 response specifying the date and time on + the server in the form yyyymmddhhmmss. This date and time is in + Coordinated Universal Time. + +<span class="h4"><h4><a class="selflink" name="section-7.1.3" href="#section-7.1.3">7.1.3</a>. Examples</h4></span> + + [<a name="ref-C" id="ref-C">C</a>] DATE + [S] 111 19990623135624 + +<span class="h3"><h3><a class="selflink" name="section-7.2" href="#section-7.2">7.2</a>. HELP</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-7.2.1" href="#section-7.2.1">7.2.1</a>. Usage</h4></span> + + This command is mandatory. + + Syntax + HELP + + Responses + 100 Help text follows (multi-line) + +<span class="h4"><h4><a class="selflink" name="section-7.2.2" href="#section-7.2.2">7.2.2</a>. Description</h4></span> + + This command provides a short summary of the commands that are + understood by this implementation of the server. The help text will + be presented as a multi-line data block following the 100 response + code. + + + + + +<span class="grey">Feather Standards Track [Page 62]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-63" id="page-63" href="#page-63" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + This text is not guaranteed to be in any particular format (but must + be UTF-8) and MUST NOT be used by clients as a replacement for the + CAPABILITIES command described in <a href="#section-5.2">Section 5.2</a>. + +<span class="h4"><h4><a class="selflink" name="section-7.2.3" href="#section-7.2.3">7.2.3</a>. Examples</h4></span> + + [<a name="ref-C" id="ref-C">C</a>] HELP + [S] 100 Help text follows + [S] This is some help text. There is no specific + [S] formatting requirement for this test, though + [S] it is customary for it to list the valid commands + [S] and give a brief definition of what they do. + [S] . + +<span class="h3"><h3><a class="selflink" name="section-7.3" href="#section-7.3">7.3</a>. NEWGROUPS</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-7.3.1" href="#section-7.3.1">7.3.1</a>. Usage</h4></span> + + Indicating capability: READER + + Syntax + NEWGROUPS date time [GMT] + + Responses + 231 List of new newsgroups follows (multi-line) + + Parameters + date Date in yymmdd or yyyymmdd format + time Time in hhmmss format + +<span class="h4"><h4><a class="selflink" name="section-7.3.2" href="#section-7.3.2">7.3.2</a>. Description</h4></span> + + This command returns a list of newsgroups created on the server since + the specified date and time. The results are in the same format as + the LIST ACTIVE command (see <a href="#section-7.6.3">Section 7.6.3</a>). However, they MAY + include groups not available on the server (and so not returned by + LIST ACTIVE) and MAY omit groups for which the creation date is not + available. + + The date is specified as 6 or 8 digits in the format [xx]yymmdd, + where xx is the first two digits of the year (19-99), yy is the last + two digits of the year (00-99), mm is the month (01-12), and dd is + the day of the month (01-31). Clients SHOULD specify all four digits + of the year. If the first two digits of the year are not specified + (this is supported only for backward compatibility), the year is to + be taken from the current century if yy is smaller than or equal to + the current year, and the previous century otherwise. + + + + +<span class="grey">Feather Standards Track [Page 63]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-64" id="page-64" href="#page-64" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + The time is specified as 6 digits in the format hhmmss, where hh is + the hours in the 24-hour clock (00-23), mm is the minutes (00-59), + and ss is the seconds (00-60, to allow for leap seconds). The token + "GMT" specifies that the date and time are given in Coordinated + Universal Time [<a href="#ref-TF.686-1" title='"Glossary, ITU-R Recommendation TF.686-1"'>TF.686-1</a>]; if it is omitted, then the date and time + are specified in the server's local timezone. Note that there is no + way of using the protocol specified in this document to establish the + server's local timezone. + + Note that an empty list is a possible valid response and indicates + that there are no new newsgroups since that date-time. + + Clients SHOULD make all queries using Coordinated Universal Time + (i.e., by including the "GMT" argument) when possible. + +<span class="h4"><h4><a class="selflink" name="section-7.3.3" href="#section-7.3.3">7.3.3</a>. Examples</h4></span> + + Example where there are new groups: + + [<a name="ref-C" id="ref-C">C</a>] NEWGROUPS 19990624 000000 GMT + [S] 231 list of new newsgroups follows + [S] alt.rfc-writers.recovery 4 1 y + [S] tx.natives.recovery 89 56 y + [S] . + + Example where there are no new groups: + + [<a name="ref-C" id="ref-C">C</a>] NEWGROUPS 19990624 000000 GMT + [S] 231 list of new newsgroups follows + [S] . + +<span class="h3"><h3><a class="selflink" name="section-7.4" href="#section-7.4">7.4</a>. NEWNEWS</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-7.4.1" href="#section-7.4.1">7.4.1</a>. Usage</h4></span> + + Indicating capability: NEWNEWS + + Syntax + NEWNEWS wildmat date time [GMT] + + Responses + 230 List of new articles follows (multi-line) + + Parameters + wildmat Newsgroups of interest + date Date in yymmdd or yyyymmdd format + time Time in hhmmss format + + + + +<span class="grey">Feather Standards Track [Page 64]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-65" id="page-65" href="#page-65" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-7.4.2" href="#section-7.4.2">7.4.2</a>. Description</h4></span> + + This command returns a list of message-ids of articles posted or + received on the server, in the newsgroups whose names match the + wildmat, since the specified date and time. One message-id is sent + on each line; the order of the response has no specific significance + and may vary from response to response in the same session. A + message-id MAY appear more than once; if it does, it has the same + meaning as if it appeared only once. + + Date and time are in the same format as the NEWGROUPS command (see + <a href="#section-7.3">Section 7.3</a>). + + Note that an empty list is a possible valid response and indicates + that there is currently no new news in the relevant groups. + + Clients SHOULD make all queries in Coordinated Universal Time (i.e., + by using the "GMT" argument) when possible. + +<span class="h4"><h4><a class="selflink" name="section-7.4.3" href="#section-7.4.3">7.4.3</a>. Examples</h4></span> + + Example where there are new articles: + + [<a name="ref-C" id="ref-C">C</a>] NEWNEWS news.*,sci.* 19990624 000000 GMT + [S] 230 list of new articles by message-id follows + [S] <i.am.a.new.article@example.com> + [S] <i.am.another.new.article@example.com> + [S] . + + Example where there are no new articles: + + [<a name="ref-C" id="ref-C">C</a>] NEWNEWS alt.* 19990624 000000 GMT + [S] 230 list of new articles by message-id follows + [S] . + +<span class="h3"><h3><a class="selflink" name="section-7.5" href="#section-7.5">7.5</a>. Time</h3></span> + + As described in <a href="#section-6">Section 6</a>, each article has an arrival timestamp. + Each newsgroup also has a creation timestamp. These timestamps are + used by the NEWNEWS and NEWGROUP commands to construct their + responses. + + Clients can ensure that they do not have gaps in lists of articles or + groups by using the DATE command in the following manner: + + First session: + Issue DATE command and record result. + Issue NEWNEWS command using a previously chosen timestamp. + + + +<span class="grey">Feather Standards Track [Page 65]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-66" id="page-66" href="#page-66" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Subsequent sessions: + Issue DATE command and hold result in temporary storage. + Issue NEWNEWS command using timestamp saved from previous session. + Overwrite saved timestamp with that currently in temporary + storage. + + In order to allow for minor errors, clients MAY want to adjust the + timestamp back by two or three minutes before using it in NEWNEWS. + +<span class="h4"><h4><a class="selflink" name="section-7.5.1" href="#section-7.5.1">7.5.1</a>. Examples</h4></span> + + First session: + + [<a name="ref-C" id="ref-C">C</a>] DATE + [S] 111 20010203112233 + [<a href="#ref-C" title='"Demo User"'>C</a>] NEWNEWS local.chat 20001231 235959 GMT + [S] 230 list follows + [S] <article.1@local.service> + [S] <article.2@local.service> + [S] <article.3@local.service> + [S] . + + Second session (the client has subtracted 3 minutes from the + timestamp returned previously): + + [<a name="ref-C" id="ref-C">C</a>] DATE + [S] 111 20010204003344 + [<a href="#ref-C" title='"Demo User"'>C</a>] NEWNEWS local.chat 20010203 111933 GMT + [S] 230 list follows + [S] <article.3@local.service> + [S] <article.4@local.service> + [S] <article.5@local.service> + [S] . + + Note how <article.3@local.service> arrived in the 3 minute gap and so + is listed in both responses. + +<span class="h3"><h3><a class="selflink" name="section-7.6" href="#section-7.6">7.6</a>. The LIST Commands</h3></span> + + The LIST family of commands all return information that is multi-line + and that can, in general, be expected not to change during the + session. Often the information is related to newsgroups, in which + case the response has one line per newsgroup and a wildmat MAY be + provided to restrict the groups for which information is returned. + + The set of available keywords (including those provided by + extensions) is given in the capability list with capability label + LIST. + + + +<span class="grey">Feather Standards Track [Page 66]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-67" id="page-67" href="#page-67" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-7.6.1" href="#section-7.6.1">7.6.1</a>. LIST</h4></span> + +<span class="h5"><h5><a class="selflink" name="section-7.6.1.1" href="#section-7.6.1.1">7.6.1.1</a>. Usage</h5></span> + + Indicating capability: LIST + + Syntax + LIST [keyword [wildmat|argument]] + + Responses + 215 Information follows (multi-line) + + Parameters + keyword Information requested [<a href="#ref-1">1</a>] + argument Specific to keyword + wildmat Groups of interest + + [<a name="ref-1" id="ref-1">1</a>] If no keyword is provided, it defaults to ACTIVE. + +<span class="h5"><h5><a class="selflink" name="section-7.6.1.2" href="#section-7.6.1.2">7.6.1.2</a>. Description</h5></span> + + The LIST command allows the server to provide blocks of information + to the client. This information may be global or may be related to + newsgroups; in the latter case, the information may be returned + either for all groups or only for those matching a wildmat. Each + block of information is represented by a different keyword. The + command returns the specific information identified by the keyword. + + If the information is available, it is returned as a multi-line data + block following the 215 response code. The format of the information + depends on the keyword. The information MAY be affected by the + additional argument, but the format MUST NOT be. + + If the information is based on newsgroups and the optional wildmat + argument is specified, the response is limited to only the groups (if + any) whose names match the wildmat and for which the information is + available. + + Note that an empty list is a possible valid response; for a + newsgroup-based keyword, it indicates that there are no groups + meeting the above criteria. + + If the keyword is not recognised, or if an argument is specified and + the keyword does not expect one, a 501 response code MUST BE + returned. If the keyword is recognised but the server does not + maintain the information, a 503 response code MUST BE returned. + + + + + +<span class="grey">Feather Standards Track [Page 67]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-68" id="page-68" href="#page-68" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + The LIST command MUST NOT change the visible state of the server in + any way; that is, the behaviour of subsequent commands MUST NOT be + affected by whether the LIST command was issued. For example, it + MUST NOT make groups available that otherwise would not have been. + +<span class="h5"><h5><a class="selflink" name="section-7.6.1.3" href="#section-7.6.1.3">7.6.1.3</a>. Examples</h5></span> + + Example of LIST with the ACTIVE keyword: + + [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE + [S] 215 list of newsgroups follows + [S] misc.test 3002322 3000234 y + [S] comp.risks 442001 441099 m + [S] alt.rfc-writers.recovery 4 1 y + [S] tx.natives.recovery 89 56 y + [S] tx.natives.recovery.d 11 9 n + [S] . + + Example of LIST with no keyword: + + [<a name="ref-C" id="ref-C">C</a>] LIST + [S] 215 list of newsgroups follows + [S] misc.test 3002322 3000234 y + [S] comp.risks 442001 441099 m + [S] alt.rfc-writers.recovery 4 1 y + [S] tx.natives.recovery 89 56 y + [S] tx.natives.recovery.d 11 9 n + [S] . + + The output is identical to that of the previous example. + + Example of LIST on a newsgroup-based keyword with and without + wildmat: + + [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE.TIMES + [S] 215 information follows + [S] misc.test 930445408 <creatme@isc.org> + [S] alt.rfc-writers.recovery 930562309 <m@example.com> + [S] tx.natives.recovery 930678923 <sob@academ.com> + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] LIST ACTIVE.TIMES tx.* + [S] 215 information follows + [S] tx.natives.recovery 930678923 <sob@academ.com> + [S] . + + + + + + + +<span class="grey">Feather Standards Track [Page 68]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-69" id="page-69" href="#page-69" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of LIST returning an error where the keyword is recognized + but the software does not maintain this information: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] LIST XTRA.DATA + [S] 503 Data item not stored + + Example of LIST where the keyword is not recognised: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] LIST DISTRIB.PATS + [S] 501 Syntax Error + +<span class="h4"><h4><a class="selflink" name="section-7.6.2" href="#section-7.6.2">7.6.2</a>. Standard LIST Keywords</h4></span> + + This specification defines the following LIST keywords: + + +--------------+---------------+------------------------------------+ + | Keyword | Definition | Status | + +--------------+---------------+------------------------------------+ + | ACTIVE | <a href="#section-7.6.3">Section 7.6.3</a> | Mandatory if the READER capability | + | | | is advertised | + | | | | + | ACTIVE.TIMES | <a href="#section-7.6.4">Section 7.6.4</a> | Optional | + | | | | + | DISTRIB.PATS | <a href="#section-7.6.5">Section 7.6.5</a> | Optional | + | | | | + | HEADERS | <a href="#section-8.6">Section 8.6</a> | Mandatory if the HDR capability is | + | | | advertised | + | | | | + | NEWSGROUPS | <a href="#section-7.6.6">Section 7.6.6</a> | Mandatory if the READER capability | + | | | is advertised | + | | | | + | OVERVIEW.FMT | <a href="#section-8.4">Section 8.4</a> | Mandatory if the OVER capability | + | | | is advertised | + +--------------+---------------+------------------------------------+ + + + + + +<span class="grey">Feather Standards Track [Page 69]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-70" id="page-70" href="#page-70" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Where one of these LIST keywords is supported by a server, it MUST + have the meaning given in the relevant sub-section. + +<span class="h4"><h4><a class="selflink" name="section-7.6.3" href="#section-7.6.3">7.6.3</a>. LIST ACTIVE</h4></span> + + This keyword MUST be supported by servers advertising the READER + capability. + + LIST ACTIVE returns a list of valid newsgroups and associated + information. If no wildmat is specified, the server MUST include + every group that the client is permitted to select with the GROUP + command (<a href="#section-6.1.1">Section 6.1.1</a>). Each line of this list consists of four + fields separated from each other by one or more spaces: + + o The name of the newsgroup. + o The reported high water mark for the group. + o The reported low water mark for the group. + o The current status of the group on this server. + + The reported high and low water marks are as described in the GROUP + command (see <a href="#section-6.1.1">Section 6.1.1</a>), but note that they are in the opposite + order to the 211 response to that command. + + The status field is typically one of the following: + + "y" Posting is permitted. + + "n" Posting is not permitted. + + "m" Postings will be forwarded to the newsgroup moderator. + + The server SHOULD use these values when these meanings are required + and MUST NOT use them with any other meaning. Other values for the + status may exist; the definition of these other values and the + circumstances under which they are returned may be specified in an + extension or may be private to the server. A client SHOULD treat an + unrecognized status as giving no information. + + The status of a newsgroup only indicates how posts to that newsgroup + are normally processed and is not necessarily customised to the + specific client. For example, if the current client is forbidden + from posting, then this will apply equally to groups with status "y". + Conversely, a client with special privileges (not defined by this + specification) might be able to post to a group with status "n". + + + + + + + +<span class="grey">Feather Standards Track [Page 70]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-71" id="page-71" href="#page-71" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + For example: + + [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE + [S] 215 list of newsgroups follows + [S] misc.test 3002322 3000234 y + [S] comp.risks 442001 441099 m + [S] alt.rfc-writers.recovery 4 1 y + [S] tx.natives.recovery 89 56 y + [S] tx.natives.recovery.d 11 9 n + [S] . + + or, on an implementation that includes leading zeroes: + + [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE + [S] 215 list of newsgroups follows + [S] misc.test 0003002322 0003000234 y + [S] comp.risks 0000442001 0000441099 m + [S] alt.rfc-writers.recovery 0000000004 0000000001 y + [S] tx.natives.recovery 0000000089 0000000056 y + [S] tx.natives.recovery.d 0000000011 0000000009 n + [S] . + + The information is newsgroup based, and a wildmat MAY be specified, + in which case the response is limited to only the groups (if any) + whose names match the wildmat. For example: + + [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE *.recovery + [S] 215 list of newsgroups follows + [S] alt.rfc-writers.recovery 4 1 y + [S] tx.natives.recovery 89 56 y + [S] . + +<span class="h4"><h4><a class="selflink" name="section-7.6.4" href="#section-7.6.4">7.6.4</a>. LIST ACTIVE.TIMES</h4></span> + + This keyword is optional. + + The active.times list is maintained by some NNTP servers to contain + information about who created a particular newsgroup and when. Each + line of this list consists of three fields separated from each other + by one or more spaces. The first field is the name of the newsgroup. + The second is the time when this group was created on this news + server, measured in seconds since the start of January 1, 1970. The + third is plain text intended to describe the entity that created the + newsgroup; it is often a mailbox as defined in <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> [<a href="https://tools.ietf.org/html/rfc2822" title='"Internet Message Format"'>RFC2822</a>]. + For example: + + + + + + +<span class="grey">Feather Standards Track [Page 71]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-72" id="page-72" href="#page-72" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + [<a name="ref-C" id="ref-C">C</a>] LIST ACTIVE.TIMES + [S] 215 information follows + [S] misc.test 930445408 <creatme@isc.org> + [S] alt.rfc-writers.recovery 930562309 <m@example.com> + [S] tx.natives.recovery 930678923 <sob@academ.com> + [S] . + + The list MAY omit newsgroups for which the information is unavailable + and MAY include groups not available on the server; in particular, it + MAY omit all groups created before the date and time of the oldest + entry. The client MUST NOT assume that the list is complete or that + it matches the list returned by the LIST ACTIVE command + (<a href="#section-7.6.3">Section 7.6.3</a>). The NEWGROUPS command (<a href="#section-7.3">Section 7.3</a>) may provide a + better way to access this information, and the results of the two + commands SHOULD be consistent except that, if the latter is invoked + with a date and time earlier than the oldest entry in active.times + list, its result may include extra groups. + + The information is newsgroup based, and a wildmat MAY be specified, + in which case the response is limited to only the groups (if any) + whose names match the wildmat. + +<span class="h4"><h4><a class="selflink" name="section-7.6.5" href="#section-7.6.5">7.6.5</a>. LIST DISTRIB.PATS</h4></span> + + This keyword is optional. + + The distrib.pats list is maintained by some NNTP servers to assist + clients to choose a value for the content of the Distribution header + of a news article being posted. Each line of this list consists of + three fields separated from each other by a colon (":"). The first + field is a weight, the second field is a wildmat (which may be a + simple newsgroup name), and the third field is a value for the + Distribution header content. For example: + + [<a name="ref-C" id="ref-C">C</a>] LIST DISTRIB.PATS + [S] 215 information follows + [S] 10:local.*:local + [S] 5:*:world + [S] 20:local.here.*:thissite + [S] . + + The client MAY use this information to construct an appropriate + Distribution header given the name of a newsgroup. To do so, it + should determine the lines whose second field matches the newsgroup + 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 + the Distribution header. + + + + +<span class="grey">Feather Standards Track [Page 72]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-73" id="page-73" href="#page-73" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + The information is not newsgroup based, and an argument MUST NOT be + specified. + +<span class="h4"><h4><a class="selflink" name="section-7.6.6" href="#section-7.6.6">7.6.6</a>. LIST NEWSGROUPS</h4></span> + + This keyword MUST be supported by servers advertising the READER + capability. + + The newsgroups list is maintained by NNTP servers to contain the name + of each newsgroup that is available on the server and a short + description about the purpose of the group. Each line of this list + consists of two fields separated from each other by one or more space + or TAB characters (the usual practice is a single TAB). The first + field is the name of the newsgroup, and the second is a short + description of the group. For example: + + [<a name="ref-C" id="ref-C">C</a>] LIST NEWSGROUPS + [S] 215 information follows + [S] misc.test General Usenet testing + [S] alt.rfc-writers.recovery RFC Writers Recovery + [S] tx.natives.recovery Texas Natives Recovery + [S] . + + The list MAY omit newsgroups for which the information is unavailable + and MAY include groups not available on the server. The client MUST + NOT assume that the list is complete or that it matches the list + returned by LIST ACTIVE. + + The description SHOULD be in UTF-8. However, servers often obtain + the information from external sources. These sources may have used + different encodings (ones that use octets in the range 128 to 255 in + some other manner) and, in that case, the server MAY pass it on + unchanged. Therefore, clients MUST be prepared to receive such + descriptions. + + The information is newsgroup based, and a wildmat MAY be specified, + in which case the response is limited to only the groups (if any) + whose names match the wildmat. + +<span class="h2"><h2><a class="selflink" name="section-8" href="#section-8">8</a>. Article Field Access Commands</h2></span> + + This section lists commands that may be used to access specific + article fields; that is, headers of articles and metadata about + articles. These commands typically fetch data from an "overview + database", which is a database of headers extracted from incoming + articles plus metadata determined as the article arrives. Only + certain fields are included in the database. + + + + +<span class="grey">Feather Standards Track [Page 73]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-74" id="page-74" href="#page-74" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + This section is based on the Overview/NOV database [<a href="#ref-ROBE1995" title='"FAQ: Overview database / NOV General Information"'>ROBE1995</a>] + developed by Geoff Collyer. + +<span class="h3"><h3><a class="selflink" name="section-8.1" href="#section-8.1">8.1</a>. Article Metadata</h3></span> + + Article "metadata" is data about articles that does not occur within + the article itself. Each metadata item has a name that MUST begin + with a colon (and that MUST NOT contain a colon elsewhere within it). + As with header names, metadata item names are not case sensitive. + + When generating a metadata item, the server MUST compute it for + 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 + assumed to specify the correct number of lines or bytes in the + article.) If the server has access to several non-identical copies + of an article, the value returned MUST be correct for any copy of + that article retrieved during the same session. + + This specification defines two metadata items: ":bytes" and ":lines". + Other metadata items may be defined by extensions. The names of + metadata items defined by registered extensions MUST NOT begin with + ":x-". To avoid the risk of a clash with a future registered + extension, the names of metadata items defined by private extensions + SHOULD begin with ":x-". + +<span class="h4"><h4><a class="selflink" name="section-8.1.1" href="#section-8.1.1">8.1.1</a>. The :bytes Metadata Item</h4></span> + + The :bytes metadata item for an article is a decimal integer. It + SHOULD equal the number of octets in the entire article: headers, + body, and separating empty line (counting a CRLF pair as two octets, + and excluding both the "." CRLF terminating the response and any "." + added for "dot-stuffing" purposes). + + Note to client implementers: some existing servers return a value + different from that above. The commonest reasons for this are as + follows: + + o Counting a CRLF pair as one octet. + + o Including the "." character used for dot-stuffing in the number. + + o Including the terminating "." CRLF in the number. + + o Using one copy of an article for counting the octets but then + returning another one that differs in some (permitted) manner. + + Implementations should be prepared for such variation and MUST NOT + rely on the value being accurate. + + + +<span class="grey">Feather Standards Track [Page 74]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-75" id="page-75" href="#page-75" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-8.1.2" href="#section-8.1.2">8.1.2</a>. The :lines Metadata Item</h4></span> + + 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 line separating headers and body). Equivalently, it is two + less than the number of CRLF pairs that the BODY command would return + for that article (the extra two are those following the response code + and the termination octet). + +<span class="h3"><h3><a class="selflink" name="section-8.2" href="#section-8.2">8.2</a>. Database Consistency</h3></span> + + The information stored in the overview database may change over time. + If the database records the content or absence of a given field (that + is, a header or metadata item) for all 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 if it records a metadata item for some articles but not + for 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 that are not stored in the database. Therefore, + if a header appears in the LIST OVERVIEW.FMT output but not in the + OVER output for a given article, that header does not appear in the + article (similarly for metadata items). + + These rules assume that the fields being stored in the database + remain constant for long periods of time, and therefore the database + will be 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 since the change. + Therefore, the output from LIST OVERVIEW.FMT needs to be altered + twice. Firstly, 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. + + If the HDR command uses the overview database rather than taking + information directly from the articles, the same issues of + consistency and inconsistency apply, and the LIST HEADERS command + SHOULD take the same approach as the LIST OVERVIEW.FMT command in + resolving them. + + + + + + + +<span class="grey">Feather Standards Track [Page 75]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-76" id="page-76" href="#page-76" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h3"><h3><a class="selflink" name="section-8.3" href="#section-8.3">8.3</a>. OVER</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-8.3.1" href="#section-8.3.1">8.3.1</a>. Usage</h4></span> + + Indicating capability: OVER + + Syntax + OVER message-id + OVER range + OVER + + Responses + + First form (message-id specified) + 224 Overview information follows (multi-line) + 430 No article with that message-id + + Second form (range specified) + 224 Overview information follows (multi-line) + 412 No newsgroup selected + 423 No articles in that range + + Third form (current article number used) + 224 Overview information follows (multi-line) + 412 No newsgroup selected + 420 Current article number is invalid + + Parameters + range Number(s) of articles + message-id Message-id of article + +<span class="h4"><h4><a class="selflink" name="section-8.3.2" href="#section-8.3.2">8.3.2</a>. Description</h4></span> + + The OVER command returns the contents of all the fields in the + database for an article specified by message-id, or from a specified + article or range of articles in the currently selected newsgroup. + + The message-id argument indicates a specific article. The range + argument may be any of the following: + + o An article number. + + o An article number followed by a dash to indicate all following. + + o An article number followed by a dash followed by another article + number. + + If neither is specified, the current article number is used. + + + +<span class="grey">Feather Standards Track [Page 76]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-77" id="page-77" href="#page-77" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Support for the first (message-id) form is optional. If it is + supported, the OVER capability line MUST include the argument + "MSGID". Otherwise, the capability line MUST NOT include this + argument, and the OVER command MUST return the generic response code + 503 when this form is used. + + If the information is available, it is returned as a multi-line data + block following the 224 response code and contains one line per + article, sorted in numerical order of article number. (Note that + unless the argument is a range including a dash, there will be + exactly one line in the data block.) Each line 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 of trailing TABs may + be omitted. + + The first 8 fields MUST be the following, in order: + + "0" or article number (see below) + Subject header content + From header content + Date header content + Message-ID header content + References header content + :bytes metadata item + :lines metadata item + + If the article is specified by message-id (the first form of the + command), the article number MUST be replaced with zero, except that + if there is a currently selected newsgroup and the article is present + in that group, the server MAY use the article's number in that group. + (See the ARTICLE command (<a href="#section-6.2.1">Section 6.2.1</a>) and STAT examples + (<a href="#section-6.2.4.3">Section 6.2.4.3</a>) for more details.) In the other two forms of the + command, the article number MUST be returned. + + Any subsequent fields are the contents of the other headers and + metadata held in the database. + + 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 + 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 the two mandatory metadata items, the content of the field MUST + be just the value, with no other text. + + For all subsequent fields that contain headers, the content MUST be + the entire header line other than the trailing CRLF. For all + subsequent fields that contain metadata, the field consists of the + metadata name, a single space, and then the value. + + + +<span class="grey">Feather Standards Track [Page 77]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-78" id="page-78" href="#page-78" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + For all fields, the value is processed by first removing all CRLF + pairs (that is, undoing any folding and removing the terminating + CRLF) and then replacing each TAB with a single space. If there is + no such header in the article, no such metadata item, or no header or + item stored in the database for that article, the corresponding field + MUST be empty. + + Note that, after unfolding, the characters NUL, LF, and CR cannot + occur in the header of an article offered by a conformant server. + Nevertheless, servers SHOULD check for these characters and replace + each one by a single space (so that, for example, CR LF LF TAB will + become two spaces, since the CR and first LF will be removed by the + unfolding process). This will encourage robustness in the face of + non-conforming data; it is also possible that future versions of this + specification could permit these characters to appear in articles. + + The server SHOULD NOT produce output for articles that no longer + exist. + + If the argument is a message-id and no such article exists, a 430 + response MUST be returned. If the argument is a range or is omitted + and the currently selected newsgroup is invalid, a 412 response MUST + be returned. If the argument is a range and no articles in that + number range exist in the currently selected newsgroup, including the + case where the second number is less than the first one, a 423 + response MUST be returned. If the argument is omitted and the + current article number is invalid, a 420 response MUST be returned. + +<span class="h4"><h4><a class="selflink" name="section-8.3.3" href="#section-8.3.3">8.3.3</a>. Examples</h4></span> + + In the first four examples, TAB has been replaced by vertical bar and + some lines have been folded for readability. + + Example of a successful retrieval of overview information for an + article (explicitly not using an article number): + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] OVER + [S] 224 Overview information follows + [S] 3000234|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] . + + + + + + +<span class="grey">Feather Standards Track [Page 78]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-79" id="page-79" href="#page-79" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of a successful retrieval of overview information for an + article by message-id: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] OVER MSGID + [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] 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 the same commands on a system that does not implement + retrieval by message-id: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] OVER + [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] OVER <45223423@example.com> + [S] 503 Overview by message-id unsupported + + + + + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 79]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-80" id="page-80" href="#page-80" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of a successful retrieval of overview information for a range + of articles: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] OVER 3000234-3000240 + [S] 224 Overview information follows + [S] 3000234|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] 3000235|Another test article|nobody@nowhere.to + (Demo User)|6 Oct 1998 04:38:45 -0500|<45223425@to.to>|| + 4818|37||Distribution: fi + [S] 3000238|Re: I am just a test article|somebody@elsewhere.to| + 7 Oct 1998 11:38:40 +1200|<kfwer3v@elsewhere.to>| + <45223423@to.to>|9234|51 + [S] . + + Note the missing "References" and Xref headers in the second line, + the missing trailing fields in the first and last lines, and that + there are only results for those articles that still exist. + + Example of an unsuccessful retrieval of overview information on an + article by number: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] OVER 300256 + [S] 423 No such article in this group + + Example of an invalid range: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] OVER 3000444-3000222 + [S] 423 Empty range + + Example of an unsuccessful retrieval of overview information by + number because no newsgroup was selected first: + + [Assumes currently selected newsgroup is invalid.] + [<a href="#ref-C" title='"Demo User"'>C</a>] OVER + [S] 412 No newsgroup selected + + + + + + + +<span class="grey">Feather Standards Track [Page 80]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-81" id="page-81" href="#page-81" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of an attempt to retrieve information when the currently + selected newsgroup is empty: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] OVER + [S] 420 No current article selected + +<span class="h3"><h3><a class="selflink" name="section-8.4" href="#section-8.4">8.4</a>. LIST OVERVIEW.FMT</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-8.4.1" href="#section-8.4.1">8.4.1</a>. Usage</h4></span> + + Indicating capability: OVER + + Syntax + LIST OVERVIEW.FMT + + Responses + 215 Information follows (multi-line) + +<span class="h4"><h4><a class="selflink" name="section-8.4.2" href="#section-8.4.2">8.4.2</a>. Description</h4></span> + + See <a href="#section-7.6.1">Section 7.6.1</a> for general requirements of the LIST command. + + The LIST OVERVIEW.FMT command returns a description of the fields in + the database for which it is consistent (as described above). The + information is returned as a multi-line data block following the 215 + response code. The information contains one line per field in the + order in which they are returned by the OVER command; the first 7 + lines MUST (except for the case of letters) be exactly as follows: + + Subject: + From: + Date: + Message-ID: + References: + :bytes + :lines + + For compatibility with existing implementations, the last two lines + MAY instead be: + + Bytes: + Lines: + + even though they refer to metadata, not headers. + + + + + +<span class="grey">Feather Standards Track [Page 81]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-82" id="page-82" href="#page-82" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + All subsequent lines MUST consist of either a header name followed by + ":full", or the name of a piece of metadata. + + There are no leading or trailing spaces in the output. + + Note that the 7 fixed lines describe the 2nd to 8th fields of the + OVER output. The "full" suffix (which may use either uppercase, + lowercase, or a mix) is a reminder that the corresponding fields + include the header name. + + This command MAY generate different results if it is used more than + once in a session. + + If the OVER command is not implemented, the meaning of the output + from this command is not specified, but it must still meet the above + syntactic requirements. + +<span class="h4"><h4><a class="selflink" name="section-8.4.3" href="#section-8.4.3">8.4.3</a>. Examples</h4></span> + + Example of LIST OVERVIEW.FMT output corresponding to the example OVER + output above, in the preferred format: + + [<a name="ref-C" id="ref-C">C</a>] LIST OVERVIEW.FMT + [S] 215 Order of fields in overview database. + [S] Subject: + [S] From: + [S] Date: + [S] Message-ID: + [S] References: + [S] :bytes + [S] :lines + [S] Xref:full + [S] Distribution:full + [S] . + + + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 82]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-83" id="page-83" href="#page-83" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of LIST OVERVIEW.FMT output corresponding to the example OVER + output above, in the alternative format: + + [<a name="ref-C" id="ref-C">C</a>] LIST OVERVIEW.FMT + [S] 215 Order of fields in overview database. + [S] Subject: + [S] From: + [S] Date: + [S] Message-ID: + [S] References: + [S] Bytes: + [S] Lines: + [S] Xref:FULL + [S] Distribution:FULL + [S] . + +<span class="h3"><h3><a class="selflink" name="section-8.5" href="#section-8.5">8.5</a>. HDR</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-8.5.1" href="#section-8.5.1">8.5.1</a>. Usage</h4></span> + + Indicating capability: HDR + + Syntax + HDR field message-id + HDR field range + HDR field + + Responses + + First form (message-id specified) + 225 Headers follow (multi-line) + 430 No article with that message-id + + Second form (range specified) + 225 Headers follow (multi-line) + 412 No newsgroup selected + 423 No articles in that range + + Third form (current article number used) + 225 Headers follow (multi-line) + 412 No newsgroup selected + 420 Current article number is invalid + + Parameters + field Name of field + range Number(s) of articles + message-id Message-id of article + + + + +<span class="grey">Feather Standards Track [Page 83]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-84" id="page-84" href="#page-84" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-8.5.2" href="#section-8.5.2">8.5.2</a>. Description</h4></span> + + The HDR command provides access to specific fields from an article + specified by message-id, or from a specified article or range of + articles in the currently selected newsgroup. It MAY take the + information directly from the articles or from the overview database. + In the case of headers, an implementation MAY restrict the use of + this command to a specific list of headers or MAY allow it to be used + with any header; it may behave differently when it is used with a + message-id argument and when it is used with a range or no argument. + + The required field argument is the name of a header with the colon + omitted (e.g., "subject") or the name of a metadata item including + the leading colon (e.g., ":bytes"), and is case insensitive. + + The message-id argument indicates a specific article. The range + argument may be any of the following: + + o An article number. + + o An article number followed by a dash to indicate all following. + + o An article number followed by a dash followed by another article + number. + + If neither is specified, the current article number is used. + + If the information is available, it is returned as a multi-line data + block following the 225 response code and contains one line for each + article in the range that exists. (Note that unless the argument is + a range including a dash, there will be exactly one line in the data + block.) The line consists of the article number, a space, and then + the contents of the field. In the case of a header, the header name, + the colon, and the first space after the colon are all omitted. + + If the article is specified by message-id (the first form of the + command), the article number MUST be replaced with zero, except that + if there is a currently selected newsgroup and the article is present + in that group, the server MAY use the article's number in that group. + (See the ARTICLE command (<a href="#section-6.2.1">Section 6.2.1</a>) and STAT examples + (<a href="#section-6.2.4.3">Section 6.2.4.3</a>) for more details.) In the other two forms of the + command, the article number MUST be returned. + + 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 the same transformation as is performed by the OVER command + (<a href="#section-8.3.2">Section 8.3.2</a>), and the same comment concerning NUL, CR, and LF + applies.) + + + +<span class="grey">Feather Standards Track [Page 84]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-85" id="page-85" href="#page-85" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Note the distinction between headers and metadata appearing to have + the same meaning. Headers are always taken unchanged from the + article; metadata are always calculated. For example, a request for + "Lines" returns the contents of the "Lines" header of the specified + articles, if any, no matter whether they accurately state the number + of lines, while a request for ":lines" returns the line count + metadata, which is always the actual number of lines irrespective of + what any header may state. + + If the requested header is not present in the article, or if it is + present but empty, a line for that article is included in the output, + but the header content portion of the line is empty (the space after + the article number MAY be retained or omitted). If the header occurs + in a given article more than once, only the content of the first + occurrence is returned by HDR. If any article number in the provided + range does not exist in the group, no line for that article number is + included in the output. + + If the second argument is a message-id and no such article exists, a + 430 response MUST be returned. If the second argument is a range or + is omitted and the currently selected newsgroup is invalid, a 412 + response MUST be returned. If the second argument is a range and no + articles in that number range exist in the currently selected + newsgroup, including the case where the second number is less than + the first one, a 423 response MUST be returned. If the second + argument is omitted and the current article number is invalid, a 420 + response MUST be returned. + + A server MAY only allow HDR commands for a limited set of fields; it + may behave differently in this respect for the first (message-id) + form from how it would for the other forms. If so, it MUST respond + with the generic 503 response to attempts to request other fields, + rather than return erroneous results, such as a successful empty + response. + + If HDR uses the overview database and it is inconsistent for the + requested field, the server MAY return what results it can, or it MAY + respond with the generic 503 response. In the latter case, the field + MUST NOT appear in the output from LIST HEADERS. + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 85]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-86" id="page-86" href="#page-86" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-8.5.3" href="#section-8.5.3">8.5.3</a>. Examples</h4></span> + + Example of a successful retrieval of subject lines from a range of + articles (3000235 has no Subject header, and 3000236 is missing): + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] HDR Subject 3000234-3000238 + [S] 225 Headers follow + [S] 3000234 I am just a test article + [S] 3000235 + [S] 3000237 Re: I am just a test article + [S] 3000238 Ditto + [S] . + + Example of a successful retrieval of line counts from a range of + articles: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] HDR :lines 3000234-3000238 + [S] 225 Headers follow + [S] 3000234 42 + [S] 3000235 5 + [S] 3000237 11 + [S] 3000238 2378 + [S] . + + Example of a successful retrieval of the subject line from an article + by message-id: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] HDR subject <i.am.a.test.article@example.com> + [S] 225 Header information follows + [S] 0 I am just a test article + [S] . + + Example of a successful retrieval of the subject line from the + current article: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] HDR subject + [S] 225 Header information follows + [S] 3000234 I am just a test article + [S] . + + + + +<span class="grey">Feather Standards Track [Page 86]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-87" id="page-87" href="#page-87" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of an unsuccessful retrieval of a header from an article by + message-id: + + [<a name="ref-C" id="ref-C">C</a>] HDR subject <i.am.not.there@example.com> + [S] 430 No Such Article Found + + Example of an unsuccessful retrieval of headers from articles by + number because no newsgroup was selected first: + + [Assumes currently selected newsgroup is invalid.] + [<a href="#ref-C" title='"Demo User"'>C</a>] HDR subject 300256- + [S] 412 No newsgroup selected + + Example of an unsuccessful retrieval of headers because the currently + selected newsgroup is empty: + + [<a name="ref-C" id="ref-C">C</a>] GROUP example.empty.newsgroup + [S] 211 0 0 0 example.empty.newsgroup + [<a href="#ref-C" title='"Demo User"'>C</a>] HDR subject 1- + [S] 423 No articles in that range + + Example of an unsuccessful retrieval of headers because the server + does not allow HDR commands for that header: + + [<a name="ref-C" id="ref-C">C</a>] GROUP misc.test + [S] 211 1234 3000234 3002322 misc.test + [<a href="#ref-C" title='"Demo User"'>C</a>] HDR Content-Type 3000234-3000238 + [S] 503 HDR not permitted on Content-Type + +<span class="h3"><h3><a class="selflink" name="section-8.6" href="#section-8.6">8.6</a>. LIST HEADERS</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-8.6.1" href="#section-8.6.1">8.6.1</a>. Usage</h4></span> + + Indicating capability: HDR + + Syntax + LIST HEADERS [MSGID|RANGE] + + Responses + 215 Field list follows (multi-line) + + Parameters + MSGID Requests list for access by message-id + RANGE Requests list for access by range + + + + + + + +<span class="grey">Feather Standards Track [Page 87]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-88" id="page-88" href="#page-88" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-8.6.2" href="#section-8.6.2">8.6.2</a>. Description</h4></span> + + See <a href="#section-7.6.1">Section 7.6.1</a> for general requirements of the LIST command. + + The LIST HEADERS command returns a list of fields that may be + retrieved using the HDR command. + + The information is returned as a multi-line data block following the + 215 response code and contains one line for each field name + (excluding the trailing colon for headers and including the leading + colon for metadata items). If the implementation allows any header + to be retrieved, 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 explicitly 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 + HDR command). + + An implementation that also supports the OVER command SHOULD at least + permit all the headers and metadata items listed in the output from + the LIST OVERVIEW.FMT command. + + If the server treats the first form of the HDR command (message-id + specified) differently from the other two forms (range specified or + current article number used) in respect of which headers or metadata + items are available, then the following apply: + + o If the MSGID argument is specified, the results MUST be those + available for the first form of the HDR command. + + o If the RANGE argument is specified, the results MUST be those + available for the second and third forms of the HDR command. + + o If no argument is specified, the results MUST be those available + in all forms of the HDR command (that is, it MUST only list those + items listed in both the previous cases). + + If the server does not treat the various forms differently, then it + MUST ignore any argument and always produce the same results (though + not necessarily always in the same order). + + If the HDR command is not implemented, the meaning of the output from + this command is not specified, but it must still meet the above + syntactic requirements. + + + + + + +<span class="grey">Feather Standards Track [Page 88]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-89" id="page-89" href="#page-89" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h4"><h4><a class="selflink" name="section-8.6.3" href="#section-8.6.3">8.6.3</a>. Examples</h4></span> + + Example of an implementation providing access to only a few headers: + + [<a name="ref-C" id="ref-C">C</a>] 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 <a href="#section-8.4.3">Section 8.4.3</a>: + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] OVER + [S] HDR + [S] LIST ACTIVE NEWSGROUPS HEADERS OVERVIEW.FMT + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] 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: + + [<a name="ref-C" id="ref-C">C</a>] LIST HEADERS + [S] 215 metadata items supported: + [S] : + [S] :lines + [S] :bytes + [S] :x-article-number + [S] . + + + + + + + +<span class="grey">Feather Standards Track [Page 89]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-90" id="page-90" href="#page-90" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Example of an implementation distinguishing the first form of the HDR + command from the other two forms: + + [<a name="ref-C" id="ref-C">C</a>] LIST HEADERS RANGE + [S] 215 metadata items supported: + [S] : + [S] :lines + [S] :bytes + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] LIST HEADERS MSGID + [S] 215 headers and metadata items supported: + [S] Date + [S] Distribution + [S] From + [S] Message-ID + [S] References + [S] Subject + [S] :lines + [S] :bytes + [S] :x-article-number + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] LIST HEADERS + [S] 215 headers and metadata items supported: + [S] Date + [S] Distribution + [S] From + [S] Message-ID + [S] References + [S] Subject + [S] :lines + [S] :bytes + [S] . + + Note that :x-article-number does not appear in the last set of + output. + +<span class="h2"><h2><a class="selflink" name="section-9" href="#section-9">9</a>. Augmented BNF Syntax for NNTP</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-9.1" href="#section-9.1">9.1</a>. Introduction</h3></span> + + Each of the following sections describes the syntax of a major + element of NNTP. This syntax extends and refines the descriptions + elsewhere in this specification and should be given precedence when + resolving apparent conflicts. Note that ABNF [<a href="https://tools.ietf.org/html/rfc4234" title='"Augmented BNF for Syntax Specifications: ABNF"'>RFC4234</a>] strings are + case insensitive. Non-terminals used in several places are defined + in a separate section at the end. + + + + + +<span class="grey">Feather Standards Track [Page 90]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-91" id="page-91" href="#page-91" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Between them, the non-terminals <command-line>, <command-datastream>, + <command-continuation>, and <response> specify the text that flows + between client and server. A consistent naming scheme is used in + this document for the non-terminals relating to each command, and + SHOULD be used by the specification of registered extensions. + + For each command, the sequence is as follows: + + o The client sends an instance of <command-line>; the syntax for the + EXAMPLE command is <example-command>. + + o If the client is one that immediately streams data, it sends an + instance of <command-datastream>; the syntax for the EXAMPLE + command is <example-datastream>. + + o The server sends an instance of <response>. + + * The initial response line is independent of the command that + generated it; if the 000 response has arguments, the syntax of + the initial line is <response-000-content>. + + * If the response is multi-line, the initial line is followed by + a <multi-line-data-block>. The syntax for the contents of this + block after "dot-stuffing" has been removed is (for the 000 + response to the EXAMPLE command) <example-000-ml-content> and + is an instance of <multi-line-response-content>. + + o While the latest response is one that indicates more data is + required (in general, a 3xx response): + + * the client sends an instance of <command-continuation>; the + syntax for the EXAMPLE continuation following a 333 response is + <example-333-continuation>; + + * the server sends another instance of <response>, as above. + + (There are no commands in this specification that immediately stream + data, but this non-terminal is defined for the convenience of + extensions.) + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 91]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-92" id="page-92" href="#page-92" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h3"><h3><a class="selflink" name="section-9.2" href="#section-9.2">9.2</a>. Commands</h3></span> + + This syntax defines the non-terminal <command-line>, which represents + what is sent from the client to the server (see <a href="#section-3.1">section 3.1</a> for + limits on lengths). + + command-line = command EOL + command = X-command + X-command = keyword *(WS token) + + command =/ article-command / + body-command / + capabilities-command / + date-command / + group-command / + hdr-command / + head-command / + help-command / + ihave-command / + last-command / + list-command / + listgroup-command / + mode-reader-command / + newgroups-command / + newnews-command / + next-command / + over-command / + post-command / + quit-command / + stat-command + + article-command = "ARTICLE" [WS article-ref] + body-command = "BODY" [WS article-ref] + capabilities-command = "CAPABILITIES" [WS keyword] + date-command = "DATE" + group-command = "GROUP" [WS newsgroup-name] + hdr-command = "HDR" WS header-meta-name [WS range-ref] + head-command = "HEAD" [WS article-ref] + help-command = "HELP" + ihave-command = "IHAVE" WS message-id + last-command = "LAST" + list-command = "LIST" [WS list-arguments] + listgroup-command = "LISTGROUP" [WS newsgroup-name [WS range]] + mode-reader-command = "MODE" WS "READER" + newgroups-command = "NEWGROUPS" WS date-time + newnews-command = "NEWNEWS" WS wildmat WS date-time + next-command = "NEXT" + over-command = "OVER" [WS range-ref] + + + +<span class="grey">Feather Standards Track [Page 92]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-93" id="page-93" href="#page-93" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + post-command = "POST" + quit-command = "QUIT" + stat-command = "STAT" [WS article-ref] + + article-ref = article-number / message-id + date = date2y / date4y + date4y = 4DIGIT 2DIGIT 2DIGIT + date2y = 2DIGIT 2DIGIT 2DIGIT + date-time = date WS time [WS "GMT"] + header-meta-name = header-name / metadata-name + list-arguments = keyword [WS token] + metadata-name = ":" 1*A-NOTCOLON + range = article-number ["-" [article-number]] + range-ref = range / message-id + time = 2DIGIT 2DIGIT 2DIGIT + +<span class="h3"><h3><a class="selflink" name="section-9.3" href="#section-9.3">9.3</a>. Command Continuation</h3></span> + + This syntax defines the further material sent by the client in the + case of multi-stage commands and those that stream data. + + command-datastream = UNDEFINED + ; not used, provided as a hook for extensions + command-continuation = ihave-335-continuation / + post-340-continuation + + ihave-335-continuation = encoded-article + post-340-continuation = encoded-article + + encoded-article = multi-line-data-block + ; after undoing the "dot-stuffing", this MUST match <article> + +<span class="h3"><h3><a class="selflink" name="section-9.4" href="#section-9.4">9.4</a>. Responses</h3></span> + +<span class="h4"><h4><a class="selflink" name="section-9.4.1" href="#section-9.4.1">9.4.1</a>. Generic Responses</h4></span> + + This syntax defines the non-terminal <response>, which represents the + generic form of responses; that is, what is sent from the server to + the client in response to a <command> or a <command-continuation>. + + response = simple-response / multi-line-response + simple-response = initial-response-line + multi-line-response = initial-response-line multi-line-data-block + + initial-response-line = + initial-response-content [SP trailing-comment] CRLF + initial-response-content = X-initial-response-content + X-initial-response-content = 3DIGIT *(SP response-argument) + + + +<span class="grey">Feather Standards Track [Page 93]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-94" id="page-94" href="#page-94" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + response-argument = 1*A-CHAR + trailing-comment = *U-CHAR + +<span class="h4"><h4><a class="selflink" name="section-9.4.2" href="#section-9.4.2">9.4.2</a>. Initial Response Line Contents</h4></span> + + This syntax defines the specific initial response lines for the + various commands in this specification (see <a href="#section-3.1">section 3.1</a> for limits on + lengths). Only those response codes with arguments are listed. + + initial-response-content =/ response-111-content / + response-211-content / + response-220-content / + response-221-content / + response-222-content / + response-223-content / + response-401-content + + response-111-content = "111" SP date4y time + response-211-content = "211" 3(SP article-number) SP newsgroup-name + response-220-content = "220" SP article-number SP message-id + response-221-content = "221" SP article-number SP message-id + response-222-content = "222" SP article-number SP message-id + response-223-content = "223" SP article-number SP message-id + response-401-content = "401" SP capability-label + +<span class="h4"><h4><a class="selflink" name="section-9.4.3" href="#section-9.4.3">9.4.3</a>. Multi-line Response Contents</h4></span> + + This syntax defines the content of the various multi-line responses; + more precisely, it defines the part of the response in the multi-line + data block after any "dot-stuffing" has been undone. The numeric + portion of each non-terminal name indicates the response code that is + followed by this data. + + multi-line-response-content = article-220-ml-content / + body-222-ml-content / + capabilities-101-ml-content / + hdr-225-ml-content / + head-221-ml-content / + help-100-ml-content / + list-215-ml-content / + listgroup-211-ml-content / + newgroups-231-ml-content / + newnews-230-ml-content / + over-224-ml-content + + article-220-ml-content = article + body-222-ml-content = body + capabilities-101-ml-content = version-line CRLF + + + +<span class="grey">Feather Standards Track [Page 94]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-95" id="page-95" href="#page-95" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + *(capability-line CRLF) + hdr-225-ml-content = *(article-number SP hdr-content CRLF) + head-221-ml-content = 1*header + help-100-ml-content = *(*U-CHAR CRLF) + list-215-ml-content = list-content + listgroup-211-ml-content = *(article-number CRLF) + newgroups-231-ml-content = active-groups-list + newnews-230-ml-content = *(message-id CRLF) + over-224-ml-content = *(article-number over-content CRLF) + + active-groups-list = *(newsgroup-name SPA article-number + SPA article-number SPA newsgroup-status CRLF) + hdr-content = *S-NONTAB + hdr-n-content = [(header-name ":" / metadata-name) SP hdr-content] + list-content = body + newsgroup-status = %x79 / %x6E / %x6D / private-status + over-content = 1*6(TAB hdr-content) / + 7(TAB hdr-content) *(TAB hdr-n-content) + private-status = token ; except the values in newsgroup-status + +<span class="h3"><h3><a class="selflink" name="section-9.5" href="#section-9.5">9.5</a>. Capability Lines</h3></span> + + This syntax defines the generic form of a capability line in the + capabilities list (see <a href="#section-3.3.1">Section 3.3.1</a>). + + capability-line = capability-entry + capability-entry = X-capability-entry + X-capability-entry = capability-label *(WS capability-argument) + capability-label = keyword + capability-argument = token + + This syntax defines the specific capability entries for the + capabilities in this specification. + + capability-entry =/ + hdr-capability / + ihave-capability / + implementation-capability / + list-capability / + mode-reader-capability / + newnews-capability / + over-capability / + post-capability / + reader-capability + + hdr-capability = "HDR" + ihave-capability = "IHAVE" + implementation-capability = "IMPLEMENTATION" *(WS token) + + + +<span class="grey">Feather Standards Track [Page 95]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-96" id="page-96" href="#page-96" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + list-capability = "LIST" 1*(WS keyword) + mode-reader-capability = "MODE-READER" + newnews-capability = "NEWNEWS" + over-capability = "OVER" [WS "MSGID"] + post-capability = "POST" + reader-capability = "READER" + + version-line = "VERSION" 1*(WS version-number) + version-number = nzDIGIT *5DIGIT + +<span class="h3"><h3><a class="selflink" name="section-9.6" href="#section-9.6">9.6</a>. LIST Variants</h3></span> + + This section defines more specifically the keywords for the LIST + command and the syntax of the corresponding response contents. + + ; active + list-arguments =/ "ACTIVE" [WS wildmat] + list-content =/ list-active-content + list-active-content = active-groups-list + + + ; active.times + list-arguments =/ "ACTIVE.TIMES" [WS wildmat] + list-content =/ list-active-times-content + list-active-times-content = + *(newsgroup-name SPA 1*DIGIT SPA newsgroup-creator CRLF) + newsgroup-creator = U-TEXT + + + ; distrib.pats + list-arguments =/ "DISTRIB.PATS" + list-content =/ list-distrib-pats-content + list-distrib-pats-content = + *(1*DIGIT ":" wildmat ":" distribution CRLF) + distribution = token + + + ; headers + list-arguments =/ "HEADERS" [WS ("MSGID" / "RANGE")] + list-content =/ list-headers-content + list-headers-content = *(header-meta-name CRLF) / + *((metadata-name / ":") CRLF) + + + ; newsgroups + list-arguments =/ "NEWSGROUPS" [WS wildmat] + list-content =/ list-newsgroups-content + list-newsgroups-content = + + + +<span class="grey">Feather Standards Track [Page 96]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-97" id="page-97" href="#page-97" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + *(newsgroup-name WS newsgroup-description CRLF) + newsgroup-description = S-TEXT + + + ; overview.fmt + list-arguments =/ "OVERVIEW.FMT" + list-content =/ list-overview-fmt-content + list-overview-fmt-content = "Subject:" CRLF + "From:" CRLF + "Date:" CRLF + "Message-ID:" CRLF + "References:" CRLF + ( ":bytes" CRLF ":lines" / "Bytes:" CRLF "Lines:") CRLF + *((header-name ":full" / metadata-name) CRLF) + +<span class="h3"><h3><a class="selflink" name="section-9.7" href="#section-9.7">9.7</a>. Articles</h3></span> + + This syntax defines the non-terminal <article>, which represents the + format of an article as described in <a href="#section-3.6">Section 3.6</a>. + + article = 1*header CRLF body + header = header-name ":" [CRLF] SP header-content CRLF + header-content = *(S-CHAR / [CRLF] WS) + body = *(*B-CHAR CRLF) + +<span class="h3"><h3><a class="selflink" name="section-9.8" href="#section-9.8">9.8</a>. General Non-terminals</h3></span> + + These non-terminals are used at various places in the syntax and are + collected here for convenience. A few of these non-terminals are not + used in this specification but are provided for the consistency and + convenience of extension authors. + + multi-line-data-block = content-lines termination + content-lines = *([content-text] CRLF) + content-text = (".." / B-NONDOT) *B-CHAR + termination = "." CRLF + + article-number = 1*16DIGIT + header-name = 1*A-NOTCOLON + keyword = ALPHA 2*(ALPHA / DIGIT / "." / "-") + message-id = "<" 1*248A-NOTGT ">" + newsgroup-name = 1*wildmat-exact + token = 1*P-CHAR + + wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) + wildmat-pattern = 1*wildmat-item + wildmat-item = wildmat-exact / wildmat-wild + wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / + + + +<span class="grey">Feather Standards Track [Page 97]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-98" id="page-98" href="#page-98" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + UTF8-non-ascii ; exclude ! * , ? [ \ ] + wildmat-wild = "*" / "?" + + base64 = *(4base64-char) [base64-terminal] + base64-char = UPPER / LOWER / DIGIT / "+" / "/" + base64-terminal = 2base64-char "==" / 3base64-char "=" + + ; Assorted special character sets + ; A- means based on US-ASCII, 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 + ; B- means based on bytes, excluding NUL CR and LF + A-CHAR = %x21-7E + A-NOTCOLON = %x21-39 / %x3B-7E ; exclude ":" + A-NOTGT = %x21-3D / %x3F-7E ; exclude ">" + P-CHAR = A-CHAR / UTF8-non-ascii + U-CHAR = CTRL / TAB / SP / A-CHAR / UTF8-non-ascii + U-NONTAB = CTRL / SP / A-CHAR / UTF8-non-ascii + U-TEXT = P-CHAR *U-CHAR + B-CHAR = CTRL / TAB / SP / %x21-FF + B-NONDOT = CTRL / TAB / SP / %x21-2D / %x2F-FF ; exclude "." + + ALPHA = UPPER / LOWER ; use only when case-insensitive + CR = %x0D + CRLF = CR LF + CTRL = %x01-08 / %x0B-0C / %x0E-1F + DIGIT = %x30-39 + nzDIGIT = %x31-39 + EOL = *(SP / TAB) CRLF + LF = %x0A + LOWER = %x61-7A + SP = %x20 + SPA = 1*SP + TAB = %x09 + UPPER = %x41-5A + UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 + UTF8-2 = %xC2-DF UTF8-tail + UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail / + %xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail + UTF8-4 = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail / + %xF4 %x80-8F 2UTF8-tail + UTF8-tail = %x80-BF + WS = 1*(SP / TAB) + + The following non-terminals require special consideration. They + represent situations where material SHOULD be restricted to UTF-8, + but implementations MUST be able to cope with other character + encodings. Therefore, there are two sets of definitions for them. + + + +<span class="grey">Feather Standards Track [Page 98]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-99" id="page-99" href="#page-99" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Implementations MUST accept any content that meets this syntax: + + S-CHAR = %x21-FF + S-NONTAB = CTRL / SP / S-CHAR + S-TEXT = (CTRL / S-CHAR) *B-CHAR + + and MAY pass such content on unaltered. + + When generating new content or re-encoding existing content, + implementations SHOULD conform to this syntax: + + S-CHAR = P-CHAR + S-NONTAB = U-NONTAB + S-TEXT = U-TEXT + +<span class="h3"><h3><a class="selflink" name="section-9.9" href="#section-9.9">9.9</a>. Extensions and Validation</h3></span> + + The specification of a registered extension MUST include formal + syntax that defines additional forms for the following non-terminals: + + command + for each new command other than a variant of the LIST command - + the syntax of each command MUST be compatible with the definition + of <X-command>; + + command-datastream + for each new command that immediately streams data; + + command-continuation + for each new command that sends further material after the initial + command line - the syntax of each continuation MUST be exactly + what is sent to the server, including any escape mechanisms such + as "dot-stuffing"; + + initial-response-content + for each new response code that has arguments - the syntax of each + response MUST be compatible with the definition of <X-initial- + response-content>; + + multi-line-response-content + for each new response code that has a multi-line response - the + syntax MUST show the response after the lines containing the + response code and the terminating octet have been removed and any + "dot-stuffing" undone; + + capability-entry + for each new capability label - the syntax of each entry MUST be + compatible with the definition of <X-capability-entry>; + + + +<span class="grey">Feather Standards Track [Page 99]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-100" id="page-100" href="#page-100" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + list-arguments + for each new variant of the LIST command - the syntax of each + entry MUST be compatible with the definition of <X-command>; + + list-content + for each new variant of the LIST command - the syntax MUST show + the response after the lines containing the 215 response code and + the terminating octet have been removed and any "dot-stuffing" + undone. + + The =/ notation of ABNF [<a href="https://tools.ietf.org/html/rfc4234" title='"Augmented BNF for Syntax Specifications: ABNF"'>RFC4234</a>] and the naming conventions + described in <a href="#section-9.1">Section 9.1</a> SHOULD be used for this. + + When the syntax in this specification, or syntax based on it, is + validated, it should be noted that: + + o the non-terminals <command-line>, <command-datastream>, + <command-continuation>, <response>, and + <multi-line-response-content> describe basic concepts of the + protocol and are not referred to by any other rule; + + o the non-terminal <base64> is provided for the convenience of + extension authors and is not referred to by any rule in this + specification; + + o for the reasons given above, the non-terminals <S-CHAR>, + <S-NONTAB>, and <S-TEXT> each have two definitions; and + + o the non-terminal <UNDEFINED> is deliberately not defined. + +<span class="h2"><h2><a class="selflink" name="section-10" href="#section-10">10</a>. Internationalisation Considerations</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-10.1" href="#section-10.1">10.1</a>. Introduction and Historical Situation</h3></span> + + <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> [<a href="https://tools.ietf.org/html/rfc977" title='"Network News Transfer Protocol"'>RFC977</a>] was written at a time when internationalisation was + not seen as a significant issue. As such, it was written on the + assumption that all communication would be in ASCII and use only a + 7-bit transport layer, although in practice just about all known + implementations are 8-bit clean. + + Since then, Usenet and NNTP have spread throughout the world. In the + absence of standards for handling the issues of language and + character sets, countries, newsgroup hierarchies, and individuals + have found a variety of solutions that work for them but that are not + necessarily appropriate elsewhere. For example, some have adopted a + default 8-bit character set appropriate to their needs (such as + ISO/IEC 8859-1 in Western Europe or KOI-8 in Russia), others have + used ASCII (either US-ASCII or national variants) in headers but + + + +<span class="grey">Feather Standards Track [Page 100]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-101" id="page-101" href="#page-101" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + local 16-bit character sets in article bodies, and still others have + gone for a combination of MIME [<a href="https://tools.ietf.org/html/rfc2045" title='"Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"'>RFC2045</a>] and UTF-8. With the + increased use of MIME in email, it is becoming more common to find + NNTP articles containing MIME headers that identify the character set + of the body, but this is far from universal. + + The resulting confusion does not help interoperability. + + One point that has been generally accepted is that articles can + contain octets with the top bit set, and NNTP is only expected to + operate on 8-bit clean transport paths. + +<span class="h3"><h3><a class="selflink" name="section-10.2" href="#section-10.2">10.2</a>. This Specification</h3></span> + + Part of the role of this present specification is to eliminate this + confusion and promote interoperability as far as possible. At the + same time, it is necessary to accept the existence of the present + situation and not break existing implementations and arrangements + gratuitously, even if they are less than optimal. Therefore, the + current practice described above has been taken into consideration in + producing this specification. + + This specification extends NNTP from US-ASCII [<a href="#ref-ANSI1986" title='"Coded Character Set - 7-bit American Standard Code for Information Interchange"'>ANSI1986</a>] to UTF-8 + [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>]. Except in the two areas discussed below, UTF-8 (which is + a superset of US-ASCII) is mandatory, and implementations MUST NOT + use any other encoding. + + Firstly, the use of MIME for article headers and bodies is strongly + recommended. However, given widely divergent existing practices, an + attempt to require a particular encoding and tagging standard would + be premature at this time. Accordingly, this specification allows + the use of arbitrary 8-bit data in articles subject to the following + requirements and recommendations. + + o The names of headers (e.g., "From" or "Subject") MUST be in + US-ASCII. + + o Header values SHOULD use US-ASCII or an encoding based on it, such + as <a href="https://tools.ietf.org/html/rfc2047">RFC 2047</a> [<a href="https://tools.ietf.org/html/rfc2047" title='"MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text"'>RFC2047</a>], until such time as another approach has + been standardised. At present, 8-bit encodings (including UTF-8) + SHOULD NOT be used because they are likely to cause + interoperability problems. + + o The character set of article bodies SHOULD be indicated in the + article headers, and this SHOULD be done in accordance with MIME. + + o Where an article is obtained from an external source, an + implementation MAY pass it on and derive data from it (such as the + + + +<span class="grey">Feather Standards Track [Page 101]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-102" id="page-102" href="#page-102" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + response to the HDR command), even though the article or the data + does not meet the above requirements. Implementations MUST + transfer such articles and data correctly and unchanged; they MUST + NOT attempt to convert or re-encode the article or derived data. + (Nevertheless, a client or server MAY elect not to post or forward + the article if, after further examination of the article, it deems + it inappropriate to do so.) + + This requirement affects the ARTICLE (<a href="#section-6.2.1">Section 6.2.1</a>), BODY + (<a href="#section-6.2.3">Section 6.2.3</a>), HDR (<a href="#section-8.5">Section 8.5</a>), HEAD (<a href="#section-6.2.2">Section 6.2.2</a>), IHAVE + (<a href="#section-6.3.2">Section 6.3.2</a>), OVER (<a href="#section-8.3">Section 8.3</a>), and POST (<a href="#section-6.3.1">Section 6.3.1</a>) + commands. + + Secondly, the following requirements are placed on the newsgroups + list returned by the LIST NEWSGROUPS command (<a href="#section-7.6.6">Section 7.6.6</a>): + + o Although this specification allows UTF-8 for newsgroup names, they + SHOULD be restricted to US-ASCII until a successor to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> + [<a href="https://tools.ietf.org/html/rfc1036" title='"Standard for interchange of USENET messages"'>RFC1036</a>] standardises another approach. 8-bit encodings SHOULD + NOT be used because they are likely to cause interoperability + problems. + + o The newsgroup description SHOULD be in US-ASCII or UTF-8 unless + and until a successor to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> standardises other encoding + arrangements. 8-bit encodings other than UTF-8 SHOULD NOT be used + because they are likely to cause interoperability problems. + + o Implementations that obtain this data from an external source MUST + handle it correctly even if it does not meet the above + requirements. Implementations (in particular, clients) MUST + handle such data correctly. + +<span class="h3"><h3><a class="selflink" name="section-10.3" href="#section-10.3">10.3</a>. Outstanding Issues</h3></span> + + While the primary use of NNTP is for transmitting articles that + conform to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> (Netnews articles), it is also used for other + formats (see <a href="#appendix-A">Appendix A</a>). It is therefore most appropriate that + internationalisation issues related to article formats be addressed + in the relevant specifications. For Netnews articles, this is any + successor to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a>. For email messages, it is <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> [<a href="https://tools.ietf.org/html/rfc2822" title='"Internet Message Format"'>RFC2822</a>]. + + Of course, any article transmitted via NNTP needs to conform to this + specification as well. + + Restricting newsgroup names to UTF-8 is not a complete solution. In + particular, when new newsgroup names are created or a user is asked + to enter a newsgroup name, some scheme of canonicalisation will need + to take place. This specification does not attempt to define that + + + +<span class="grey">Feather Standards Track [Page 102]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-103" id="page-103" href="#page-103" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + canonicalization; further work is needed in this area, in conjunction + with the article format specifications. Until such specifications + are published, implementations SHOULD match newsgroup names octet by + octet. It is anticipated that any approved scheme will be applied + "at the edges", and therefore octet-by-octet comparison will continue + to apply to most, if not all, uses of newsgroup names in NNTP. + + In the meantime, any implementation experimenting with UTF-8 + newsgroup names is strongly cautioned that a future specification may + require that those names be canonicalized when used with NNTP in a + way that is not compatible with their experiments. + + Since the primary use of NNTP is with Netnews, and since newsgroup + descriptions are normally distributed through specially formatted + articles, it is recommended that the internationalisation issues + related to them be addressed in any successor to <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a>. + +<span class="h2"><h2><a class="selflink" name="section-11" href="#section-11">11</a>. IANA Considerations</h2></span> + + This specification requires IANA to keep a registry of capability + labels. The initial contents of this registry are specified in + <a href="#section-3.3.4">Section 3.3.4</a>. As described in <a href="#section-3.3.3">Section 3.3.3</a>, labels beginning with + X are reserved for private use, while all other names are expected to + be associated with a specification in an RFC on the standards track + or defining an IESG-approved experimental protocol. + + Different entries in the registry MUST use different capability + labels. + + Different entries in the registry MUST NOT use the same command name. + For this purpose, variants distinguished by a second or subsequent + keyword (e.g., "LIST HEADERS" and "LIST OVERVIEW.FMT") count as + different commands. If there is a need for two extensions to use the + same command, a single harmonised specification MUST be registered. + +<span class="h2"><h2><a class="selflink" name="section-12" href="#section-12">12</a>. Security Considerations</h2></span> + + This section is meant to inform application developers, information + providers, and users of the security limitations in NNTP as described + by this document. The discussion does not include definitive + solutions to the problems revealed, though it does make some + suggestions for reducing security risks. + + + + + + + + + +<span class="grey">Feather Standards Track [Page 103]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-104" id="page-104" href="#page-104" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h3"><h3><a class="selflink" name="section-12.1" href="#section-12.1">12.1</a>. Personal and Proprietary Information</h3></span> + + NNTP, because it was created to distribute network news articles, + will forward whatever information is stored in those articles. + Specification of that information is outside this scope of this + document, but it is likely that some personal and/or proprietary + information is available in some of those articles. It is very + important that designers and implementers provide informative + warnings to users so that personal and/or proprietary information in + material that is added automatically to articles (e.g., in headers) + is not disclosed inadvertently. Additionally, effective and easily + understood mechanisms to manage the distribution of news articles + SHOULD be provided to NNTP Server administrators, so that they are + able to report with confidence the likely spread of any particular + set of news articles. + +<span class="h3"><h3><a class="selflink" name="section-12.2" href="#section-12.2">12.2</a>. Abuse of Server Log Information</h3></span> + + A server is in the position to save session data about a user's + requests that might identify their reading patterns or subjects of + interest. This information is clearly confidential in nature, and + its handling can be constrained by law in certain countries. People + using this protocol to provide data are responsible for ensuring that + such material is not distributed without the permission of any + individuals that are identifiable by the published results. + +<span class="h3"><h3><a class="selflink" name="section-12.3" href="#section-12.3">12.3</a>. Weak Authentication and Access Control</h3></span> + + There is no user-based or token-based authentication in the basic + NNTP specification. Access is normally controlled by server + configuration files. Those files specify access by using domain + names or IP addresses. However, this specification does permit the + creation of extensions to NNTP for such purposes; one such extension + is [<a href="#ref-NNTP-AUTH" title='"Network News Transfer Protocol (NNTP) Extension for Authentication"'>NNTP-AUTH</a>]. While including such mechanisms is optional, doing + so is strongly encouraged. + + Other mechanisms are also available. For example, a proxy server + could be put in place that requires authentication before connecting + via the proxy to the NNTP server. + +<span class="h3"><h3><a class="selflink" name="section-12.4" href="#section-12.4">12.4</a>. DNS Spoofing</h3></span> + + Many existing NNTP implementations authorize incoming connections by + checking the IP address of that connection against the IP addresses + obtained via DNS lookups of lists of domain names given in local + configuration files. Servers that use this type of authentication + and clients that find a server by doing a DNS lookup of the server + name rely very heavily on the Domain Name Service, and are thus + + + +<span class="grey">Feather Standards Track [Page 104]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-105" id="page-105" href="#page-105" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + generally prone to security attacks based on the deliberate + misassociation of IP addresses and DNS names. Clients and servers + need to be cautious in assuming the continuing validity of an IP + number/DNS name association. + + In particular, NNTP clients and servers SHOULD rely on their name + resolver for confirmation of an IP number/DNS name association, + rather than cache the result of previous host name lookups. Many + platforms already can cache host name lookups locally when + appropriate, and they SHOULD be configured to do so. It is proper + for these lookups to be cached, however, only when the TTL (Time To + Live) information reported by the name server makes it likely that + the cached information will remain useful. + + If NNTP clients or servers cache the results of host name lookups in + order to achieve a performance improvement, they MUST observe the TTL + information reported by DNS. If NNTP clients or servers do not + observe this rule, they could be spoofed when a previously accessed + server's IP address changes. As network renumbering is expected to + become increasingly common, the possibility of this form of attack + will increase. Observing this requirement thus reduces this + potential security vulnerability. + + This requirement also improves the load-balancing behaviour of + clients for replicated servers using the same DNS name and reduces + the likelihood of a user's experiencing failure in accessing sites + that use that strategy. + +<span class="h3"><h3><a class="selflink" name="section-12.5" href="#section-12.5">12.5</a>. UTF-8 Issues</h3></span> + + UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>] permits only certain sequences of octets and + designates others as either malformed or "illegal". The Unicode + standard identifies a number of security issues related to illegal + sequences and forbids their generation by conforming implementations. + + Implementations of this specification MUST NOT generate malformed or + illegal sequences and SHOULD detect them and take some appropriate + action. This could include the following: + + o Generating a 501 response code. + + o Replacing such sequences by the sequence %xEF.BF.BD, which encodes + the "replacement character" U+FFFD. + + o Closing the connection. + + o Replacing such sequences by a "guessed" valid sequence (based on + properties of the UTF-8 encoding). + + + +<span class="grey">Feather Standards Track [Page 105]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-106" id="page-106" href="#page-106" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + In the last case, the implementation MUST ensure that any replacement + cannot be used to bypass validity or security checks. For example, + the illegal sequence %xC0.A0 is an over-long encoding for space + (%x20). If it is replaced by the correct encoding in a command line, + this needs to happen before the command line is parsed into + individual arguments. If the replacement came after parsing, it + would be possible to generate an argument with an embedded space, + which is forbidden. Use of the "replacement character" does not have + this problem, since it is permitted wherever non-US-ASCII characters + are. Implementations SHOULD use one of the first two solutions where + the general structure of the NNTP stream remains intact and SHOULD + close the connection if it is no longer possible to parse it + sensibly. + +<span class="h3"><h3><a class="selflink" name="section-12.6" href="#section-12.6">12.6</a>. Caching of Capability Lists</h3></span> + + The CAPABILITIES command provides a capability list, which is + information about the current capabilities of the server. Whenever + there is a relevant change to the server state, the results of this + command are required to change accordingly. + + In most situations, the capabilities list in a given server state + will not change from session to session; for example, a given + extension will be installed permanently on a server. Some clients + may therefore wish to remember which extensions a server supports to + avoid the delay of an additional command and response, particularly + if they open multiple connections in the same session. + + However, information about extensions related to security and privacy + MUST NOT be cached, since this could allow a variety of attacks. + + For example, consider a server that permits the use of cleartext + passwords on links that are encrypted but not otherwise: + + [Initial connection set-up completed.] + [S] 200 NNTP Service Ready, posting permitted + [<a href="#ref-C" title='"Demo User"'>C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] NEWNEWS + [S] POST + [S] XENCRYPT + [S] LIST ACTIVE NEWSGROUPS + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] XENCRYPT + [Client and server negotiate encryption on the link] + [S] 283 Encrypted link established + + + +<span class="grey">Feather Standards Track [Page 106]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-107" id="page-107" href="#page-107" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + [<a name="ref-C" id="ref-C">C</a>] CAPABILITIES + [S] 101 Capability list: + [S] VERSION 2 + [S] READER + [S] NEWNEWS + [S] POST + [S] XSECRET + [S] LIST ACTIVE NEWSGROUPS + [S] . + [<a href="#ref-C" title='"Demo User"'>C</a>] XSECRET fred flintstone + [S] 290 Password for fred accepted + + If the client caches the last capabilities list, then on the next + session it will attempt to use XSECRET on an unencrypted link: + + [Initial connection set-up completed.] + [S] 200 NNTP Service Ready, posting permitted + [<a href="#ref-C" title='"Demo User"'>C</a>] XSECRET fred flintstone + [S] 483 Only permitted on secure links + + This exposes the password to any eavesdropper. While the primary + cause of this is passing a secret without first checking the security + of the link, caching of capability lists can increase the risk. + + Any security extension should include requirements to check the + security state of the link in a manner appropriate to that extension. + + Caching should normally only be considered for anonymous clients that + do not use any security or privacy extensions and for which the time + required for an additional command and response is a noticeable + issue. + +<span class="h2"><h2><a class="selflink" name="section-13" href="#section-13">13</a>. Acknowledgements</h2></span> + + This document is the result of much effort by the present and past + members of the NNTP Working Group, chaired by Russ Allbery and Ned + Freed. It could not have been produced without them. + + The author acknowledges the original authors of NNTP as documented in + <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> [<a href="https://tools.ietf.org/html/rfc977" title='"Network News Transfer Protocol"'>RFC977</a>]: Brian Kantor and Phil Lapsey. + + The author gratefully acknowledges the following: + + o The work of the NNTP committee chaired by Eliot Lear. The + organization of this document was influenced by the last available + version from this working group. A special thanks to Eliot for + generously providing the original machine-readable sources for + that document. + + + +<span class="grey">Feather Standards Track [Page 107]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-108" id="page-108" href="#page-108" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + o The work of the DRUMS working group, specifically <a href="https://tools.ietf.org/html/rfc1869">RFC 1869</a> + [<a href="https://tools.ietf.org/html/rfc1869" title='"SMTP Service Extensions"'>RFC1869</a>], that drove the original thinking that led to the + CAPABILITIES command and the extensions mechanism detailed in this + document. + + o The authors of <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a> [<a href="https://tools.ietf.org/html/rfc2616" title='"Hypertext Transfer Protocol -- HTTP/1.1"'>RFC2616</a>] for providing specific and + relevant examples of security issues that should be considered for + HTTP. Since many of the same considerations exist for NNTP, those + examples that are relevant have been included here with some minor + rewrites. + + o The comments and additional information provided by the following + individuals in preparing one or more of the progenitors of this + document: + + Russ Allbery <rra@stanford.edu> + Wayne Davison <davison@armory.com> + Chris Lewis <clewis@bnr.ca> + Tom Limoncelli <tal@mars.superlink.net> + Eric Schnoebelen <eric@egsner.cirr.com> + Rich Salz <rsalz@osf.org> + + This work was motivated by the work of various news reader authors + and news server authors, including those listed below: + + Rick Adams + Original author of the NNTP extensions to the RN news reader and + last maintainer of Bnews. + + Stan Barber + Original author of the NNTP extensions to the news readers that + are part of Bnews. + + Geoff Collyer + Original author of the OVERVIEW database proposal and one of the + original authors of CNEWS. + + Dan Curry + Original author of the xvnews news reader. + + Wayne Davison + Author of the first threading extensions to the RN news reader + (commonly called TRN). + + Geoff Huston + Original author of ANU NEWS. + + + + + +<span class="grey">Feather Standards Track [Page 108]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-109" id="page-109" href="#page-109" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Phil Lapsey + Original author of the UNIX reference implementation for NNTP. + + Iain Lea + Original maintainer of the TIN news reader. + + Chris Lewis + First known implementer of the AUTHINFO GENERIC extension. + + Rich Salz + Original author of INN. + + Henry Spencer + One of the original authors of CNEWS. + + Kim Storm + Original author of the NN news reader. + + Other people who contributed to this document include: + + Matthias Andree + Greg Andruk + Daniel Barclay + Maurizio Codogno + Mark Crispin + Andrew Gierth + Juergen Helbing + Scott Hollenbeck + Urs Janssen + Charles Lindsey + Ade Lovett + David Magda + Ken Murchison + Francois Petillon + Peter Robinson + Rob Siemborski + Howard Swinehart + Ruud van Tol + Jeffrey Vinocur + Erik Warmelink + + The author thanks them all and apologises to anyone omitted. + + Finally, the present author gratefully acknowledges the vast amount + of work put into previous versions by the previous author: + + Stan Barber <sob@academ.com> + + + + +<span class="grey">Feather Standards Track [Page 109]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-110" id="page-110" href="#page-110" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h2"><h2><a class="selflink" name="section-14" href="#section-14">14</a>. References</h2></span> + +<span class="h3"><h3><a class="selflink" name="section-14.1" href="#section-14.1">14.1</a>. Normative References</h3></span> + + [<a name="ref-ANSI1986" id="ref-ANSI1986">ANSI1986</a>] American National Standards Institute, "Coded Character + Set - 7-bit American Standard Code for Information + Interchange", ANSI X3.4, 1986. + + [<a name="ref-RFC977" id="ref-RFC977">RFC977</a>] Kantor, B. and P. Lapsley, "Network News Transfer + Protocol", <a href="https://tools.ietf.org/html/rfc977">RFC 977</a>, February 1986. + + [<a name="ref-RFC2045" id="ref-RFC2045">RFC2045</a>] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", <a href="https://tools.ietf.org/html/rfc2045">RFC 2045</a>, November 1996. + + [<a name="ref-RFC2047" id="ref-RFC2047">RFC2047</a>] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header Extensions for + Non-ASCII Text", <a href="https://tools.ietf.org/html/rfc2047">RFC 2047</a>, November 1996. + + [<a name="ref-RFC2119" id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", <a href="https://tools.ietf.org/html/bcp14">BCP 14</a>, <a href="https://tools.ietf.org/html/rfc2119">RFC 2119</a>, March 1997. + + [<a name="ref-RFC3629" id="ref-RFC3629">RFC3629</a>] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, <a href="https://tools.ietf.org/html/rfc3629">RFC 3629</a>, November 2003. + + [<a name="ref-RFC4234" id="ref-RFC4234">RFC4234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", <a href="https://tools.ietf.org/html/rfc4234">RFC 4234</a>, October 2005. + + [<a name="ref-RFC4648" id="ref-RFC4648">RFC4648</a>] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", <a href="https://tools.ietf.org/html/rfc4648">RFC 4648</a>, October 2006. + + [<a name="ref-TF.686-1" id="ref-TF.686-1">TF.686-1</a>] International Telecommunications Union - Radio, + "Glossary, ITU-R Recommendation TF.686-1", + ITU-R Recommendation TF.686-1, October 1997. + +<span class="h3"><h3><a class="selflink" name="section-14.2" href="#section-14.2">14.2</a>. Informative References</h3></span> + + [<a name="ref-NNTP-AUTH" id="ref-NNTP-AUTH">NNTP-AUTH</a>] Vinocur, J., Murchison, K., and C. Newman, "Network + News Transfer Protocol (NNTP) Extension for + Authentication", + <a href="https://tools.ietf.org/html/rfc4643">RFC 4643</a>, October 2006. + + [<a name="ref-NNTP-STREAM" id="ref-NNTP-STREAM">NNTP-STREAM</a>] Vinocur, J. and K. Murchison, "Network News Transfer + Protocol (NNTP) Extension for Streaming Feeds", + <a href="https://tools.ietf.org/html/rfc4644">RFC 4644</a>, October 2006. + + + + + + +<span class="grey">Feather Standards Track [Page 110]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-111" id="page-111" href="#page-111" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + [<a name="ref-NNTP-TLS" id="ref-NNTP-TLS">NNTP-TLS</a>] Murchison, K., Vinocur, J., and C. Newman, "Using + Transport Layer Security (TLS) with Network News + Transfer Protocol (NNTP)", <a href="https://tools.ietf.org/html/rfc4642">RFC 4642</a>, October 2006. + + [<a name="ref-RFC1036" id="ref-RFC1036">RFC1036</a>] Horton, M. and R. Adams, "Standard for interchange of + USENET messages", <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a>, December 1987. + + [<a name="ref-RFC1305" id="ref-RFC1305">RFC1305</a>] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation and Analysis", <a href="https://tools.ietf.org/html/rfc1305">RFC 1305</a>, + March 1992. + + [<a name="ref-RFC1869" id="ref-RFC1869">RFC1869</a>] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. + Crocker, "SMTP Service Extensions", STD 10, <a href="https://tools.ietf.org/html/rfc1869">RFC 1869</a>, + November 1995. + + [<a name="ref-RFC2616" id="ref-RFC2616">RFC2616</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a>, June 1999. + + [<a name="ref-RFC2629" id="ref-RFC2629">RFC2629</a>] Rose, M., "Writing I-Ds and RFCs using XML", <a href="https://tools.ietf.org/html/rfc2629">RFC 2629</a>, + June 1999. + + [<a name="ref-RFC2822" id="ref-RFC2822">RFC2822</a>] Resnick, P., "Internet Message Format", <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a>, April + 2001. + + [<a name="ref-RFC2980" id="ref-RFC2980">RFC2980</a>] Barber, S., "Common NNTP Extensions", <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a>, October + 2000. + + [<a name="ref-ROBE1995" id="ref-ROBE1995">ROBE1995</a>] Robertson, R., "FAQ: Overview database / NOV General + Information", January 1995. + + There is no definitive copy of this document known to + the author. It was previously posted as the Usenet + article <news:nov-faq-1-930909720@agate.Berkeley.EDU> + + [<a name="ref-SALZ1992" id="ref-SALZ1992">SALZ1992</a>] Salz, R., "Manual Page for wildmat(3) from the INN 1.4 + distribution, Revision 1.10", April 1992. + + There is no definitive copy of this document known to + the author. + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 111]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-112" id="page-112" href="#page-112" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h2"><h2><a class="selflink" name="appendix-A" href="#appendix-A">Appendix A</a>. Interaction with Other Specifications</h2></span> + + NNTP is most often used for transferring articles that conform to + <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> [<a href="https://tools.ietf.org/html/rfc1036" title='"Standard for interchange of USENET messages"'>RFC1036</a>] (such articles are called "Netnews articles" + here). It is also sometimes used for transferring email messages + that conform to <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> [<a href="https://tools.ietf.org/html/rfc2822" title='"Internet Message Format"'>RFC2822</a>] (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. + +<span class="h1"><h1><a class="selflink" name="appendix-A.1" href="#appendix-A.1">A.1</a>. Header Folding</h1></span> + + NNTP allows a header line to be folded (by inserting a CRLF pair) + before any space or TAB character. + + Both email and Netnews articles are required to have at least one + octet other than space or TAB on each header line. Thus, folding can + only happen at one point in each sequence of consecutive spaces or + TABs. Netnews 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 to that in <a href="#section-9.7">Section 9.7</a>. + + + header = header-name ":" SP [header-content] CRLF + header-content = [WS] token *( [CRLF] WS token ) + +<span class="h1"><h1><a class="selflink" name="appendix-A.2" href="#appendix-A.2">A.2</a>. Message-IDs</h1></span> + + 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 merely needs to meet certain + syntactic requirements and is just a way to refer to the article. + + Because there is a significant risk that old articles will be + reinjected into the global Usenet system, <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> [<a href="https://tools.ietf.org/html/rfc1036" title='"Standard for interchange of USENET messages"'>RFC1036</a>] 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. <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> + [<a href="https://tools.ietf.org/html/rfc2822" title='"Internet Message Format"'>RFC2822</a>] has a concept of "quoted" and "escaped" characters. It + therefore considers the three message-ids: + + + +<span class="grey">Feather Standards Track [Page 112]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-113" id="page-113" href="#page-113" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + <ab.cd@example.com> + <"ab.cd"@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 that 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. Note that + <a href="https://tools.ietf.org/html/rfc1036">RFC 1036</a> [<a href="https://tools.ietf.org/html/rfc1036" title='"Standard for interchange of USENET messages"'>RFC1036</a>] never treats two different strings as being + identical. Its successor (as of the time of writing) restricts the + syntax of message-ids so that, whenever <a href="https://tools.ietf.org/html/rfc2822">RFC 2822</a> would treat two + strings as equivalent, only one of them is valid (in the above + example, only the first string is valid). + + This specification does not describe how the message-id of an article + 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 Netnews + 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 through 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 recognized as a duplicate. + + If an article does not contain a message-id that the server can + identify, it MUST synthesize one. This could, for example, be a + simple sequence number or be based on the date and time when the + article arrived. When email or Netnews articles are handled, a + Message-ID header SHOULD be added to ensure global consistency and + uniqueness. + + Note that, because the message-id might not have been derived from + the Message-ID header in the article, the following example is + legitimate (though unusual): + + + + + + + + +<span class="grey">Feather Standards Track [Page 113]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-114" id="page-114" href="#page-114" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + [<a name="ref-C" id="ref-C">C</a>] HEAD <45223423@example.com> + [S] 221 0 <45223423@example.com> + [S] Path: pathost!demo!whitehouse!not-for-mail + [S] Message-ID: <1234@example.net> + [S] From: "Demo User" <nobody@example.net> + [S] Newsgroups: misc.test + [S] Subject: I am just a test article + [S] Date: 6 Oct 1998 04:38:40 -0500 + [S] Organization: An Example Net, Uncertain, Texas + [S] . + +<span class="h1"><h1><a class="selflink" name="appendix-A.3" href="#appendix-A.3">A.3</a>. Article Posting</h1></span> + + 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 Netnews + articles). It is expected that the client will already have done any + necessary validation (or that it has in turn obtained the article + from a third party that 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 Netnews article, + and the server is expected to validate it and, if necessary, to + convert it to the right form for onward distribution. This is often + 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, to fold or limit + lines, or to process the incoming text otherwise. + + 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 + recognize the two articles as duplicates. In the case of email or + Netnews articles, therefore, the posted article SHOULD contain a + header with the 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 + recognized as identical and that the same message-id is allocated, + whether or not those contents are suitable for use as the message-id. + + + + + +<span class="grey">Feather Standards Track [Page 114]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-115" id="page-115" href="#page-115" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h2"><h2><a class="selflink" name="appendix-B" href="#appendix-B">Appendix B</a>. Summary of Commands</h2></span> + + This section contains a list of every command defined in this + document, ordered by command name and by indicating capability. + + Ordered by command name: + + +-------------------+-----------------------+---------------+ + | Command | Indicating capability | Definition | + +-------------------+-----------------------+---------------+ + | ARTICLE | READER | <a href="#section-6.2.1">Section 6.2.1</a> | + | BODY | READER | <a href="#section-6.2.3">Section 6.2.3</a> | + | CAPABILITIES | mandatory | <a href="#section-5.2">Section 5.2</a> | + | DATE | READER | <a href="#section-7.1">Section 7.1</a> | + | GROUP | READER | <a href="#section-6.1.1">Section 6.1.1</a> | + | HDR | HDR | <a href="#section-8.5">Section 8.5</a> | + | HEAD | mandatory | <a href="#section-6.2.2">Section 6.2.2</a> | + | HELP | mandatory | <a href="#section-7.2">Section 7.2</a> | + | IHAVE | IHAVE | <a href="#section-6.3.2">Section 6.3.2</a> | + | LAST | READER | <a href="#section-6.1.3">Section 6.1.3</a> | + | LIST | LIST | <a href="#section-7.6.1">Section 7.6.1</a> | + | LIST ACTIVE.TIMES | LIST | <a href="#section-7.6.4">Section 7.6.4</a> | + | LIST ACTIVE | LIST | <a href="#section-7.6.3">Section 7.6.3</a> | + | LIST DISTRIB.PATS | LIST | <a href="#section-7.6.5">Section 7.6.5</a> | + | LIST HEADERS | HDR | <a href="#section-8.6">Section 8.6</a> | + | LIST NEWSGROUPS | LIST | <a href="#section-7.6.6">Section 7.6.6</a> | + | LIST OVERVIEW.FMT | OVER | <a href="#section-8.4">Section 8.4</a> | + | LISTGROUP | READER | <a href="#section-6.1.2">Section 6.1.2</a> | + | MODE READER | MODE-READER | <a href="#section-5.3">Section 5.3</a> | + | NEWGROUPS | READER | <a href="#section-7.3">Section 7.3</a> | + | NEWNEWS | NEWNEWS | <a href="#section-7.4">Section 7.4</a> | + | NEXT | READER | <a href="#section-6.1.4">Section 6.1.4</a> | + | OVER | OVER | <a href="#section-8.3">Section 8.3</a> | + | POST | POST | <a href="#section-6.3.1">Section 6.3.1</a> | + | QUIT | mandatory | <a href="#section-5.4">Section 5.4</a> | + | STAT | mandatory | <a href="#section-6.2.4">Section 6.2.4</a> | + +-------------------+-----------------------+---------------+ + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 115]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-116" id="page-116" href="#page-116" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Ordered by indicating capability: + + +-------------------+-----------------------+---------------+ + | Command | Indicating capability | Definition | + +-------------------+-----------------------+---------------+ + | CAPABILITIES | mandatory | <a href="#section-5.2">Section 5.2</a> | + | HEAD | mandatory | <a href="#section-6.2.2">Section 6.2.2</a> | + | HELP | mandatory | <a href="#section-7.2">Section 7.2</a> | + | QUIT | mandatory | <a href="#section-5.4">Section 5.4</a> | + | STAT | mandatory | <a href="#section-6.2.4">Section 6.2.4</a> | + | HDR | HDR | <a href="#section-8.5">Section 8.5</a> | + | LIST HEADERS | HDR | <a href="#section-8.6">Section 8.6</a> | + | IHAVE | IHAVE | <a href="#section-6.3.2">Section 6.3.2</a> | + | LIST | LIST | <a href="#section-7.6.1">Section 7.6.1</a> | + | LIST ACTIVE | LIST | <a href="#section-7.6.3">Section 7.6.3</a> | + | LIST ACTIVE.TIMES | LIST | <a href="#section-7.6.4">Section 7.6.4</a> | + | LIST DISTRIB.PATS | LIST | <a href="#section-7.6.5">Section 7.6.5</a> | + | LIST NEWSGROUPS | LIST | <a href="#section-7.6.6">Section 7.6.6</a> | + | MODE READER | MODE-READER | <a href="#section-5.3">Section 5.3</a> | + | NEWNEWS | NEWNEWS | <a href="#section-7.4">Section 7.4</a> | + | OVER | OVER | <a href="#section-8.3">Section 8.3</a> | + | LIST OVERVIEW.FMT | OVER | <a href="#section-8.4">Section 8.4</a> | + | POST | POST | <a href="#section-6.3.1">Section 6.3.1</a> | + | ARTICLE | READER | <a href="#section-6.2.1">Section 6.2.1</a> | + | BODY | READER | <a href="#section-6.2.3">Section 6.2.3</a> | + | DATE | READER | <a href="#section-7.1">Section 7.1</a> | + | GROUP | READER | <a href="#section-6.1.1">Section 6.1.1</a> | + | LAST | READER | <a href="#section-6.1.3">Section 6.1.3</a> | + | LISTGROUP | READER | <a href="#section-6.1.2">Section 6.1.2</a> | + | NEWGROUPS | READER | <a href="#section-7.3">Section 7.3</a> | + | NEXT | READER | <a href="#section-6.1.4">Section 6.1.4</a> | + +-------------------+-----------------------+---------------+ + + + + + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 116]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-117" id="page-117" href="#page-117" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +<span class="h2"><h2><a class="selflink" name="appendix-C" href="#appendix-C">Appendix C</a>. Summary of Response Codes</h2></span> + + This section contains a list of every response code defined in this + document and indicates whether it is multi-line, which commands can + generate it, what arguments it has, and what its meaning is. + + Response code 100 (multi-line) + Generated by: HELP + Meaning: help text follows. + + Response code 101 (multi-line) + Generated by: CAPABILITIES + Meaning: capabilities list follows. + + Response code 111 + Generated by: DATE + 1 argument: yyyymmddhhmmss + Meaning: server date and time. + + Response code 200 + Generated by: initial connection, MODE READER + Meaning: service available, posting allowed. + + Response code 201 + Generated by: initial connection, MODE READER + Meaning: service available, posting prohibited. + + Response code 205 + Generated by: QUIT + Meaning: connection closing (the server immediately closes the + connection). + + Response code 211 + The 211 response code has two completely different forms, + depending on which command generated it: + + (not multi-line) + Generated by: GROUP + 4 arguments: number low high group + Meaning: group selected. + + (multi-line) + Generated by: LISTGROUP + 4 arguments: number low high group + Meaning: article numbers follow. + + + + + + +<span class="grey">Feather Standards Track [Page 117]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-118" id="page-118" href="#page-118" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Response code 215 (multi-line) + Generated by: LIST + Meaning: information follows. + + Response code 220 (multi-line) + Generated by: ARTICLE + 2 arguments: n message-id + Meaning: article follows. + + Response code 221 (multi-line) + Generated by: HEAD + 2 arguments: n message-id + Meaning: article headers follow. + + Response code 222 (multi-line) + Generated by: BODY + 2 arguments: n message-id + Meaning: article body follows. + + Response code 223 + Generated by: LAST, NEXT, STAT + 2 arguments: n message-id + Meaning: article exists and selected. + + Response code 224 (multi-line) + Generated by: OVER + Meaning: overview information follows. + + Response code 225 (multi-line) + Generated by: HDR + Meaning: headers follow. + + Response code 230 (multi-line) + Generated by: NEWNEWS + Meaning: list of new articles follows. + + Response code 231 (multi-line) + Generated by: NEWGROUPS + Meaning: list of new newsgroups follows. + + Response code 235 + Generated by: IHAVE (second stage) + Meaning: article transferred OK. + + Response code 240 + Generated by: POST (second stage) + Meaning: article received OK. + + + + +<span class="grey">Feather Standards Track [Page 118]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-119" id="page-119" href="#page-119" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Response code 335 + Generated by: IHAVE (first stage) + Meaning: send article to be transferred. + + Response code 340 + Generated by: POST (first stage) + Meaning: send article to be posted. + + Response code 400 + Generic response and generated by initial connection + Meaning: service not available or no longer available (the server + immediately closes the connection). + + Response code 401 + Generic response + 1 argument: capability-label + Meaning: the server is in the wrong mode; the indicated capability + should be used to change the mode. + + Response code 403 + Generic response + Meaning: internal fault or problem preventing action being taken. + + Response code 411 + Generated by: GROUP, LISTGROUP + Meaning: no such newsgroup. + + Response code 412 + Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP, + NEXT, OVER, STAT + Meaning: no newsgroup selected. + + Response code 420 + Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT + Meaning: current article number is invalid. + + Response code 421 + Generated by: NEXT + Meaning: no next article in this group. + + Response code 422 + Generated by: LAST + Meaning: no previous article in this group. + + Response code 423 + Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT + Meaning: no article with that number or in that range. + + + + +<span class="grey">Feather Standards Track [Page 119]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-120" id="page-120" href="#page-120" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Response code 430 + Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT + Meaning: no article with that message-id. + + Response code 435 + Generated by: IHAVE (first stage) + Meaning: article not wanted. + + Response code 436 + Generated by: IHAVE (either stage) + Meaning: transfer not possible (first stage) or failed (second + stage); try again later. + + Response code 437 + Generated by: IHAVE (second stage) + Meaning: transfer rejected; do not retry. + + Response code 440 + Generated by: POST (first stage) + Meaning: posting not permitted. + + Response code 441 + Generated by: POST (second stage) + Meaning: posting failed. + + Response code 480 + Generic response + Meaning: command unavailable until the client has authenticated + itself. + + Response code 483 + Generic response + Meaning: command unavailable until suitable privacy has been + arranged. + + Response code 500 + Generic response + Meaning: unknown command. + + Response code 501 + Generic response + Meaning: syntax error in command. + + + + + + + + + +<span class="grey">Feather Standards Track [Page 120]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-121" id="page-121" href="#page-121" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + Response code 502 + Generic response and generated by initial connection + + Meaning for the initial connection and the MODE READER command: + service permanently unavailable (the server immediately closes the + connection). + + Meaning for all other commands: command not permitted (and there + is no way for the client to change this). + + Response code 503 + Generic response + Meaning: feature not supported. + + Response code 504 + Generic response + Meaning: error in base64-encoding [<a href="https://tools.ietf.org/html/rfc4648" title='"The Base16, Base32, and Base64 Data Encodings"'>RFC4648</a>] of an argument. + +<span class="h2"><h2><a class="selflink" name="appendix-D" href="#appendix-D">Appendix D</a>. Changes from <a href="https://tools.ietf.org/html/rfc977">RFC 977</a></h2></span> + + In general every attempt has been made to ensure that the protocol + specification in this document is compatible with the version + specified in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> [<a href="https://tools.ietf.org/html/rfc977" title='"Network News Transfer Protocol"'>RFC977</a>] and the various facilities adopted from + <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> [<a href="https://tools.ietf.org/html/rfc2980" title='"Common NNTP Extensions"'>RFC2980</a>]. However, there have been a number of changes, + some compatible and some not. + + This appendix lists these changes. It is not guaranteed to be + exhaustive or correct and MUST NOT be relied on. + + o A formal syntax specification (<a href="#section-9">Section 9</a>) has been added. + + o The default character set is changed from US-ASCII [<a href="#ref-ANSI1986" title='"Coded Character Set - 7-bit American Standard Code for Information Interchange"'>ANSI1986</a>] to + UTF-8 [<a href="https://tools.ietf.org/html/rfc3629" title='"UTF-8, a transformation format of ISO 10646"'>RFC3629</a>] (note that US-ASCII is a subset of UTF-8). This + matter is discussed further in <a href="#section-10">Section 10</a>. + + o All articles are required to have a message-id, eliminating the + "<0>" placeholder used in <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> in some responses. + + o The newsgroup name matching capabilities already documented in + <a href="https://tools.ietf.org/html/rfc977">RFC 977</a> ("wildmats", <a href="#section-4">Section 4</a>) are clarified and extended. The + new facilities (e.g., the use of commas and exclamation marks) are + allowed wherever wildmats appear in the protocol. + + o Support for pipelining of commands (<a href="#section-3.5">Section 3.5</a>) is made + mandatory. + + + + + + +<span class="grey">Feather Standards Track [Page 121]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-122" id="page-122" href="#page-122" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + o The principles behind response codes (<a href="#section-3.2">Section 3.2</a>) have been + tidied up. In particular: + + * the x8x response code family, formerly used for private + extensions, is now reserved for authentication and privacy + extensions; + + * the x9x response code family, formerly intended for debugging + facilities, are now reserved for private extensions; + + * the 502 and 503 generic response codes (<a href="#section-3.2.1">Section 3.2.1</a>) have + been redefined; + + * new 401, 403, 480, 483, and 504 generic response codes have + been added. + + o The rules for article numbering (<a href="#section-6">Section 6</a>) have been clarified + (also see <a href="#section-6.1.1.2">Section 6.1.1.2</a>). + + o The SLAVE command (which was ill-defined) is removed from the + protocol. + + o Four-digit years are permitted in the NEWNEWS (<a href="#section-7.4">Section 7.4</a>) and + NEWGROUPS (<a href="#section-7.3">Section 7.3</a>) commands (two-digit years are still + permitted). The optional distribution parameter to these commands + has been removed. + + o The LIST command (<a href="#section-7.6.1">Section 7.6.1</a>) is greatly extended; the original + is available as LIST ACTIVE, while new variants include + ACTIVE.TIMES, DISTRIB.PATS, and NEWSGROUPS. A new "m" status flag + is added to the LIST ACTIVE response. + + o A new CAPABILITIES command (<a href="#section-5.2">Section 5.2</a>) allows clients to + determine what facilities are supported by a server. + + o The DATE command (<a href="#section-7.1">Section 7.1</a>) is adopted from <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> + effectively unchanged. + + o The LISTGROUP command (<a href="#section-6.1.2">Section 6.1.2</a>) is adopted from <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a>. + An optional range argument has been added, and the 211 initial + response line now has the same format as the 211 response from the + GROUP command. + + o The MODE READER command (<a href="#section-5.3">Section 5.3</a>) is adopted from <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> and + its meaning and effects clarified. + + o The XHDR command in <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> has been formalised as the new HDR + (<a href="#section-8.5">Section 8.5</a>) and LIST HEADERS (<a href="#section-8.6">Section 8.6</a>) commands. + + + +<span class="grey">Feather Standards Track [Page 122]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-123" id="page-123" href="#page-123" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + + o The XOVER command in <a href="https://tools.ietf.org/html/rfc2980">RFC 2980</a> has been formalised as the new OVER + (<a href="#section-8.3">Section 8.3</a>) and LIST OVERVIEW.FMT (<a href="#section-8.4">Section 8.4</a>) commands. The + former can be applied to a message-id as well as to a range. + + o The concept of article metadata (<a href="#section-8.1">Section 8.1</a>) has been formalised, + allowing the Bytes and Lines pseudo-headers to be deprecated. + + Client authors should note in particular that lack of support for the + CAPABILITIES command is a good indication that the server does not + support this specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 123]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-124" id="page-124" href="#page-124" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +Author's Address + + Clive D.W. Feather + THUS plc + 322 Regents Park Road + London + N3 2QQ + United Kingdom + + Phone: +44 20 8495 6138 + Fax: +44 870 051 9937 + EMail: clive@demon.net + URI: <a href="http://www.davros.org/">http://www.davros.org/</a> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<span class="grey">Feather Standards Track [Page 124]</span> +</pre><!--NewPage--><pre class="newpage"><a name="page-125" id="page-125" href="#page-125" class="invisible"> </a> +<span class="grey"><a href="#">RFC 3977</a> Network News Transfer Protocol (NNTP) October 2006</span> + + +Full Copyright Statement + +Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in <a href="https://tools.ietf.org/html/bcp78">BCP 78</a>, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in <a href="https://tools.ietf.org/html/bcp78">BCP 78</a> and <a href="https://tools.ietf.org/html/bcp79">BCP 79</a>. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Feather Standards Track [Page 125] + +</pre><br> +<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.109, available from +<a href="https://tools.ietf.org/tools/rfcmarkup/">https://tools.ietf.org/tools/rfcmarkup/</a> +</small></small></span> + +</body></html>
\ No newline at end of file |