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