ignore generated appdata
[claws.git] / doc / src / rfc2980.txt
1
2
3
4
5
6
7 Network Working Group                                          S. Barber
8 Request for Comments: 2980                    Academ Consulting Services
9 Category: Informational                                     October 2000
10
11
12                          Common NNTP Extensions
13
14 Status of this Memo
15
16    This memo provides information for the Internet community.  It does
17    not specify an Internet standard of any kind.  Distribution of this
18    memo is unlimited.
19
20 Copyright Notice
21
22    Copyright (C) The Internet Society (2000).  All Rights Reserved.
23
24 Abstract
25
26    In this document, a number of popular extensions to the Network News
27    Transfer Protocol (NNTP) protocol defined in RFC 977 are documented
28    and discussed.  While this document is not intended to serve as a
29    standard of any kind, it will hopefully serve as a reference document
30    for future implementers of the NNTP protocol.  In the role, this
31    document would hopefully create the possibility for some level of
32    interoperability among implementations that make use of extensions.
33
34 Introduction
35
36    RFC 977 [1] defines the NNTP protocol and  was released over a decade
37    ago.  Since then, NNTP has become one of the most popular protocols
38    in use on the Internet.  Many implementations of the protocol have
39    been created on many different platforms and operating systems.  With
40    the growth in use of the protocol, work began on a revision to NNTP
41    in 1991, but that work did not result in a new standard protocol
42    specification.  However, many ideas from that working group did find
43    their way into many implementations of NNTP.  Additionally, many
44    other extensions, often created by newsreader authors, are also in
45    use.  This document will capture and define all known extensions to
46    NNTP available in official NNTP server releases of some type as of
47    this writing.  Where possible, the server software first implementing
48    a particular extension will be noted.  It is the hope of the author
49    that using this document in tandem with RFC 977 will limit the
50    addition of new extensions that essentially do the same thing.
51    Software developers may wish to use this document and others [2] as a
52    resource for the  development of new software.
53
54
55
56
57
58 Barber                       Informational                      [Page 1]
59 \f
60 RFC 2980                 Common NNTP Extensions             October 2000
61
62
63    This document does not specify an Internet Standard of any kind.  It
64    only attempts to document current practices.  While this document may
65    clarify some ambiguity in RFC 977, RFC 977 should be regarded as
66    authoritative in all cases.  There are some implementations that are
67    not strictly RFC 977 compliant and where necessary, these deviations
68    from the standard will be noted.  This document does reflect the work
69    of the IETF NNTP-EXT working group chaired by Ned Freed and Stan
70    Barber.
71
72    This document is provided to help implementers have a uniform source
73    of information about extensions, however, it is important for any
74    prospective implementer to understand that the extensions listed here
75    are NOT part of any current standard for NNTP.  In fact, some of the
76    ones listed in this document should not be included in new NNTP
77    implementations as they should no longer be used modern NNTP
78    environments.  Such commands should be considered historic and are
79    documented as such in this document.
80
81    Extensions fall into three categories: transport, newsreader and
82    other.  Transport extensions are additions to the NNTP specification
83    that were made specifically to move news articles from one server to
84    another server.  Newsreader extensions are additions to the NNTP
85    specification that were made to assist NNTP clients in selecting and
86    retrieving news articles from servers.  Other extensions to the NNTP
87    specification are those which did not specifically fall into either
88    of the other two categories.  Examples of other extensions include
89    authentication and time-of-day extensions.  For each command, the
90    format of section 3 of RFC 977 will be used.
91
92 1. Transport Extensions
93
94    A transport extension is one which is primarily used in inter-server
95    communications.  Following are the descriptions of each transport
96    extension commands and the responses which will be returned by those
97    commands.
98
99    Each command is shown in upper case for clarity, although case is
100    ignored in the interpretation of commands by the NNTP server.  Any
101    parameters are shown in lower case.  A parameter shown in [square
102    brackets] is optional.  For example, [GMT] indicates that the
103    triglyph GMT may present or omitted.  A parameter that may be
104    repeated is followed by an ellipsis.
105
106
107
108
109
110
111
112
113
114 Barber                       Informational                      [Page 2]
115 \f
116 RFC 2980                 Common NNTP Extensions             October 2000
117
118
119 1.1.1  The CHECK command
120
121    CHECK <message-id>
122
123    CHECK is used by a peer to discover if the article with the specified
124    message-id should be sent to the server using the TAKETHIS command.
125    The peer does not have to wait for a response from the server before
126    sending the next command.
127
128    From using the responses to the sequence of CHECK commands, a list of
129    articles to be sent can be constructed for subsequent use by the
130    TAKETHIS command.
131
132    The use of the CHECK command for streaming is optional.  Some
133    implementations will directly use the TAKETHIS command and send all
134    articles in the send queue on that peer for the server.
135
136    On some implementations, the use of the CHECK command is not
137    permitted when the server is in slave mode (via the SLAVE command).
138
139    Responses that are of the form X3X must specify the message-id in the
140    response.
141
142 1.1.2.  Responses
143
144       238 no such article found, please send it to me
145       400 not accepting articles
146       431 try sending it again later
147       438 already have it, please don't send it to me
148       480 Transfer permission denied
149       500 Command not understood
150
151 1.2.1  The MODE STREAM command
152
153    MODE STREAM
154
155    MODE STREAM is used by a peer to indicate to the server that it would
156    like to suspend the lock step conversational nature of NNTP and send
157    commands in streams.  This command should be used before TAKETHIS and
158    CHECK.  See the section on the commands TAKETHIS and CHECK for more
159    details.
160
161 1.2.2.  Responses
162
163       203 Streaming is OK
164       500 Command not understood
165
166
167
168
169
170 Barber                       Informational                      [Page 3]
171 \f
172 RFC 2980                 Common NNTP Extensions             October 2000
173
174
175 1.3.1  The TAKETHIS command
176
177    TAKETHIS <message-id>
178
179    TAKETHIS is used to send articles to a server when in streaming mode.
180    The entire article (header and body, in that sequence) is sent
181    immediately after the peer sends the TAKETHIS command.  The peer does
182    not have to wait for a response from the server before sending the
183    next command and the associated article.
184
185    During transmission of the article, the peer should send the entire
186    article, including header and body, in the manner specified for text
187    transmission from the server.  See RFC 977, Section 2.4.1 for
188    details.
189
190    Responses that are of the form X3X must specify the message-id in the
191    response.
192
193 1.3.2.  Responses
194
195       239 article transferred ok
196       400 not accepting articles
197       439 article transfer failed
198       480 Transfer permission denied
199       500 Command not understood
200
201 1.4.1  The XREPLIC command
202
203    XREPLIC ggg:nnn[,ggg:nnn...]
204
205    The XREPLIC command makes is possible to exactly duplicate the news
206    spool structure of one server in another server.  It first appeared
207    in INN.
208
209    This command works similarly to the IHAVE command as specified in RFC
210    977.  The same response codes are used.  The command line arguments
211    consist of entries separated by a single comma.  Each entry consists
212    of a news group name, a colon, and an article number.  If the server
213    responds with a 335 response, the article should be filed in the news
214    group(s) and article number(s) specified in the XREPLIC command line.
215    If the server cannot do successfully install the article once it has
216    accepted it, a 436 or 437 response code can be used to indicate the
217    failure.
218
219    This command should only be used when the receiving server is being
220    fed by only one other server.  It is likely that when used with
221    servers that have multiple feeds that this command will frequently
222    fail.
223
224
225
226 Barber                       Informational                      [Page 4]
227 \f
228 RFC 2980                 Common NNTP Extensions             October 2000
229
230
231    XREPLIC slaving has been deprecated in INN version 1.7.2 and later.
232    INN now has the ability to slave servers via transparent means,
233    simply by having the article's Xref header transferred.  (In previous
234    versions, this header was generated locally and stripped off on
235    outgoing feeds.)
236
237    It is likely that future versions of INN will no longer support
238    XREPLIC.
239
240 1.4.2.  Responses
241
242       235 article transferred ok
243       335 send article to be transferred.  End with <CR-LF>.<CR-LF>
244       435 article not wanted - do not send it
245       436 transfer failed - try again later
246       437 article rejected - do not try again
247
248 2. Newsreader Extensions
249
250    Newsreader extensions are those which are primarily used by
251    newsreading clients.  Following are the descriptions of each
252    newsreader extension commands and the responses which will be
253    returned by those commands.
254
255    Each command is shown in upper case for clarity, although case is
256    ignored in the interpretation of commands by the NNTP server.  Any
257    parameters are shown in lower case.  A parameter shown in [square
258    brackets] is optional.  For example, [GMT] indicates that the
259    triglyph GMT may present or omitted.  A parameter that may be
260    repeated is followed by an ellipsis.  Mutually exclusive parameters
261    are separated by a vertical bar (|) character.  For example,
262    ggg|<message-id> indicates that  a group name or a <message-id> may
263    be specified, but not both.  Some parameters, notably <message-id>,
264    is case specific.  See RFC 1036 for these details.
265
266    Also, certain commands make use of a pattern for selection of
267    multiple news groups.  The pattern in all cases is based on the
268    wildmat [4] format introduced by Rich Salz in 1986.  Arguments
269    expected to be in wildmat format will be represented by the string
270    wildmat.  This format is discussed in detail in section 3.3 of this
271    document.
272
273 2.1.1 Extensions to the LIST command
274
275    The original LIST command took no arguments in RFC 977 and returned
276    the contents of the active file in a specific format.  Since the
277    original newsreaders made use of other information available in the
278    news transport software in addition to the active file, extensions to
279
280
281
282 Barber                       Informational                      [Page 5]
283 \f
284 RFC 2980                 Common NNTP Extensions             October 2000
285
286
287    the LIST command were created to make that information available to
288    NNTP newsreaders.  There may be other extensions to the LIST command
289    that simply return the contents of a file.  This approach is
290    suggested over the addition of over verbs.  For example, LIST MOTD
291    could be used instead of adding XMOTD.
292
293 2.1.2 LIST ACTIVE
294
295    LIST ACTIVE [wildmat]
296
297    LIST ACTIVE is exactly the same as the LIST command specified in RFC
298    977.  The responses and the format should exactly match the LIST
299    command without arguments.  If the optional matching parameter is
300    specified, the list is limited to only the groups that match the
301    pattern.  Specifying a single group is usually very efficient for the
302    server, and multiple groups may be specified by using wildmat
303    patterns (described later in this document), not regular expressions.
304    If nothing is matched an empty list is returned, not an error.  This
305    command first appeared in the UNIX reference version.
306
307 2.1.3 LIST ACTIVE.TIMES
308
309    LIST ACTIVE.TIMES
310
311    The active.times file is maintained by some news transports systems
312    to contain information about the when and who created a particular
313    news group.  The format of this file generally include three fields.
314    The first field is the name of the news group.  The second is the
315    time when this group was created on this news server measured in
316    seconds since January 1, 1970.  The third is the email address of the
317    entity that created the news group.  When executed, the information
318    is displayed following the 215 response.  When display is completed,
319    the server will send a period on a line by itself.  If the
320    information is not available, the server will return the 503 error
321    response.  This command first appeared in the UNIX reference version.
322
323 2.1.3.1 Responses
324
325       215 information follows
326       503 program error, function not performed
327
328 2.1.4 LIST DISTRIBUTIONS
329
330    LIST DISTRIBUTIONS
331
332    The distributions file is maintained by some news transport systems
333    to contain information about valid values for the Distribution: line
334    in a news article header and about what the values mean.  Each line
335
336
337
338 Barber                       Informational                      [Page 6]
339 \f
340 RFC 2980                 Common NNTP Extensions             October 2000
341
342
343    contains two fields, the value and a short explanation on the meaning
344    of the value.  When executed, the information is displayed following
345    the 215 response.  When display is completed, the server will send a
346    period on a line by itself.  If the information is not available, the
347    server will return the 503 error response.  This command first
348    appeared in the UNIX reference version.
349
350 2.1.4.1 Responses
351
352       215 information follows
353       503 program error, function not performed
354
355 2.1.5 LIST DISTRIB.PATS
356
357    LIST DISTRIB.PATS
358
359    The distrib.pats file is maintained by some news transport systems to
360    contain default values for the Distribution:  line in a news article
361    header when posting to particular news groups.  This information
362    could be used to provide a default value for the Distribution: line
363    in the header when posting an article.  The information returned
364    involves three fields separated by colons.  The first column is a
365    weight.  The second is a group name or a pattern that can be used to
366    match a group name in the wildmat format.  The third is the value of
367    the Distribution:  line that should be used when the group name
368    matches and the weight value is the highest.  All this processing is
369    done by the news posting client and not by the server itself.  The
370    server just provides this information to the client for it to use or
371    ignore as it chooses.  When executed, the information is displayed
372    following the 215 response.  When display is completed, the server
373    will send a period on a line by itself.  If the information is not
374    available, the server will return the 503 error response.  This
375    command first appeared in INN.
376
377 2.1.5.1 Responses
378
379       215 information follows
380       503 program error, function not performed
381
382 2.1.6 LIST NEWSGROUPS
383
384    LIST NEWSGROUPS [wildmat]
385
386    The newsgroups file is maintained by some news transport systems to
387    contain the name of each news group which is active on the server and
388    a short description about the purpose of each news group.  Each line
389    in the file contains two fields, the news group name and a short
390    explanation of the purpose of that news group.  When executed, the
391
392
393
394 Barber                       Informational                      [Page 7]
395 \f
396 RFC 2980                 Common NNTP Extensions             October 2000
397
398
399    information is displayed following the 215 response.  When display is
400    completed, the server will send a period on a line by itself.  If the
401    information is not available, the server will return the 503
402    response.  If the optional matching parameter is specified, the list
403    is limited to only the groups that match the pattern (no matching is
404    done on the group descriptions).  Specifying a single group is
405    usually very efficient for the server, and multiple groups may be
406    specified by using wildmat patterns (similar to file globbing), not
407    regular expressions.  If nothing is matched an empty list is
408    returned, not an error.
409
410    When the optional parameter is specified, this command is equivalent
411    to the XGTITLE command, though the response code are different.
412
413       215 information follows
414       503 program error, function not performed
415
416 2.1.7 LIST OVERVIEW.FMT
417
418    LIST OVERVIEW.FMT
419
420    The overview.fmt file is maintained by some news transport systems to
421    contain the order in which header information is stored in the
422    overview databases for each news group.  When executed, news article
423    header fields are displayed one line at a time in the order in which
424    they are stored in the overview database [5] following the 215
425    response.  When display is completed, the server will send a period
426    on a line by itself.  If the information is not available, the server
427    will return the 503 response.
428
429    Please note that if the header has the word "full" (without quotes)
430    after the colon, the header's name is prepended to its field in the
431    output returned by the server.
432
433    Many newsreaders work better if Xref: is one of the optional fields.
434
435    It is STRONGLY recommended that this command be implemented in any
436    server that implements the XOVER command.  See section 2.8 for more
437    details about the XOVER command.
438
439 2.1.7.1 Responses
440
441       215 information follows
442       503 program error, function not performed
443
444
445
446
447
448
449
450 Barber                       Informational                      [Page 8]
451 \f
452 RFC 2980                 Common NNTP Extensions             October 2000
453
454
455 2.1.8 LIST SUBSCRIPTIONS
456
457    LIST SUBSCRIPTIONS
458
459    This command is used to get a default subscription list for new users
460    of this server.  The order of groups is significant.
461
462    When this list is available, it is preceded by the 215 response and
463    followed by a period on a line by itself.  When this list is not
464    available, the server returns a 503 response code.
465
466 2.1.8.1 Responses
467
468       215 information follows
469       503 program error, function not performed
470
471 2.2 LISTGROUP
472
473    LISTGROUP [ggg]
474
475    The LISTGROUP command is used to get a listing of all the article
476    numbers in a particular news group.
477
478    The optional parameter ggg is the name of the news group to be
479    selected (e.g. "news.software.b").  A list of valid news groups may
480    be obtained from the LIST command.  If no group is specified, the
481    current group is used as the default argument.
482
483    The successful selection response will be a list of the article
484    numbers in the group followed by a period on a line by itself.
485
486    When a valid group is selected by means of this command, the
487    internally maintained "current article pointer" is set to the first
488    article in the group.  If an invalid group is specified, the
489    previously selected group and article remain selected.  If an empty
490    news group is selected, the "current article pointer" is in an
491    indeterminate state and should not be used.
492
493    Note that the name of the news group is not case-dependent.  It must
494    otherwise match a news group obtained from the LIST command or an
495    error will result.
496
497 2.2.1  Responses
498
499       211 list of article numbers follow
500       412 Not currently in newsgroup
501       502 no permission
502
503
504
505
506 Barber                       Informational                      [Page 9]
507 \f
508 RFC 2980                 Common NNTP Extensions             October 2000
509
510
511 2.3 MODE READER
512
513    MODE READER is used by the client to indicate to the server that it
514    is a news reading client.  Some implementations make use of this
515    information to reconfigure themselves for better performance in
516    responding to news reader commands.  This command can be contrasted
517    with the SLAVE command in RFC 977, which was not widely implemented.
518    MODE READER was first available in INN.
519
520 2.3.1 Responses
521
522       200 Hello, you can post
523       201 Hello, you can't post
524
525 2.4 XGTITLE
526
527    XGTITLE [wildmat]
528
529    The XGTITLE command is used to retrieve news group descriptions for
530    specific news groups.
531
532    This extension first appeared in ANU-NEWS, an NNTP implementation for
533    DEC's VMS.  The optional parameter is a pattern in wildmat format.
534    When executed, a 282 response is given followed by lines that have
535    two fields, the news group name (which matches the pattern in the
536    argument) and a short explanation of the purpose of the news group.
537    When no argument is specified, the default argument is the current
538    group name.  When display is completed, the server sends a period on
539    a line by itself.
540
541    Please note that this command and the LIST NEWSGROUP command provide
542    the same functionality with different response codes.
543
544    Since this command provides the same functionality as LIST NEWSGROUP
545    it is suggested that this extension be deprecated and no longer be
546    used in newsreading clients.
547
548    Note that there is a conflict in one of the response codes from
549    XGTITLE and some of the authentication extensions.
550
551 2.5.1 Responses
552
553       481 Groups and descriptions unavailable
554       282 list of groups and descriptions follows
555
556
557
558
559
560
561
562 Barber                       Informational                     [Page 10]
563 \f
564 RFC 2980                 Common NNTP Extensions             October 2000
565
566
567 2.6 XHDR
568
569    XHDR header [range|<message-id>]
570
571    The XHDR command is used to retrieve specific headers from specific
572    articles.
573
574    The required parameter is the name of a header line (e.g.  "subject")
575    in a news group article.  See RFC 1036 for a list of valid header
576    lines.  The optional range argument may be any of the following:
577
578                an article number
579                an article number followed by a dash to indicate
580                   all following
581                an article number followed by a dash followed by
582                   another article number
583
584    The optional message-id argument indicates a specific article.  The
585    range and message-id arguments are mutually exclusive.  If no
586    argument is specified, then information from the current article is
587    displayed.  Successful responses start with a 221 response followed
588    by a the matched headers from all matched messages.  Each line
589    containing matched headers returned by the server has an article
590    number (or message ID, if a message ID was specified in the command),
591    then one or more spaces, then the value of the requested header in
592    that article.  Once the output is complete, a period is sent on a
593    line by itself.  If the optional argument is a message-id and no such
594    article exists, the 430 error response is returned.  If a range is
595    specified, a news group must have been selected earlier, else a 412
596    error response is returned.  If no articles are in the range
597    specified, a 420 error response is returned by the server.  A 502
598    response will be returned if the client only has permission to
599    transfer articles.
600
601    Some implementations will return "(none)" followed by a period on a
602    line by itself if no headers match in any of the articles searched.
603    Others return the 221 response code followed by a period on a line by
604    itself.
605
606    The XHDR command has been available in the UNIX reference
607    implementation from its first release.  However, until now, it has
608    been documented only in the source for the server.
609
610
611
612
613
614
615
616
617
618 Barber                       Informational                     [Page 11]
619 \f
620 RFC 2980                 Common NNTP Extensions             October 2000
621
622
623 2.6.1 Responses
624
625       221 Header follows
626       412 No news group current selected
627       420 No current article selected
628       430 no such article
629       502 no permission
630
631 2.7 XINDEX
632
633    XINDEX ggg
634
635    The XINDEX command is used to retrieve an index file in the format of
636    originally created for use by the TIN [6] news reader.
637
638    The required parameter ggg is the name of the news group to be
639    selected (e.g. "news.software.b").  A list of valid news groups may
640    be obtained from the LIST command.
641
642    The successful selection response will return index file in the
643    format used by the TIN news reader followed by a period on a line by
644    itself.
645
646    When a valid group is selected by means of this command, the
647    internally maintained "current article pointer" is set to the first
648    article in the group.  If an invalid group is specified, the
649    previously selected group and article remain selected.  If an empty
650    news group is selected, the "current article pointer" is in an
651    indeterminate state and should not be used.
652
653    Note that the name of the news group is not case-dependent.  It must
654    otherwise match a news group obtained from the LIST command or an
655    error will result.
656
657    The format of the tin-style index file is discussed in the
658    documentation for the TIN newsreader.  Since more recent versions of
659    TIN support the news overview (NOV) format, it is recommended that
660    this extension become historic and no longer be used in current
661    servers or future implementations.
662
663 2.7.1 Responses
664
665       218 tin-style index follows
666       418 no tin-style index is available for this news group
667
668
669
670
671
672
673
674 Barber                       Informational                     [Page 12]
675 \f
676 RFC 2980                 Common NNTP Extensions             October 2000
677
678
679 2.8 XOVER
680
681    XOVER [range]
682
683    The XOVER command returns information from the overview database for
684    the article(s) specified.  This command was originally suggested as
685    part of the OVERVIEW work described in "The Design of a Common
686    Newsgroup Overview Database for Newsreaders" by Geoff Collyer.  This
687    document is distributed in the Cnews distribution.  The optional
688    range argument may be any of the following:
689
690                an article number
691                an article number followed by a dash to indicate
692                   all following
693                an article number followed by a dash followed by
694                   another article number
695
696    If no argument is specified, then information from the current
697    article is displayed.  Successful responses start with a 224 response
698    followed by the overview information for all matched messages.  Once
699    the output is complete, a period is sent on a line by itself.  If no
700    argument is specified, the information for the current article is
701    returned.  A news group must have been selected earlier, else a 412
702    error response is returned.  If no articles are in the range
703    specified, a 420 error response is returned by the server.  A 502
704    response will be returned if the client only has permission to
705    transfer articles.
706
707    Each line of output will be formatted with the article number,
708    followed by each of the headers in the overview database or the
709    article itself (when the data is not available in the overview
710    database) for that article separated by a tab character.  The
711    sequence of fields must be in this order: subject, author, date,
712    message-id, references, byte count, and line count.  Other optional
713    fields may follow line count.  Other optional fields may follow line
714    count.  These fields are specified by examining the response to the
715    LIST OVERVIEW.FMT command.  Where no data exists, a null field must
716    be provided (i.e. the output will have two tab characters adjacent to
717    each other).  Servers should not output fields for articles that have
718    been removed since the XOVER database was created.
719
720    The LIST OVERVIEW.FMT command should be implemented if XOVER is
721    implemented.  A client can use LIST OVERVIEW.FMT to determine what
722    optional fields  and in which order all fields will be supplied by
723    the XOVER command.  See Section 2.1.7 for more details about the LIST
724    OVERVIEW.FMT command.
725
726
727
728
729
730 Barber                       Informational                     [Page 13]
731 \f
732 RFC 2980                 Common NNTP Extensions             October 2000
733
734
735    Note that any tab and end-of-line characters in any header data that
736    is returned will be converted to a space character.
737
738 2.8.1 Responses
739
740       224 Overview information follows
741       412 No news group current selected
742       420 No article(s) selected
743       502 no permission
744
745 2.9 XPAT
746
747    XPAT header range|<message-id> pat [pat...]
748
749    The XPAT command is used to retrieve specific headers from specific
750    articles, based on pattern matching on the contents of the header.
751    This command was first available in INN.
752
753    The required header parameter is the name of a header line (e.g.
754    "subject") in a news group article.  See RFC 1036 for a list of valid
755    header lines.  The required range argument may be any of the
756    following:
757
758                an article number
759                an article number followed by a dash to indicate
760                   all following
761                an article number followed by a dash followed by
762                   another article number
763
764    The required message-id argument indicates a specific article.  The
765    range and message-id arguments are mutually exclusive.  At least one
766    pattern in wildmat must be specified as well.  If there are
767    additional arguments the are joined together separated by a single
768    space to form one complete pattern.  Successful responses start with
769    a 221 response followed by a the headers from all messages in which
770    the pattern matched the contents of the specified header line.  This
771    includes an empty list.  Once the output is complete, a period is
772    sent on a line by itself.  If the optional argument is a message-id
773    and no such article exists, the 430 error response is returned.  A
774    502 response will be returned if the client only has permission to
775    transfer articles.
776
777 2.9.1 Responses
778
779       221 Header follows
780       430 no such article
781       502 no permission
782
783
784
785
786 Barber                       Informational                     [Page 14]
787 \f
788 RFC 2980                 Common NNTP Extensions             October 2000
789
790
791 2.10 The XPATH command
792
793    XPATH <message-id>
794
795    The XPATH command is used to determine the filenames in which an
796    article is filed.  It first appeared in INN.
797
798    The required parameter message-id is the message id of an article as
799    shown in that article's message-id header.  According to RFC 1036
800    [3], all message ids for all articles within the netnews environment
801    are unique, but articles may be crossposted to multiple groups.  The
802    response to an XPATH command will include a listing of all filenames
803    in which an article is stored separated by spaces or a response
804    indicating that no article with the specified message-id exists.  The
805    returned data is only useful if the news client knows the
806    implementation details of the server.  Because of this, it is
807    recommended that client avoid using this command.
808
809 2.10.1  Responses
810
811       223 path1[ path2 ...]
812       430 no such article on server
813
814 2.11 The XROVER command
815
816    XROVER [range]
817
818    The XROVER command returns reference information from the overview
819    database for the article(s) specified.  This command first appeared
820    in the Unix reference implementation.  The optional range argument
821    may be any of the following:
822
823                an article number
824                an article number followed by a dash to indicate
825                     all following
826                an article number followed by a dash followed by
827                    another article number
828
829    Successful responses start with a 224 response followed by the
830    contents of reference information for all matched messages.  Once the
831    output is complete, a period is sent on a line by itself.  If no
832    argument is specified, the information for the current article is
833    returned.  A news group must have been selected earlier, else a 412
834    error response is returned.  If no articles are in the range
835    specified, a 420 error response is returned by the server.  A 502
836    response will be returned if the client only has permission to
837    transfer articles.
838
839
840
841
842 Barber                       Informational                     [Page 15]
843 \f
844 RFC 2980                 Common NNTP Extensions             October 2000
845
846
847    The output will be formatted with the article number, followed by the
848    contents of the References: line for that article, but does not
849    contain the field name itself.
850
851    This command provides the same basic functionality as using the XHDR
852    command and "references" as the header argument.
853
854 2.11.1 Responses
855
856       224 Overview information follows
857       412 No news group current selected
858       420 No article(s) selected
859       502 no permission
860
861 2.12 XTHREAD
862
863    XTHREAD [DBINIT|THREAD]
864
865    The XTHREAD command is used to retrieve threading information
866    in format of originally created for use by the TRN [6] news
867    reader.
868
869    The command XTHREAD DBINIT may be issued prior to entering
870    any groups to see if a thread database exists.  If it does,
871    the database's byte order and version number are returned
872    as binary data.
873
874    If no parameter is given, XTHREAD THREAD is assumed.
875
876    To use XTHREAD THREAD, a news group must have been selected
877    earlier, else a 412 error response is returned.
878
879    A 502 response will be returned if the client only has
880    permission to transfer articles.  A 503 response is returned
881    if the threading files are not available.
882
883    The format of the trn-style thread format is discussed in
884    the documentation for the TRN newsreader.  Since more recent
885    versions of TRN support the news overview (NOV) format, it
886    is recommended that this extension become historic and no
887    longer be used in current servers or future implementations.
888
889 2.12.1 Responses
890
891       288 Binary data to follow
892       412 No newsgroup current selected
893       502 No permission
894       503 program error, function not performed
895
896
897
898 Barber                       Informational                     [Page 16]
899 \f
900 RFC 2980                 Common NNTP Extensions             October 2000
901
902
903 3. Other Extensions
904
905 3.1 AUTHINFO
906
907    AUTHINFO is used to inform a server about the identity of a user of
908    the server.  In all cases, clients must provide this information when
909    requested by the server.  Servers are not required to accept
910    authentication information that is volunteered by the client.
911    Clients must accommodate servers that reject any authentication
912    information volunteered by the client.
913
914    There are three forms of AUTHINFO in use.  The original version, an
915    NNTP v2 revision called AUTHINFO SIMPLE and a more recent version
916    which is called AUTHINFO GENERIC.
917
918 3.1.1 Original AUTHINFO
919
920    AUTHINFO USER username
921    AUTHINFO PASS password
922
923    The original AUTHINFO is used to identify a specific entity to the
924    server using a simple username/password combination.  It first
925    appeared in the UNIX reference implementation.
926
927    When authorization is required, the server will send a 480 response
928    requesting authorization from the client.  The client must enter
929    AUTHINFO USER followed by the username.  Once sent, the server will
930    cache the username and may send a 381 response requesting the
931    password associated with that username.  Should the server request a
932    password using the 381 response, the client must enter AUTHINFO PASS
933    followed by a password and the server will then check the
934    authentication database to see if the username/password combination
935    is valid.  If the combination is valid or if no password is required,
936    the server will return a 281 response.  The client should then retry
937    the original command to which the server responded with the 480
938    response.  The command should then be processed by the server
939    normally.  If the combination is not valid, the server will return a
940    502 response.
941
942    Clients must provide authentication when requested by the server.  It
943    is possible that some implementations will accept authentication
944    information at the beginning of a session, but this was not the
945    original intent of the specification.  If a client attempts to
946    reauthenticate, the server may return 482 response indicating that
947    the new authentication data is rejected by the server.  The 482 code
948    will also be returned when the AUTHINFO commands are not entered in
949    the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO
950    PASS preceding AUTHINFO USER).
951
952
953
954 Barber                       Informational                     [Page 17]
955 \f
956 RFC 2980                 Common NNTP Extensions             October 2000
957
958
959    All information is passed in cleartext.
960
961    When authentication succeeds, the server will create an email address
962    for the client from the user name supplied in the AUTHINFO USER
963    command and the hostname generated by a reverse lookup on the IP
964    address of the client.  If the reverse lookup fails, the IP address,
965    represented in dotted-quad format, will be used.  Once authenticated,
966    the server shall generate a Sender:  line using the email address
967    provided by authentication if it does not match the client-supplied
968    From: line.  Additionally, the server should log the event, including
969    the email address.  This will provide a means by which subsequent
970    statistics generation can associate newsgroup references with unique
971    entities - not necessarily by name.
972
973 3.1.1.1 Responses
974
975       281 Authentication accepted
976       381 More authentication information required
977       480 Authentication required
978       482 Authentication rejected
979       502 No permission
980
981 3.1.2 AUTHINFO SIMPLE
982
983    AUTHINFO SIMPLE
984    user password
985
986    This version of AUTHINFO was part of a proposed NNTP V2
987    specification, which was started in 1991 but never completed, and is
988    implemented in some servers and clients.  It is a refinement of the
989    original AUTHINFO and provides the same basic functionality, but the
990    sequence of commands is much simpler.
991
992    When authorization is required, the server sends a 450 response
993    requesting authorization from the client.  The client must enter
994    AUTHINFO SIMPLE.  If the server will accept this form of
995    authentication, the server responds with a 350 response.  The client
996    must then send the username followed by one or more space characters
997    followed by the password.  If accepted, the server returns a 250
998    response and the client should then retry the original command to
999    which the server responded with the 450 response.  The command should
1000    then be processed by the server normally.  If the combination is not
1001    valid, the server will return a 452 response.
1002
1003    Note that the response codes used here were part of the proposed NNTP
1004    V2 specification and are violations of RFC 977.  It is recommended
1005    that this command not be implemented, but use either or both of the
1006    other forms of AUTHINFO if such functionality if required.
1007
1008
1009
1010 Barber                       Informational                     [Page 18]
1011 \f
1012 RFC 2980                 Common NNTP Extensions             October 2000
1013
1014
1015 3.1.2.1 Responses
1016
1017       250 Authorization accepted
1018       350 Continue with authorization sequence
1019       450 Authorization required for this command
1020       452 Authorization rejected
1021
1022 3.1.3 AUTHINFO GENERIC
1023
1024    AUTHINFO GENERIC authenticator arguments...
1025
1026    AUTHINFO GENERIC is used to identify a specific entity to the server
1027    using arbitrary authentication  or identification protocols.  The
1028    desired protocol is indicated by the authenticator parameter, and any
1029    number of parameters can be passed to the authenticator.
1030
1031    When authorization is required, the server will send a 480 response
1032    requesting authorization from the client.  The client should enter
1033    AUTHINFO GENERIC followed by the authenticator name, and the
1034    arguments if any.  The authenticator and arguments must not contain
1035    the sequence "..".
1036
1037    The server will attempt to engage the server end authenticator,
1038    similarly, the client should engage the client end authenticator.
1039    The server end authenticator will then initiate authentication using
1040    the NNTP sockets (if appropriate for that authentication protocol),
1041    using the protocol specified by the authenticator name.  These
1042    authentication protocols are not included in this document, but are
1043    similar in structure to those referenced in RFC 1731 [8] for the
1044    IMAP-4 protocol.
1045
1046    If the server returns 501, this means that the authenticator
1047    invocation was syntactically incorrect, or that AUTHINFO GENERIC is
1048    not supported.  The client should retry using the AUTHINFO USER
1049    command.
1050
1051    If the requested authenticator capability is not found, the server
1052    returns the 503 response code.
1053
1054    If there is some other unspecified server program error, the server
1055    returns the 500 response code.
1056
1057    The authenticators converse using their protocol until complete.  If
1058    the authentication succeeds, the server authenticator will terminate
1059    with a 281, and the client can continue by reissuing the command that
1060    prompted the 380.  If the authentication fails, the server will
1061    respond with a 502.
1062
1063
1064
1065
1066 Barber                       Informational                     [Page 19]
1067 \f
1068 RFC 2980                 Common NNTP Extensions             October 2000
1069
1070
1071    The client must provide authentication when requested by the server.
1072    The server may request authentication at any time.  Servers may
1073    request authentication more than once during a single session.
1074
1075    When the server authenticator completes, it provides to the server
1076    (by a mechanism herein undefined) the email address of the user, and
1077    potentially what the user is allowed to access.  Once authenticated,
1078    the server shall generate a Sender:  line using the email address
1079    provided by the authenticator if it does not match the user-supplied
1080    From: line.  Additionally, the server should log the event, including
1081    the user's authenticated email address (if available).  This will
1082    provide a means by which subsequent statistics generation can
1083    associate newsgroup references with unique entities - not necessarily
1084    by name.
1085
1086    Some implementations make it possible to obtain a list of
1087    authentication procedures available by sending the server AUTHINFO
1088    GENERIC with no arguments.  The server then returns a list of
1089    supported mechanisms followed by a period on a line by itself.
1090
1091 3.1.3.1 Responses
1092
1093       281 Authentication succeeded
1094       480 Authentication required
1095       500 Command not understood
1096       501 Command not supported
1097       502 No permission
1098       503 Program error, function not performed
1099       nnn  authenticator-specific protocol.
1100
1101 3.2 DATE
1102
1103    DATE
1104
1105    The first NNTP working group discussed and proposed a syntax for this
1106    command to help clients find out the current time from the server's
1107    perspective.  At the time this command was discussed (1991-1992), the
1108    Network Time Protocol [9] (NTP) was not yet in wide use and there was
1109    also some concern that small systems may not be able to make
1110    effective use of NTP.
1111
1112    This command returns a one-line response code of 111 followed by the
1113    GMT date and time on the server in the form YYYYMMDDhhmmss.
1114
1115 3.2.1 Responses
1116
1117       111 YYYYMMDDhhmmss
1118
1119
1120
1121
1122 Barber                       Informational                     [Page 20]
1123 \f
1124 RFC 2980                 Common NNTP Extensions             October 2000
1125
1126
1127 3.3 The WILDMAT format
1128
1129    The WILDMAT format was first developed by Rich Salz based on the
1130    format used in the UNIX "find" command to articulate file names.  It
1131    was developed to provide a uniform mechanism for matching patterns in
1132    the same manner that the UNIX shell matches filenames.  Patterns are
1133    implicitly anchored at the beginning and end of each string when
1134    testing for a match.  There are five pattern matching operations
1135    other than a strict one-to-one match between the pattern and the
1136    source to be checked for a match.  The first is an asterisk (*) to
1137    match any sequence of zero or more characters.  The second is a
1138    question mark (?) to match any single character.  The third specifies
1139    a specific set of characters.  The set is specified as a list of
1140    characters, or as a range of characters where the beginning and end
1141    of the range are separated by a minus (or dash) character, or as any
1142    combination of lists and ranges.  The dash can also be included in
1143    the set as a character it if is the beginning or end of the set.
1144    This set is enclosed in square brackets.  The close square bracket
1145    (]) may be used in a set if it is the first character in the set.
1146    The fourth operation is the same as the logical not of the third
1147    operation and is specified the same way as the third with the
1148    addition of a caret character (^) at the beginning of the test string
1149    just inside the open square bracket.  The final operation uses the
1150    backslash character to invalidate the special meaning of the a open
1151    square bracket ([), the asterisk, backslash or the question mark.
1152    Two backslashes in sequence will result in the evaluation of the
1153    backslash as a character with no special meaning.
1154
1155 3.3.1 Examples
1156
1157    a. [^]-] -- matches any single character other than a close square
1158                bracket or a minus sign/dash.
1159
1160    b. *bdc  -- matches any string that ends with the string "bdc"
1161                including the string "bdc" (without quotes).
1162
1163    c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
1164                character.
1165
1166    d. a??d  --  matches any four character string which begins
1167                 with a and ends with d.
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178 Barber                       Informational                     [Page 21]
1179 \f
1180 RFC 2980                 Common NNTP Extensions             October 2000
1181
1182
1183 3.4 Additional Headers
1184
1185    Many NNTP implementations add headers to Usenet articles when then
1186    are POSTed via NNTP.  These headers are discussed in this section.
1187    None of these headers conflict with those specified in RFC 1036 and
1188    should be passed unchanged by Usenet transports conforming to RFC
1189    1036.
1190
1191 3.4.1 NNTP-Posting-Host
1192
1193    This line is added to the header of a posted article by the server.
1194    The contents of the header is either the IP address or the fully
1195    qualified domain name of the client host posting the article.  The
1196    fully qualified domain name should be determined by doing a reverse
1197    lookup in the DNS on the IP address of the client.  If the client
1198    article contains this line, it is removed by the server before
1199    acceptance of the article by the Usenet transport system.
1200
1201    This header provides some idea of the actual host posting the article
1202    as opposed to information in the Sender or From lines that may be
1203    present in the article.  This is not a fool-proof methodology since
1204    reverse lookups in the DNS are vulnerable to certain types of
1205    spoofing, but such discussions are outside the scope of this
1206    document.
1207
1208 3.4.2 X-Newsreader and others
1209
1210
1211    There are other lines that are added by clients as well.  Most of
1212    these indicate the type of newsreader software that is posting the
1213    article.
1214
1215 4.0 Common Implementation Issues
1216
1217    Many NNTP implementations do not follow the specifications in RFC
1218    977.  In this section, some common implementation issues are
1219    summarized.
1220
1221 4.1 The Response to the LIST command
1222
1223    RFC 977 says that the fourth field of the "list of valid newsgroups
1224    associated information" returned must be "either 'y' or 'n'
1225    indicating whether posting to this newsgroup is allowed ('y') or
1226    prohibited ('n').  Most implementations simply output the exact
1227    contents of the transport system's active newsgroup list.  For more
1228    implementations, the fourth field usually has more values that 'y' or
1229    'n'.
1230
1231
1232
1233
1234 Barber                       Informational                     [Page 22]
1235 \f
1236 RFC 2980                 Common NNTP Extensions             October 2000
1237
1238
1239 4.2 The Required Headers in an Article and the POST command
1240
1241    RFC 977 notes in section 3.10.1 that articles presented "should
1242    include all required header lines." In fact, modern implementations
1243    only require From, Subject, and Newsgroups header lines and will
1244    supply the rest; further, many implementers believe that it is best
1245    for clients to generate as few headers as possible, since clients
1246    often do not format other headers correctly.
1247
1248    This implementation behavior is consistent with both Bnews and Cnews
1249    which would supply missing headers for articles directly submitted to
1250    them.
1251
1252 4.3 Article Numbering
1253
1254    RFC 977 does not directly address the rules concerning articles
1255    number.  However, the current practice is simple: article numbers are
1256    monotonically increasing, articles may disappear, and therefore the
1257    high and low water marks returned in a GROUP command should be
1258    treated as maximum minima, and minimum maxima, respectively.
1259
1260 4.4 Availability of commands defined in RFC 977
1261
1262    Some implementations permit administrators to disable commands
1263    defined RFC 977.  Some implementations have some set of commands
1264    disabled by default.  This means that client implementations cannot
1265    depend on the availability of the disabled set of commands.  This
1266    increases the complexity of the client and does not encourage
1267    implementors to optimize the implementation of commands that don't
1268    perform well.
1269
1270    NEWNEWS is one of the commands frequently disabled.
1271
1272 4.5 The Distribution header and NEWNEWS
1273
1274    In section 12.4 of RFC 977, the optional distributions argument is
1275    described.  This argument, according to RFC 977, would limit the
1276    responses to articles that were in newsgroups with prefixes that
1277    matched the optional distributions argument.
1278
1279    Some implementations implement this by matching the Distributions
1280    header in articles to the distribution argument.  Others do the match
1281    against segments of the newsgroup's name.
1282
1283    This variation is probably best explained by the evolution of the
1284    USENET article format.  At the time RFC 977 was specified, the
1285    newsgroup name defined how the group was distributed throughout
1286    USENET.  RFC 1036 changed this convention.  So, those that are
1287
1288
1289
1290 Barber                       Informational                     [Page 23]
1291 \f
1292 RFC 2980                 Common NNTP Extensions             October 2000
1293
1294
1295    strictly implementing RFC 977 would match the newsgroup name prefix
1296    against the distribution argument and only display matches.  Those
1297    that implement against the intent of the command (as modified by the
1298    redefinition of the article format)would match the Distributions
1299    header against the distribution argument and only display those
1300    matches.
1301
1302 5.0 Further Work
1303
1304    With the continued use of NNTP on the Internet, there remains an
1305    interest in creating an optimized transport protocol for server-to-
1306    server transfers and an optimized client protocol for client-to-
1307    server interactions.  There is also considerable interest is building
1308    better mechanisms to provide audit information on which news groups
1309    are being read by which users.
1310
1311    An IETF working group has been formed and it is the hope of this
1312    author that these issues will be addressed in that forum.
1313
1314 6.0 Security Considerations
1315
1316    The use of the AUTHINFO is optional.  This command as documented has
1317    a number of security implications.  In the original and simple forms,
1318    all passwords are passed in plaintext and could be discovered by
1319    various forms of network or system surveillance.  The AUTHINFO
1320    GENERIC command has the potential for the same problems if a
1321    mechanism is used that also passes cleartext passwords.  RFC 1731 [8]
1322    discusses these issues in greater detail.
1323
1324 7.0 References
1325
1326    [1]  Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
1327         977, February 1986.
1328
1329    [2]  Limoncelli, Tom, "Read This Before You Write a Newsreader",
1330         http://mars.superlink.net/tal/news-software-authors.html, June,
1331         1996.
1332
1333    [3]  Horton, M. and R. Adams, "Standard for interchange of USENET
1334         messages",  RFC 1036, December 1987.
1335
1336    [4]  Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
1337         distribution, UUNET Technologies, Revision 1.10, April, 1992.
1338
1339    [5]  Robertson, Rob, "FAQ: Overview database / NOV General
1340         Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
1341         nov.Z, January, 1995.
1342
1343
1344
1345
1346 Barber                       Informational                     [Page 24]
1347 \f
1348 RFC 2980                 Common NNTP Extensions             October 2000
1349
1350
1351    [6]  Lea, Iain, "FAQ about the TIN newsreader",
1352         http://www.cs.unca.edu/~davidson/handouts/tinfaq.html
1353
1354    [7]  Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
1355         2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/
1356         software/readers/%5Bnews.software.readers%5D_trn_newsreader
1357         _FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
1358         -hierarchy/news/software/readers/%5Bnews.software.readers
1359         %5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.
1360
1361    [8]  Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
1362         December 1994.
1363
1364    [9]  Mills, D., "Network Time Protocol (Version 3), Specification,
1365         Implementation and Analysis", RFC 1305, March 1992.
1366
1367 8.0 Notes
1368
1369    DEC is a registered trademark of Compaq Computer Corporation.  UNIX
1370    is a registered trademark of The Open Group.  VMS is a registered
1371    trademark of Compaq Computer Corporation.
1372
1373 9.0 Acknowledgments
1374
1375    The author gratefully acknowledges the comments and additional
1376    information provided by the following individuals:
1377
1378    Wayne Davison <davison@armory.com>
1379    Chris Lewis <clewis@bnr.ca>
1380    Tom Limoncelli <tal@lucent.com>
1381    Eric Schnoebelen <eric@egsner.cirr.com>
1382    Rich Salz <rsalz@osf.org>
1383
1384    This work was precipitated by the work of various newsreader authors
1385    and newsserver authors which includes those listed below:
1386
1387    Rick Adams    -- Original author of the NNTP extensions to the RN
1388                     newsreader and last maintainer of Bnews
1389    Stan Barber   -- Original author of the NNTP extensions to the
1390                     newsreaders that are part of Bnews.
1391    Geoff Collyer -- Original author of the OVERVIEW database proposal and
1392                     one of the original authors of CNEWS
1393    Dan Curry     -- Original author of the xvnews newsreader
1394    Wayne Davison -- Author of the first threading extensions to the
1395                     RN newsreader (commonly called TRN).
1396    Geoff Huston  -- Original author of ANU NEWS
1397
1398
1399
1400
1401
1402 Barber                       Informational                     [Page 25]
1403 \f
1404 RFC 2980                 Common NNTP Extensions             October 2000
1405
1406
1407    Phil Lapsey   -- Original author of the UNIX reference
1408                     implementation
1409    Iain Lea      -- Original maintainer of the TIN newsreader
1410    Chris Lewis   -- First known implementor of the AUTHINFO GENERIC
1411                     extension
1412    Rich Salz     -- Original author of INN
1413    Henry Spencer -- One of the original authors of CNEWS
1414    Kim Storm     -- Original author of the NN newsreader
1415
1416 10.0 Author's Address
1417
1418    Stan Barber
1419    P.O. Box 300481
1420    Houston, Texas, 77230
1421
1422    EMail: sob@academ.com
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 Barber                       Informational                     [Page 26]
1459 \f
1460 RFC 2980                 Common NNTP Extensions             October 2000
1461
1462
1463 11.0 Full Copyright Statement
1464
1465    Copyright (C) The Internet Society (2000).  All Rights Reserved.
1466
1467    This document and translations of it may be copied and furnished to
1468    others, and derivative works that comment on or otherwise explain it
1469    or assist in its implementation may be prepared, copied, published
1470    and distributed, in whole or in part, without restriction of any
1471    kind, provided that the above copyright notice and this paragraph are
1472    included on all such copies and derivative works.  However, this
1473    document itself may not be modified in any way, such as by removing
1474    the copyright notice or references to the Internet Society or other
1475    Internet organizations, except as needed for the purpose of
1476    developing Internet standards in which case the procedures for
1477    copyrights defined in the Internet Standards process must be
1478    followed, or as required to translate it into languages other than
1479    English.
1480
1481    The limited permissions granted above are perpetual and will not be
1482    revoked by the Internet Society or its successors or assigns.
1483
1484    This document and the information contained herein is provided on an
1485    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1486    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1487    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1488    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1489    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1490
1491 Acknowledgement
1492
1493    Funding for the RFC Editor function is currently provided by the
1494    Internet Society.
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514 Barber                       Informational                     [Page 27]
1515 \f