File: rfc2980.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1515 lines) | stat: -rw-r--r-- 57,165 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515






Network Working Group                                          S. Barber
Request for Comments: 2980                    Academ Consulting Services
Category: Informational                                     October 2000


                         Common NNTP Extensions

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   In this document, a number of popular extensions to the Network News
   Transfer Protocol (NNTP) protocol defined in RFC 977 are documented
   and discussed.  While this document is not intended to serve as a
   standard of any kind, it will hopefully serve as a reference document
   for future implementers of the NNTP protocol.  In the role, this
   document would hopefully create the possibility for some level of
   interoperability among implementations that make use of extensions.

Introduction

   RFC 977 [1] defines the NNTP protocol and  was released over a decade
   ago.  Since then, NNTP has become one of the most popular protocols
   in use on the Internet.  Many implementations of the protocol have
   been created on many different platforms and operating systems.  With
   the growth in use of the protocol, work began on a revision to NNTP
   in 1991, but that work did not result in a new standard protocol
   specification.  However, many ideas from that working group did find
   their way into many implementations of NNTP.  Additionally, many
   other extensions, often created by newsreader authors, are also in
   use.  This document will capture and define all known extensions to
   NNTP available in official NNTP server releases of some type as of
   this writing.  Where possible, the server software first implementing
   a particular extension will be noted.  It is the hope of the author
   that using this document in tandem with RFC 977 will limit the
   addition of new extensions that essentially do the same thing.
   Software developers may wish to use this document and others [2] as a
   resource for the  development of new software.





Barber                       Informational                      [Page 1]

RFC 2980                 Common NNTP Extensions             October 2000


   This document does not specify an Internet Standard of any kind.  It
   only attempts to document current practices.  While this document may
   clarify some ambiguity in RFC 977, RFC 977 should be regarded as
   authoritative in all cases.  There are some implementations that are
   not strictly RFC 977 compliant and where necessary, these deviations
   from the standard will be noted.  This document does reflect the work
   of the IETF NNTP-EXT working group chaired by Ned Freed and Stan
   Barber.

   This document is provided to help implementers have a uniform source
   of information about extensions, however, it is important for any
   prospective implementer to understand that the extensions listed here
   are NOT part of any current standard for NNTP.  In fact, some of the
   ones listed in this document should not be included in new NNTP
   implementations as they should no longer be used modern NNTP
   environments.  Such commands should be considered historic and are
   documented as such in this document.

   Extensions fall into three categories: transport, newsreader and
   other.  Transport extensions are additions to the NNTP specification
   that were made specifically to move news articles from one server to
   another server.  Newsreader extensions are additions to the NNTP
   specification that were made to assist NNTP clients in selecting and
   retrieving news articles from servers.  Other extensions to the NNTP
   specification are those which did not specifically fall into either
   of the other two categories.  Examples of other extensions include
   authentication and time-of-day extensions.  For each command, the
   format of section 3 of RFC 977 will be used.

1. Transport Extensions

   A transport extension is one which is primarily used in inter-server
   communications.  Following are the descriptions of each transport
   extension commands and the responses which will be returned by those
   commands.

   Each command is shown in upper case for clarity, although case is
   ignored in the interpretation of commands by the NNTP server.  Any
   parameters are shown in lower case.  A parameter shown in [square
   brackets] is optional.  For example, [GMT] indicates that the
   triglyph GMT may present or omitted.  A parameter that may be
   repeated is followed by an ellipsis.









Barber                       Informational                      [Page 2]

RFC 2980                 Common NNTP Extensions             October 2000


1.1.1  The CHECK command

   CHECK <message-id>

   CHECK is used by a peer to discover if the article with the specified
   message-id should be sent to the server using the TAKETHIS command.
   The peer does not have to wait for a response from the server before
   sending the next command.

   From using the responses to the sequence of CHECK commands, a list of
   articles to be sent can be constructed for subsequent use by the
   TAKETHIS command.

   The use of the CHECK command for streaming is optional.  Some
   implementations will directly use the TAKETHIS command and send all
   articles in the send queue on that peer for the server.

   On some implementations, the use of the CHECK command is not
   permitted when the server is in slave mode (via the SLAVE command).

   Responses that are of the form X3X must specify the message-id in the
   response.

1.1.2.  Responses

      238 no such article found, please send it to me
      400 not accepting articles
      431 try sending it again later
      438 already have it, please don't send it to me
      480 Transfer permission denied
      500 Command not understood

1.2.1  The MODE STREAM command

   MODE STREAM

   MODE STREAM is used by a peer to indicate to the server that it would
   like to suspend the lock step conversational nature of NNTP and send
   commands in streams.  This command should be used before TAKETHIS and
   CHECK.  See the section on the commands TAKETHIS and CHECK for more
   details.

1.2.2.  Responses

      203 Streaming is OK
      500 Command not understood





Barber                       Informational                      [Page 3]

RFC 2980                 Common NNTP Extensions             October 2000


1.3.1  The TAKETHIS command

   TAKETHIS <message-id>

   TAKETHIS is used to send articles to a server when in streaming mode.
   The entire article (header and body, in that sequence) is sent
   immediately after the peer sends the TAKETHIS command.  The peer does
   not have to wait for a response from the server before sending the
   next command and the associated article.

   During transmission of the article, the peer should send the entire
   article, including header and body, in the manner specified for text
   transmission from the server.  See RFC 977, Section 2.4.1 for
   details.

   Responses that are of the form X3X must specify the message-id in the
   response.

1.3.2.  Responses

      239 article transferred ok
      400 not accepting articles
      439 article transfer failed
      480 Transfer permission denied
      500 Command not understood

1.4.1  The XREPLIC command

   XREPLIC ggg:nnn[,ggg:nnn...]

   The XREPLIC command makes is possible to exactly duplicate the news
   spool structure of one server in another server.  It first appeared
   in INN.

   This command works similarly to the IHAVE command as specified in RFC
   977.  The same response codes are used.  The command line arguments
   consist of entries separated by a single comma.  Each entry consists
   of a news group name, a colon, and an article number.  If the server
   responds with a 335 response, the article should be filed in the news
   group(s) and article number(s) specified in the XREPLIC command line.
   If the server cannot do successfully install the article once it has
   accepted it, a 436 or 437 response code can be used to indicate the
   failure.

   This command should only be used when the receiving server is being
   fed by only one other server.  It is likely that when used with
   servers that have multiple feeds that this command will frequently
   fail.



Barber                       Informational                      [Page 4]

RFC 2980                 Common NNTP Extensions             October 2000


   XREPLIC slaving has been deprecated in INN version 1.7.2 and later.
   INN now has the ability to slave servers via transparent means,
   simply by having the article's Xref header transferred.  (In previous
   versions, this header was generated locally and stripped off on
   outgoing feeds.)

   It is likely that future versions of INN will no longer support
   XREPLIC.

1.4.2.  Responses

      235 article transferred ok
      335 send article to be transferred.  End with <CR-LF>.<CR-LF>
      435 article not wanted - do not send it
      436 transfer failed - try again later
      437 article rejected - do not try again

2. Newsreader Extensions

   Newsreader extensions are those which are primarily used by
   newsreading clients.  Following are the descriptions of each
   newsreader extension commands and the responses which will be
   returned by those commands.

   Each command is shown in upper case for clarity, although case is
   ignored in the interpretation of commands by the NNTP server.  Any
   parameters are shown in lower case.  A parameter shown in [square
   brackets] is optional.  For example, [GMT] indicates that the
   triglyph GMT may present or omitted.  A parameter that may be
   repeated is followed by an ellipsis.  Mutually exclusive parameters
   are separated by a vertical bar (|) character.  For example,
   ggg|<message-id> indicates that  a group name or a <message-id> may
   be specified, but not both.  Some parameters, notably <message-id>,
   is case specific.  See RFC 1036 for these details.

   Also, certain commands make use of a pattern for selection of
   multiple news groups.  The pattern in all cases is based on the
   wildmat [4] format introduced by Rich Salz in 1986.  Arguments
   expected to be in wildmat format will be represented by the string
   wildmat.  This format is discussed in detail in section 3.3 of this
   document.

2.1.1 Extensions to the LIST command

   The original LIST command took no arguments in RFC 977 and returned
   the contents of the active file in a specific format.  Since the
   original newsreaders made use of other information available in the
   news transport software in addition to the active file, extensions to



Barber                       Informational                      [Page 5]

RFC 2980                 Common NNTP Extensions             October 2000


   the LIST command were created to make that information available to
   NNTP newsreaders.  There may be other extensions to the LIST command
   that simply return the contents of a file.  This approach is
   suggested over the addition of over verbs.  For example, LIST MOTD
   could be used instead of adding XMOTD.

2.1.2 LIST ACTIVE

   LIST ACTIVE [wildmat]

   LIST ACTIVE is exactly the same as the LIST command specified in RFC
   977.  The responses and the format should exactly match the LIST
   command without arguments.  If the optional matching parameter is
   specified, the list is limited to only the groups that match the
   pattern.  Specifying a single group is usually very efficient for the
   server, and multiple groups may be specified by using wildmat
   patterns (described later in this document), not regular expressions.
   If nothing is matched an empty list is returned, not an error.  This
   command first appeared in the UNIX reference version.

2.1.3 LIST ACTIVE.TIMES

   LIST ACTIVE.TIMES

   The active.times file is maintained by some news transports systems
   to contain information about the when and who created a particular
   news group.  The format of this file generally include three fields.
   The first field is the name of the news group.  The second is the
   time when this group was created on this news server measured in
   seconds since January 1, 1970.  The third is the email address of the
   entity that created the news group.  When executed, the information
   is displayed following the 215 response.  When display is completed,
   the server will send a period on a line by itself.  If the
   information is not available, the server will return the 503 error
   response.  This command first appeared in the UNIX reference version.

2.1.3.1 Responses

      215 information follows
      503 program error, function not performed

2.1.4 LIST DISTRIBUTIONS

   LIST DISTRIBUTIONS

   The distributions file is maintained by some news transport systems
   to contain information about valid values for the Distribution: line
   in a news article header and about what the values mean.  Each line



Barber                       Informational                      [Page 6]

RFC 2980                 Common NNTP Extensions             October 2000


   contains two fields, the value and a short explanation on the meaning
   of the value.  When executed, the information is displayed following
   the 215 response.  When display is completed, the server will send a
   period on a line by itself.  If the information is not available, the
   server will return the 503 error response.  This command first
   appeared in the UNIX reference version.

2.1.4.1 Responses

      215 information follows
      503 program error, function not performed

2.1.5 LIST DISTRIB.PATS

   LIST DISTRIB.PATS

   The distrib.pats file is maintained by some news transport systems to
   contain default values for the Distribution:  line in a news article
   header when posting to particular news groups.  This information
   could be used to provide a default value for the Distribution: line
   in the header when posting an article.  The information returned
   involves three fields separated by colons.  The first column is a
   weight.  The second is a group name or a pattern that can be used to
   match a group name in the wildmat format.  The third is the value of
   the Distribution:  line that should be used when the group name
   matches and the weight value is the highest.  All this processing is
   done by the news posting client and not by the server itself.  The
   server just provides this information to the client for it to use or
   ignore as it chooses.  When executed, the information is displayed
   following the 215 response.  When display is completed, the server
   will send a period on a line by itself.  If the information is not
   available, the server will return the 503 error response.  This
   command first appeared in INN.

2.1.5.1 Responses

      215 information follows
      503 program error, function not performed

2.1.6 LIST NEWSGROUPS

   LIST NEWSGROUPS [wildmat]

   The newsgroups file is maintained by some news transport systems to
   contain the name of each news group which is active on the server and
   a short description about the purpose of each news group.  Each line
   in the file contains two fields, the news group name and a short
   explanation of the purpose of that news group.  When executed, the



Barber                       Informational                      [Page 7]

RFC 2980                 Common NNTP Extensions             October 2000


   information is displayed following the 215 response.  When display is
   completed, the server will send a period on a line by itself.  If the
   information is not available, the server will return the 503
   response.  If the optional matching parameter is specified, the list
   is limited to only the groups that match the pattern (no matching is
   done on the group descriptions).  Specifying a single group is
   usually very efficient for the server, and multiple groups may be
   specified by using wildmat patterns (similar to file globbing), not
   regular expressions.  If nothing is matched an empty list is
   returned, not an error.

   When the optional parameter is specified, this command is equivalent
   to the XGTITLE command, though the response code are different.

      215 information follows
      503 program error, function not performed

2.1.7 LIST OVERVIEW.FMT

   LIST OVERVIEW.FMT

   The overview.fmt file is maintained by some news transport systems to
   contain the order in which header information is stored in the
   overview databases for each news group.  When executed, news article
   header fields are displayed one line at a time in the order in which
   they are stored in the overview database [5] following the 215
   response.  When display is completed, the server will send a period
   on a line by itself.  If the information is not available, the server
   will return the 503 response.

   Please note that if the header has the word "full" (without quotes)
   after the colon, the header's name is prepended to its field in the
   output returned by the server.

   Many newsreaders work better if Xref: is one of the optional fields.

   It is STRONGLY recommended that this command be implemented in any
   server that implements the XOVER command.  See section 2.8 for more
   details about the XOVER command.

2.1.7.1 Responses

      215 information follows
      503 program error, function not performed







Barber                       Informational                      [Page 8]

RFC 2980                 Common NNTP Extensions             October 2000


2.1.8 LIST SUBSCRIPTIONS

   LIST SUBSCRIPTIONS

   This command is used to get a default subscription list for new users
   of this server.  The order of groups is significant.

   When this list is available, it is preceded by the 215 response and
   followed by a period on a line by itself.  When this list is not
   available, the server returns a 503 response code.

2.1.8.1 Responses

      215 information follows
      503 program error, function not performed

2.2 LISTGROUP

   LISTGROUP [ggg]

   The LISTGROUP command is used to get a listing of all the article
   numbers in a particular news group.

   The optional parameter ggg is the name of the news group to be
   selected (e.g. "news.software.b").  A list of valid news groups may
   be obtained from the LIST command.  If no group is specified, the
   current group is used as the default argument.

   The successful selection response will be a list of the article
   numbers in the group followed by a period on a line by itself.

   When a valid group is selected by means of this command, the
   internally maintained "current article pointer" is set to the first
   article in the group.  If an invalid group is specified, the
   previously selected group and article remain selected.  If an empty
   news group is selected, the "current article pointer" is in an
   indeterminate state and should not be used.

   Note that the name of the news group is not case-dependent.  It must
   otherwise match a news group obtained from the LIST command or an
   error will result.

2.2.1  Responses

      211 list of article numbers follow
      412 Not currently in newsgroup
      502 no permission




Barber                       Informational                      [Page 9]

RFC 2980                 Common NNTP Extensions             October 2000


2.3 MODE READER

   MODE READER is used by the client to indicate to the server that it
   is a news reading client.  Some implementations make use of this
   information to reconfigure themselves for better performance in
   responding to news reader commands.  This command can be contrasted
   with the SLAVE command in RFC 977, which was not widely implemented.
   MODE READER was first available in INN.

2.3.1 Responses

      200 Hello, you can post
      201 Hello, you can't post

2.4 XGTITLE

   XGTITLE [wildmat]

   The XGTITLE command is used to retrieve news group descriptions for
   specific news groups.

   This extension first appeared in ANU-NEWS, an NNTP implementation for
   DEC's VMS.  The optional parameter is a pattern in wildmat format.
   When executed, a 282 response is given followed by lines that have
   two fields, the news group name (which matches the pattern in the
   argument) and a short explanation of the purpose of the news group.
   When no argument is specified, the default argument is the current
   group name.  When display is completed, the server sends a period on
   a line by itself.

   Please note that this command and the LIST NEWSGROUP command provide
   the same functionality with different response codes.

   Since this command provides the same functionality as LIST NEWSGROUP
   it is suggested that this extension be deprecated and no longer be
   used in newsreading clients.

   Note that there is a conflict in one of the response codes from
   XGTITLE and some of the authentication extensions.

2.5.1 Responses

      481 Groups and descriptions unavailable
      282 list of groups and descriptions follows







Barber                       Informational                     [Page 10]

RFC 2980                 Common NNTP Extensions             October 2000


2.6 XHDR

   XHDR header [range|<message-id>]

   The XHDR command is used to retrieve specific headers from specific
   articles.

   The required parameter is the name of a header line (e.g.  "subject")
   in a news group article.  See RFC 1036 for a list of valid header
   lines.  The optional range argument may be any of the following:

               an article number
               an article number followed by a dash to indicate
                  all following
               an article number followed by a dash followed by
                  another article number

   The optional message-id argument indicates a specific article.  The
   range and message-id arguments are mutually exclusive.  If no
   argument is specified, then information from the current article is
   displayed.  Successful responses start with a 221 response followed
   by a the matched headers from all matched messages.  Each line
   containing matched headers returned by the server has an article
   number (or message ID, if a message ID was specified in the command),
   then one or more spaces, then the value of the requested header in
   that article.  Once the output is complete, a period is sent on a
   line by itself.  If the optional argument is a message-id and no such
   article exists, the 430 error response is returned.  If a range is
   specified, a news group must have been selected earlier, else a 412
   error response is returned.  If no articles are in the range
   specified, a 420 error response is returned by the server.  A 502
   response will be returned if the client only has permission to
   transfer articles.

   Some implementations will return "(none)" followed by a period on a
   line by itself if no headers match in any of the articles searched.
   Others return the 221 response code followed by a period on a line by
   itself.

   The XHDR command has been available in the UNIX reference
   implementation from its first release.  However, until now, it has
   been documented only in the source for the server.









Barber                       Informational                     [Page 11]

RFC 2980                 Common NNTP Extensions             October 2000


2.6.1 Responses

      221 Header follows
      412 No news group current selected
      420 No current article selected
      430 no such article
      502 no permission

2.7 XINDEX

   XINDEX ggg

   The XINDEX command is used to retrieve an index file in the format of
   originally created for use by the TIN [6] news reader.

   The required parameter ggg is the name of the news group to be
   selected (e.g. "news.software.b").  A list of valid news groups may
   be obtained from the LIST command.

   The successful selection response will return index file in the
   format used by the TIN news reader followed by a period on a line by
   itself.

   When a valid group is selected by means of this command, the
   internally maintained "current article pointer" is set to the first
   article in the group.  If an invalid group is specified, the
   previously selected group and article remain selected.  If an empty
   news group is selected, the "current article pointer" is in an
   indeterminate state and should not be used.

   Note that the name of the news group is not case-dependent.  It must
   otherwise match a news group obtained from the LIST command or an
   error will result.

   The format of the tin-style index file is discussed in the
   documentation for the TIN newsreader.  Since more recent versions of
   TIN support the news overview (NOV) format, it is recommended that
   this extension become historic and no longer be used in current
   servers or future implementations.

2.7.1 Responses

      218 tin-style index follows
      418 no tin-style index is available for this news group







Barber                       Informational                     [Page 12]

RFC 2980                 Common NNTP Extensions             October 2000


2.8 XOVER

   XOVER [range]

   The XOVER command returns information from the overview database for
   the article(s) specified.  This command was originally suggested as
   part of the OVERVIEW work described in "The Design of a Common
   Newsgroup Overview Database for Newsreaders" by Geoff Collyer.  This
   document is distributed in the Cnews distribution.  The optional
   range argument may be any of the following:

               an article number
               an article number followed by a dash to indicate
                  all following
               an article number followed by a dash followed by
                  another article number

   If no argument is specified, then information from the current
   article is displayed.  Successful responses start with a 224 response
   followed by the overview information for all matched messages.  Once
   the output is complete, a period is sent on a line by itself.  If no
   argument is specified, the information for the current article is
   returned.  A news group must have been selected earlier, else a 412
   error response is returned.  If no articles are in the range
   specified, a 420 error response is returned by the server.  A 502
   response will be returned if the client only has permission to
   transfer articles.

   Each line of output will be formatted with the article number,
   followed by each of the headers in the overview database or the
   article itself (when the data is not available in the overview
   database) for that article separated by a tab character.  The
   sequence of fields must be in this order: subject, author, date,
   message-id, references, byte count, and line count.  Other optional
   fields may follow line count.  Other optional fields may follow line
   count.  These fields are specified by examining the response to the
   LIST OVERVIEW.FMT command.  Where no data exists, a null field must
   be provided (i.e. the output will have two tab characters adjacent to
   each other).  Servers should not output fields for articles that have
   been removed since the XOVER database was created.

   The LIST OVERVIEW.FMT command should be implemented if XOVER is
   implemented.  A client can use LIST OVERVIEW.FMT to determine what
   optional fields  and in which order all fields will be supplied by
   the XOVER command.  See Section 2.1.7 for more details about the LIST
   OVERVIEW.FMT command.





Barber                       Informational                     [Page 13]

RFC 2980                 Common NNTP Extensions             October 2000


   Note that any tab and end-of-line characters in any header data that
   is returned will be converted to a space character.

2.8.1 Responses

      224 Overview information follows
      412 No news group current selected
      420 No article(s) selected
      502 no permission

2.9 XPAT

   XPAT header range|<message-id> pat [pat...]

   The XPAT command is used to retrieve specific headers from specific
   articles, based on pattern matching on the contents of the header.
   This command was first available in INN.

   The required header parameter is the name of a header line (e.g.
   "subject") in a news group article.  See RFC 1036 for a list of valid
   header lines.  The required range argument may be any of the
   following:

               an article number
               an article number followed by a dash to indicate
                  all following
               an article number followed by a dash followed by
                  another article number

   The required message-id argument indicates a specific article.  The
   range and message-id arguments are mutually exclusive.  At least one
   pattern in wildmat must be specified as well.  If there are
   additional arguments the are joined together separated by a single
   space to form one complete pattern.  Successful responses start with
   a 221 response followed by a the headers from all messages in which
   the pattern matched the contents of the specified header line.  This
   includes an empty list.  Once the output is complete, a period is
   sent on a line by itself.  If the optional argument is a message-id
   and no such article exists, the 430 error response is returned.  A
   502 response will be returned if the client only has permission to
   transfer articles.

2.9.1 Responses

      221 Header follows
      430 no such article
      502 no permission




Barber                       Informational                     [Page 14]

RFC 2980                 Common NNTP Extensions             October 2000


2.10 The XPATH command

   XPATH <message-id>

   The XPATH command is used to determine the filenames in which an
   article is filed.  It first appeared in INN.

   The required parameter message-id is the message id of an article as
   shown in that article's message-id header.  According to RFC 1036
   [3], all message ids for all articles within the netnews environment
   are unique, but articles may be crossposted to multiple groups.  The
   response to an XPATH command will include a listing of all filenames
   in which an article is stored separated by spaces or a response
   indicating that no article with the specified message-id exists.  The
   returned data is only useful if the news client knows the
   implementation details of the server.  Because of this, it is
   recommended that client avoid using this command.

2.10.1  Responses

      223 path1[ path2 ...]
      430 no such article on server

2.11 The XROVER command

   XROVER [range]

   The XROVER command returns reference information from the overview
   database for the article(s) specified.  This command first appeared
   in the Unix reference implementation.  The optional range argument
   may be any of the following:

               an article number
               an article number followed by a dash to indicate
                    all following
               an article number followed by a dash followed by
                   another article number

   Successful responses start with a 224 response followed by the
   contents of reference information for all matched messages.  Once the
   output is complete, a period is sent on a line by itself.  If no
   argument is specified, the information for the current article is
   returned.  A news group must have been selected earlier, else a 412
   error response is returned.  If no articles are in the range
   specified, a 420 error response is returned by the server.  A 502
   response will be returned if the client only has permission to
   transfer articles.




Barber                       Informational                     [Page 15]

RFC 2980                 Common NNTP Extensions             October 2000


   The output will be formatted with the article number, followed by the
   contents of the References: line for that article, but does not
   contain the field name itself.

   This command provides the same basic functionality as using the XHDR
   command and "references" as the header argument.

2.11.1 Responses

      224 Overview information follows
      412 No news group current selected
      420 No article(s) selected
      502 no permission

2.12 XTHREAD

   XTHREAD [DBINIT|THREAD]

   The XTHREAD command is used to retrieve threading information
   in format of originally created for use by the TRN [6] news
   reader.

   The command XTHREAD DBINIT may be issued prior to entering
   any groups to see if a thread database exists.  If it does,
   the database's byte order and version number are returned
   as binary data.

   If no parameter is given, XTHREAD THREAD is assumed.

   To use XTHREAD THREAD, a news group must have been selected
   earlier, else a 412 error response is returned.

   A 502 response will be returned if the client only has
   permission to transfer articles.  A 503 response is returned
   if the threading files are not available.

   The format of the trn-style thread format is discussed in
   the documentation for the TRN newsreader.  Since more recent
   versions of TRN support the news overview (NOV) format, it
   is recommended that this extension become historic and no
   longer be used in current servers or future implementations.

2.12.1 Responses

      288 Binary data to follow
      412 No newsgroup current selected
      502 No permission
      503 program error, function not performed



Barber                       Informational                     [Page 16]

RFC 2980                 Common NNTP Extensions             October 2000


3. Other Extensions

3.1 AUTHINFO

   AUTHINFO is used to inform a server about the identity of a user of
   the server.  In all cases, clients must provide this information when
   requested by the server.  Servers are not required to accept
   authentication information that is volunteered by the client.
   Clients must accommodate servers that reject any authentication
   information volunteered by the client.

   There are three forms of AUTHINFO in use.  The original version, an
   NNTP v2 revision called AUTHINFO SIMPLE and a more recent version
   which is called AUTHINFO GENERIC.

3.1.1 Original AUTHINFO

   AUTHINFO USER username
   AUTHINFO PASS password

   The original AUTHINFO is used to identify a specific entity to the
   server using a simple username/password combination.  It first
   appeared in the UNIX reference implementation.

   When authorization is required, the server will send a 480 response
   requesting authorization from the client.  The client must enter
   AUTHINFO USER followed by the username.  Once sent, the server will
   cache the username and may send a 381 response requesting the
   password associated with that username.  Should the server request a
   password using the 381 response, the client must enter AUTHINFO PASS
   followed by a password and the server will then check the
   authentication database to see if the username/password combination
   is valid.  If the combination is valid or if no password is required,
   the server will return a 281 response.  The client should then retry
   the original command to which the server responded with the 480
   response.  The command should then be processed by the server
   normally.  If the combination is not valid, the server will return a
   502 response.

   Clients must provide authentication when requested by the server.  It
   is possible that some implementations will accept authentication
   information at the beginning of a session, but this was not the
   original intent of the specification.  If a client attempts to
   reauthenticate, the server may return 482 response indicating that
   the new authentication data is rejected by the server.  The 482 code
   will also be returned when the AUTHINFO commands are not entered in
   the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO
   PASS preceding AUTHINFO USER).



Barber                       Informational                     [Page 17]

RFC 2980                 Common NNTP Extensions             October 2000


   All information is passed in cleartext.

   When authentication succeeds, the server will create an email address
   for the client from the user name supplied in the AUTHINFO USER
   command and the hostname generated by a reverse lookup on the IP
   address of the client.  If the reverse lookup fails, the IP address,
   represented in dotted-quad format, will be used.  Once authenticated,
   the server shall generate a Sender:  line using the email address
   provided by authentication if it does not match the client-supplied
   From: line.  Additionally, the server should log the event, including
   the email address.  This will provide a means by which subsequent
   statistics generation can associate newsgroup references with unique
   entities - not necessarily by name.

3.1.1.1 Responses

      281 Authentication accepted
      381 More authentication information required
      480 Authentication required
      482 Authentication rejected
      502 No permission

3.1.2 AUTHINFO SIMPLE

   AUTHINFO SIMPLE
   user password

   This version of AUTHINFO was part of a proposed NNTP V2
   specification, which was started in 1991 but never completed, and is
   implemented in some servers and clients.  It is a refinement of the
   original AUTHINFO and provides the same basic functionality, but the
   sequence of commands is much simpler.

   When authorization is required, the server sends a 450 response
   requesting authorization from the client.  The client must enter
   AUTHINFO SIMPLE.  If the server will accept this form of
   authentication, the server responds with a 350 response.  The client
   must then send the username followed by one or more space characters
   followed by the password.  If accepted, the server returns a 250
   response and the client should then retry the original command to
   which the server responded with the 450 response.  The command should
   then be processed by the server normally.  If the combination is not
   valid, the server will return a 452 response.

   Note that the response codes used here were part of the proposed NNTP
   V2 specification and are violations of RFC 977.  It is recommended
   that this command not be implemented, but use either or both of the
   other forms of AUTHINFO if such functionality if required.



Barber                       Informational                     [Page 18]

RFC 2980                 Common NNTP Extensions             October 2000


3.1.2.1 Responses

      250 Authorization accepted
      350 Continue with authorization sequence
      450 Authorization required for this command
      452 Authorization rejected

3.1.3 AUTHINFO GENERIC

   AUTHINFO GENERIC authenticator arguments...

   AUTHINFO GENERIC is used to identify a specific entity to the server
   using arbitrary authentication  or identification protocols.  The
   desired protocol is indicated by the authenticator parameter, and any
   number of parameters can be passed to the authenticator.

   When authorization is required, the server will send a 480 response
   requesting authorization from the client.  The client should enter
   AUTHINFO GENERIC followed by the authenticator name, and the
   arguments if any.  The authenticator and arguments must not contain
   the sequence "..".

   The server will attempt to engage the server end authenticator,
   similarly, the client should engage the client end authenticator.
   The server end authenticator will then initiate authentication using
   the NNTP sockets (if appropriate for that authentication protocol),
   using the protocol specified by the authenticator name.  These
   authentication protocols are not included in this document, but are
   similar in structure to those referenced in RFC 1731 [8] for the
   IMAP-4 protocol.

   If the server returns 501, this means that the authenticator
   invocation was syntactically incorrect, or that AUTHINFO GENERIC is
   not supported.  The client should retry using the AUTHINFO USER
   command.

   If the requested authenticator capability is not found, the server
   returns the 503 response code.

   If there is some other unspecified server program error, the server
   returns the 500 response code.

   The authenticators converse using their protocol until complete.  If
   the authentication succeeds, the server authenticator will terminate
   with a 281, and the client can continue by reissuing the command that
   prompted the 380.  If the authentication fails, the server will
   respond with a 502.




Barber                       Informational                     [Page 19]

RFC 2980                 Common NNTP Extensions             October 2000


   The client must provide authentication when requested by the server.
   The server may request authentication at any time.  Servers may
   request authentication more than once during a single session.

   When the server authenticator completes, it provides to the server
   (by a mechanism herein undefined) the email address of the user, and
   potentially what the user is allowed to access.  Once authenticated,
   the server shall generate a Sender:  line using the email address
   provided by the authenticator if it does not match the user-supplied
   From: line.  Additionally, the server should log the event, including
   the user's authenticated email address (if available).  This will
   provide a means by which subsequent statistics generation can
   associate newsgroup references with unique entities - not necessarily
   by name.

   Some implementations make it possible to obtain a list of
   authentication procedures available by sending the server AUTHINFO
   GENERIC with no arguments.  The server then returns a list of
   supported mechanisms followed by a period on a line by itself.

3.1.3.1 Responses

      281 Authentication succeeded
      480 Authentication required
      500 Command not understood
      501 Command not supported
      502 No permission
      503 Program error, function not performed
      nnn  authenticator-specific protocol.

3.2 DATE

   DATE

   The first NNTP working group discussed and proposed a syntax for this
   command to help clients find out the current time from the server's
   perspective.  At the time this command was discussed (1991-1992), the
   Network Time Protocol [9] (NTP) was not yet in wide use and there was
   also some concern that small systems may not be able to make
   effective use of NTP.

   This command returns a one-line response code of 111 followed by the
   GMT date and time on the server in the form YYYYMMDDhhmmss.

3.2.1 Responses

      111 YYYYMMDDhhmmss




Barber                       Informational                     [Page 20]

RFC 2980                 Common NNTP Extensions             October 2000


3.3 The WILDMAT format

   The WILDMAT format was first developed by Rich Salz based on 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.  Patterns are
   implicitly anchored at the beginning and end of each string when
   testing for a match.  There are five pattern matching operations
   other than a strict one-to-one match between the pattern and the
   source to be checked for a match.  The first is an asterisk (*) to
   match any sequence of zero or more characters.  The second is a
   question mark (?) to match any single character.  The third specifies
   a specific set of characters.  The set is specified as a list of
   characters, or as a range of characters where the beginning and end
   of the range are separated by a minus (or dash) character, or as any
   combination of lists and ranges.  The dash can also be included in
   the set as a character it if is the beginning or end of the set.
   This set is enclosed in square brackets.  The close square bracket
   (]) may be used in a set if it is the first character in the set.
   The fourth operation is the same as the logical not of the third
   operation and is specified the same way as the third with the
   addition of a caret character (^) at the beginning of the test string
   just inside the open square bracket.  The final operation uses the
   backslash character to invalidate the special meaning of the a open
   square bracket ([), the asterisk, backslash or the question mark.
   Two backslashes in sequence will result in the evaluation of the
   backslash as a character with no special meaning.

3.3.1 Examples

   a. [^]-] -- matches any single character other than a close square
               bracket or a minus sign/dash.

   b. *bdc  -- matches any string that ends with the string "bdc"
               including the string "bdc" (without quotes).

   c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
               character.

   d. a??d  --  matches any four character string which begins
                with a and ends with d.










Barber                       Informational                     [Page 21]

RFC 2980                 Common NNTP Extensions             October 2000


3.4 Additional Headers

   Many NNTP implementations add headers to Usenet articles when then
   are POSTed via NNTP.  These headers are discussed in this section.
   None of these headers conflict with those specified in RFC 1036 and
   should be passed unchanged by Usenet transports conforming to RFC
   1036.

3.4.1 NNTP-Posting-Host

   This line is added to the header of a posted article by the server.
   The contents of the header is either the IP address or the fully
   qualified domain name of the client host posting the article.  The
   fully qualified domain name should be determined by doing a reverse
   lookup in the DNS on the IP address of the client.  If the client
   article contains this line, it is removed by the server before
   acceptance of the article by the Usenet transport system.

   This header provides some idea of the actual host posting the article
   as opposed to information in the Sender or From lines that may be
   present in the article.  This is not a fool-proof methodology since
   reverse lookups in the DNS are vulnerable to certain types of
   spoofing, but such discussions are outside the scope of this
   document.

3.4.2 X-Newsreader and others


   There are other lines that are added by clients as well.  Most of
   these indicate the type of newsreader software that is posting the
   article.

4.0 Common Implementation Issues

   Many NNTP implementations do not follow the specifications in RFC
   977.  In this section, some common implementation issues are
   summarized.

4.1 The Response to the LIST command

   RFC 977 says that the fourth field of the "list of valid newsgroups
   associated information" returned must be "either 'y' or 'n'
   indicating whether posting to this newsgroup is allowed ('y') or
   prohibited ('n').  Most implementations simply output the exact
   contents of the transport system's active newsgroup list.  For more
   implementations, the fourth field usually has more values that 'y' or
   'n'.




Barber                       Informational                     [Page 22]

RFC 2980                 Common NNTP Extensions             October 2000


4.2 The Required Headers in an Article and the POST command

   RFC 977 notes in section 3.10.1 that articles presented "should
   include all required header lines." In fact, modern implementations
   only require From, Subject, and Newsgroups header lines and will
   supply the rest; further, many implementers believe that it is best
   for clients to generate as few headers as possible, since clients
   often do not format other headers correctly.

   This implementation behavior is consistent with both Bnews and Cnews
   which would supply missing headers for articles directly submitted to
   them.

4.3 Article Numbering

   RFC 977 does not directly address the rules concerning articles
   number.  However, the current practice is simple: article numbers are
   monotonically increasing, articles may disappear, and therefore the
   high and low water marks returned in a GROUP command should be
   treated as maximum minima, and minimum maxima, respectively.

4.4 Availability of commands defined in RFC 977

   Some implementations permit administrators to disable commands
   defined RFC 977.  Some implementations have some set of commands
   disabled by default.  This means that client implementations cannot
   depend on the availability of the disabled set of commands.  This
   increases the complexity of the client and does not encourage
   implementors to optimize the implementation of commands that don't
   perform well.

   NEWNEWS is one of the commands frequently disabled.

4.5 The Distribution header and NEWNEWS

   In section 12.4 of RFC 977, the optional distributions argument is
   described.  This argument, according to RFC 977, would limit the
   responses to articles that were in newsgroups with prefixes that
   matched the optional distributions argument.

   Some implementations implement this by matching the Distributions
   header in articles to the distribution argument.  Others do the match
   against segments of the newsgroup's name.

   This variation is probably best explained by the evolution of the
   USENET article format.  At the time RFC 977 was specified, the
   newsgroup name defined how the group was distributed throughout
   USENET.  RFC 1036 changed this convention.  So, those that are



Barber                       Informational                     [Page 23]

RFC 2980                 Common NNTP Extensions             October 2000


   strictly implementing RFC 977 would match the newsgroup name prefix
   against the distribution argument and only display matches.  Those
   that implement against the intent of the command (as modified by the
   redefinition of the article format)would match the Distributions
   header against the distribution argument and only display those
   matches.

5.0 Further Work

   With the continued use of NNTP on the Internet, there remains an
   interest in creating an optimized transport protocol for server-to-
   server transfers and an optimized client protocol for client-to-
   server interactions.  There is also considerable interest is building
   better mechanisms to provide audit information on which news groups
   are being read by which users.

   An IETF working group has been formed and it is the hope of this
   author that these issues will be addressed in that forum.

6.0 Security Considerations

   The use of the AUTHINFO is optional.  This command as documented has
   a number of security implications.  In the original and simple forms,
   all passwords are passed in plaintext and could be discovered by
   various forms of network or system surveillance.  The AUTHINFO
   GENERIC command has the potential for the same problems if a
   mechanism is used that also passes cleartext passwords.  RFC 1731 [8]
   discusses these issues in greater detail.

7.0 References

   [1]  Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
        977, February 1986.

   [2]  Limoncelli, Tom, "Read This Before You Write a Newsreader",
        http://mars.superlink.net/tal/news-software-authors.html, June,
        1996.

   [3]  Horton, M. and R. Adams, "Standard for interchange of USENET
        messages",  RFC 1036, December 1987.

   [4]  Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
        distribution, UUNET Technologies, Revision 1.10, April, 1992.

   [5]  Robertson, Rob, "FAQ: Overview database / NOV General
        Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
        nov.Z, January, 1995.




Barber                       Informational                     [Page 24]

RFC 2980                 Common NNTP Extensions             October 2000


   [6]  Lea, Iain, "FAQ about the TIN newsreader",
        http://www.cs.unca.edu/~davidson/handouts/tinfaq.html

   [7]  Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
        2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/
        software/readers/%5Bnews.software.readers%5D_trn_newsreader
        _FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
        -hierarchy/news/software/readers/%5Bnews.software.readers
        %5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.

   [8]  Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
        December 1994.

   [9]  Mills, D., "Network Time Protocol (Version 3), Specification,
        Implementation and Analysis", RFC 1305, March 1992.

8.0 Notes

   DEC is a registered trademark of Compaq Computer Corporation.  UNIX
   is a registered trademark of The Open Group.  VMS is a registered
   trademark of Compaq Computer Corporation.

9.0 Acknowledgments

   The author gratefully acknowledges the comments and additional
   information provided by the following individuals:

   Wayne Davison <davison@armory.com>
   Chris Lewis <clewis@bnr.ca>
   Tom Limoncelli <tal@lucent.com>
   Eric Schnoebelen <eric@egsner.cirr.com>
   Rich Salz <rsalz@osf.org>

   This work was precipitated by the work of various newsreader authors
   and newsserver authors which includes those listed below:

   Rick Adams    -- Original author of the NNTP extensions to the RN
                    newsreader and last maintainer of Bnews
   Stan Barber   -- Original author of the NNTP extensions to the
                    newsreaders 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 newsreader
   Wayne Davison -- Author of the first threading extensions to the
                    RN newsreader (commonly called TRN).
   Geoff Huston  -- Original author of ANU NEWS





Barber                       Informational                     [Page 25]

RFC 2980                 Common NNTP Extensions             October 2000


   Phil Lapsey   -- Original author of the UNIX reference
                    implementation
   Iain Lea      -- Original maintainer of the TIN newsreader
   Chris Lewis   -- First known implementor 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 newsreader

10.0 Author's Address

   Stan Barber
   P.O. Box 300481
   Houston, Texas, 77230

   EMail: sob@academ.com



































Barber                       Informational                     [Page 26]

RFC 2980                 Common NNTP Extensions             October 2000


11.0 Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barber                       Informational                     [Page 27]