* doc-src/readme.txt
authorChristoph Hohmann <reboot@gmx.ch>
Fri, 27 Sep 2002 16:48:46 +0000 (16:48 +0000)
committerChristoph Hohmann <reboot@gmx.ch>
Fri, 27 Sep 2002 16:48:46 +0000 (16:48 +0000)
* doc-src/rfc1806.txt
* doc-src/rfc2183.txt
* doc-src/rfc2980.txt
        update rfcs

ChangeLog.claws
configure.in
doc/src/readme.txt
doc/src/rfc1806.txt [deleted file]
doc/src/rfc2183.txt [new file with mode: 0644]
doc/src/rfc2980.txt [new file with mode: 0644]

index ec730ac..e3c3160 100644 (file)
@@ -1,3 +1,11 @@
+2002-09-27 [christoph] 0.8.3claws31
+
+       * doc-src/readme.txt
+       * doc-src/rfc1806.txt
+       * doc-src/rfc2183.txt
+       * doc-src/rfc2980.txt
+               update rfcs
+
 2002-09-27 [melvin]    0.8.3claws30
 
        * ac/aspell.m4
 2002-09-27 [melvin]    0.8.3claws30
 
        * ac/aspell.m4
index b2be77a..d8b616b 100644 (file)
@@ -10,7 +10,7 @@ MINOR_VERSION=8
 MICRO_VERSION=3
 INTERFACE_AGE=0
 BINARY_AGE=0
 MICRO_VERSION=3
 INTERFACE_AGE=0
 BINARY_AGE=0
-EXTRA_VERSION=claws30
+EXTRA_VERSION=claws31
 VERSION=$MAJOR_VERSION.$MINOR_VERSION.$MICRO_VERSION$EXTRA_VERSION
 
 dnl set $target
 VERSION=$MAJOR_VERSION.$MINOR_VERSION.$MICRO_VERSION$EXTRA_VERSION
 
 dnl set $target
index 9287809..443516f 100644 (file)
@@ -1,5 +1,4 @@
 rfc977.txt     NNTP
 rfc977.txt     NNTP
-rfc1806.txt    MIME Content-Disposition Extension
 rfc1939.txt    POP3
 rfc2015.txt    MIME Security with Pretty Good Privacy (PGP)
 rfc2045.txt    MIME 1
 rfc1939.txt    POP3
 rfc2015.txt    MIME Security with Pretty Good Privacy (PGP)
 rfc2045.txt    MIME 1
@@ -8,6 +7,8 @@ rfc2047.txt     MIME 3
 rfc2048.txt    MIME 4
 rfc2049.txt    MIME 5
 rfc2060.txt    IMAP4
 rfc2048.txt    MIME 4
 rfc2049.txt    MIME 5
 rfc2060.txt    IMAP4
+rfc2183.txt    The Content-Disposition Header Field
 rfc2487.txt    SMTP Service Extension for Secure SMTP over TLS
 rfc2821.txt    SMTP
 rfc2822.txt    Internet Message Format
 rfc2487.txt    SMTP Service Extension for Secure SMTP over TLS
 rfc2821.txt    SMTP
 rfc2822.txt    Internet Message Format
+rfc2980.txt    Common NNTP Extensions
diff --git a/doc/src/rfc1806.txt b/doc/src/rfc1806.txt
deleted file mode 100644 (file)
index 2b48317..0000000
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Troost
-Request for Comments: 1806                           New Century Systems
-Category: Experimental                                         S. Dorner
-                                                   QUALCOMM Incorporated
-                                                               June 1995
-
-
-               Communicating Presentation Information in
-                           Internet Messages:
-                     The Content-Disposition Header
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This memo provides a mechanism whereby messages conforming to the
-   [RFC 1521] ("MIME") specification can convey presentational
-   information.  It specifies a new "Content-Disposition" header,
-   optional and valid for any [RFC 1521] entity ("message" or "body
-   part"). Two values for this header are described in this memo; one
-   for the ordinary linear presentation of the body part, and another to
-   facilitate the use of mail to transfer files. It is expected that
-   more values will be defined in the future, and procedures are defined
-   for extending this set of values.
-
-   This document is intended as an extension to [RFC 1521]. As such, the
-   reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The
-   information presented herein supplements but does not replace that
-   found in those documents.
-
-1.  Introduction
-
-   [RFC 1521] specifies a standard format for encapsulating multiple
-   pieces of data into a single Internet message. That document does not
-   address the issue of presentation styles; it provides a framework for
-   the interchange of message content, but leaves presentation issues
-   solely in the hands of mail user agent (MUA) implementors.
-
-   Two common ways of presenting multipart electronic messages are as a
-   main document with a list of separate attachments, and as a single
-   document with the various parts expanded (displayed) inline. The
-   display of an attachment is generally construed to require positive
-   action on the part of the recipient, while inline message components
-
-
-
-Troost & Dorner               Experimental                      [Page 1]
-\f
-RFC 1806                  Content-Disposition                  June 1995
-
-
-   are displayed automatically when the message is viewed. A mechanism
-   is needed to allow the sender to transmit this sort of presentational
-   information to the recipient; the Content-Disposition header provides
-   this mechanism, allowing each component of a message to be tagged
-   with an indication of its desired presentation semantics.
-
-   Tagging messages in this manner will often be sufficient for basic
-   message formatting. However, in many cases a more powerful and
-   flexible approach will be necessary. The definition of such
-   approaches is beyond the scope of this memo; however, such approaches
-   can benefit from additional Content-Disposition values and
-   parameters, to be defined at a later date.
-
-   In addition to allowing the sender to specify the presentational
-   disposition of a message component, it is desirable to allow her to
-   indicate a default archival disposition; a filename. The optional
-   "filename" parameter provides for this.
-
-2.  The Content-Disposition Header Field
-
-   Content-Disposition is an optional header; in its absence, the MUA
-   may use whatever presentation method it deems suitable.
-
-   It is desirable to keep the set of possible disposition types small
-   and well defined, to avoid needless complexity. Even so, evolving
-   usage will likely require the definition of additional disposition
-   types or parameters, so the set of disposition values is extensible;
-   see below.
-
-   In the extended BNF notation of [RFC 822], the Content-Disposition
-   header field is defined as follows:
-
-        disposition := "Content-Disposition" ":"
-                       disposition-type
-                       *(";" disposition-parm)
-
-        disposition-type := "inline"
-                          / "attachment"
-                          / extension-token
-                          ; values are not case-sensitive
-
-        disposition-parm := filename-parm / parameter
-
-        filename-parm := "filename" "=" value;
-
-   `Extension-token', `parameter' and `value' are defined according to
-   [RFC 822] and [RFC 1521].
-
-
-
-
-Troost & Dorner               Experimental                      [Page 2]
-\f
-RFC 1806                  Content-Disposition                  June 1995
-
-
-2.1  The Inline Disposition Type
-
-   A bodypart should be marked `inline' if it is intended to be
-   displayed automatically upon display of the message. Inline bodyparts
-   should be presented in the order in which they occur, subject to the
-   normal semantics of multipart messages.
-
-2.2  The Attachment Disposition Type
-
-   Bodyparts can be designated `attachment' to indicate that they are
-   separate from the main body of the mail message, and that their
-   display should not be automatic, but contingent upon some further
-   action of the user. The MUA might instead present the user of a
-   bitmap terminal with an iconic representation of the attachments, or,
-   on character terminals, with a list of attachments from which the
-   user could select for viewing or storage.
-
-2.3  The Filename Parameter
-
-   The sender may want to suggest a filename to be used if the entity is
-   detached and stored in a separate file. If the receiving MUA writes
-   the entity to a file, the suggested filename should be used as a
-   basis for the actual filename, where possible.
-
-   It is important that the receiving MUA not blindly use the suggested
-   filename.  The suggested filename should be checked (and possibly
-   changed) to see that it conforms to local filesystem conventions,
-   does not overwrite an existing file, and does not present a security
-   problem (see Security Considerations below).
-
-   The receiving MUA should not respect any directory path information
-   that may seem to be present in the filename parameter.  The filename
-   should be treated as a terminal component only.  Portable
-   specification of directory paths might possibly be done in the future
-   via a separate Content-Disposition parameter, but no provision is
-   made for it in this draft.
-
-   Current [RFC 1521] grammar restricts parameter values (and hence
-   Content-Disposition filenames) to US-ASCII.  We recognize the great
-   desirability of allowing arbitrary character sets in filenames, but
-   it is beyond the scope of this document to define the necessary
-   mechanisms.  We expect that the basic [RFC 1521] `value'
-   specification will someday be amended to allow use of non-US-ASCII
-   characters, at which time the same mechanism should be used in the
-   Content-Disposition filename parameter.
-
-
-
-
-
-
-Troost & Dorner               Experimental                      [Page 3]
-\f
-RFC 1806                  Content-Disposition                  June 1995
-
-
-   Beyond the limitation to US-ASCII, the sending MUA may wish to bear
-   in mind the limitations of common filesystems.  Many have severe
-   length and character set restrictions.  Short alphanumeric filenames
-   are least likely to require modification by the receiving system.
-
-   The presence of the filename parameter does not force an
-   implementation to write the entity to a separate file. It is
-   perfectly acceptable for implementations to leave the entity as part
-   of the normal mail stream unless the user requests otherwise. As a
-   consequence, the parameter may be used on any MIME entity, even
-   `inline' ones. These will not normally be written to files, but the
-   parameter could be used to provide a filename if the receiving user
-   should choose to write the part to a file.
-
-2.4  Future Extensions and Unrecognized Disposition Types
-
-   In the likely event that new parameters or disposition types are
-   needed, they should be registered with the IANA, in the manner
-   specified in [RFC 1521], appendix E.
-
-   Once new disposition types and parameters are defined, there is of
-   course the likelihood that implementations will see disposition types
-   and parameters they do not understand.  Furthermore, since x-tokens
-   are allowed, implementations may also see entirely unregistered
-   disposition types and parameters.
-
-   Unrecognized parameters should be ignored. Unrecognized disposition
-   types should be treated as `attachment'. The choice of `attachment'
-   for unrecognized types is made because a sender who goes to the
-   trouble of producing a Content-Disposition header with a new
-   disposition type is more likely aiming for something more elaborate
-   than inline presentation.
-
-   Unless noted otherwise in the definition of a parameter, Content-
-   Disposition parameters are valid for all dispositions.  (In contrast
-   to [RFC 1521] content-type parameters, which are defined on a per-
-   content-type basis.) Thus, for example, the `filename' parameter
-   still means the name of the file to which the part should be written,
-   even if the disposition itself is unrecognized.
-
-2.5  Content-Disposition and Multipart
-
-   If a Content-Disposition header is used on a multipart body part, it
-   applies to the multipart as a whole, not the individual subparts.
-   The disposition types of the subparts do not need to be consulted
-   until the multipart itself is presented.  When the multipart is
-   displayed, then the dispositions of the subparts should be respected.
-
-
-
-
-Troost & Dorner               Experimental                      [Page 4]
-\f
-RFC 1806                  Content-Disposition                  June 1995
-
-
-   If the `inline' disposition is used, the multipart should be
-   displayed as normal; however, an `attachment' subpart should require
-   action from the user to display.
-
-   If the `attachment' disposition is used, presentation of the
-   multipart should not proceed without explicit user action.  Once the
-   user has chosen to display the multipart, the individual subpart
-   dispositions should be consulted to determine how to present the
-   subparts.
-
-2.6  Content-Disposition and the Main Message
-
-   It is permissible to use Content-Disposition on the main body of an
-   [RFC 822] message.
-
-3.  Examples
-
-   Here is a an example of a body part containing a JPEG image that is
-   intended to be viewed by the user immediately:
-
-         Content-Type: image/jpeg
-         Content-Disposition: inline
-         Content-Description: just a small picture of me
-
-         <jpeg data>
-
-   The following body part contains a JPEG image that should be
-   displayed to the user only if the user requests it. If the JPEG is
-   written to a file, the file should be named "genome.jpg":
-
-         Content-Type: image/jpeg
-         Content-Disposition: attachment; filename=genome.jpeg
-         Content-Description: a complete map of the human genome
-
-         <jpeg data>
-
-   The following is an example of the use of the `attachment'
-   disposition with a multipart body part.  The user should see text-
-   part-1 immediately, then take some action to view multipart-2.  After
-   taking action to view multipart-2, the user will see text-part-2
-   right away, and be required to take action to view jpeg-1.  Subparts
-   are indented for clarity; they would not be so indented in a real
-   message.
-
-         Content-Type: multipart/mixed; boundary=outer
-         Content-Description: multipart-1
-
-         --outer
-
-
-
-Troost & Dorner               Experimental                      [Page 5]
-\f
-RFC 1806                  Content-Disposition                  June 1995
-
-
-           Content-Type: text/plain
-           Content-Disposition: inline
-           Content-Description: text-part-1
-
-           Some text goes here
-
-         --outer
-           Content-Type: multipart/mixed; boundary=inner
-           Content-Disposition: attachment
-           Content-Description: multipart-2
-
-           --inner
-             Content-Type: text/plain
-             Content-Disposition: inline
-             Content-Description: text-part-2
-
-             Some more text here.
-
-           --inner
-             Content-Type: image/jpeg
-             Content-Disposition: attachment
-             Content-Description: jpeg-1
-
-             <jpeg data>
-           --inner--
-         --outer--
-
-4.  Summary
-
-   Content-Disposition takes one of two values, `inline' and
-   `attachment'.  'Inline' indicates that the entity should be
-   immediately displayed to the user, whereas `attachment' means that
-   the user should take additional action to view the entity.
-
-   The `filename' parameter can be used to suggest a filename for
-   storing the bodypart, if the user wishes to store it in an external
-   file.
-
-5.  Security Considerations
-
-   There are security issues involved any time users exchange data.
-   While these are not to be minimized, neither does this memo change
-   the status quo in that regard, except in one instance.
-
-   Since this memo provides a way for the sender to suggest a filename,
-   a receiving MUA must take care that the sender's suggested filename
-   does not represent a hazard. Using UNIX as an example, some hazards
-   would be:
-
-
-
-Troost & Dorner               Experimental                      [Page 6]
-\f
-RFC 1806                  Content-Disposition                  June 1995
-
-
-          + Creating startup files (e.g., ".login").
-
-          + Creating or overwriting system files (e.g.,
-            "/etc/passwd").
-
-          + Overwriting any existing file.
-
-          + Placing executable files into any command search path
-            (e.g., "~/bin/more").
-
-          + Sending the file to a pipe (e.g., "| sh").
-
-   In general, the receiving MUA should never name or place the file
-   such that it will get interpreted or executed without the user
-   explicitly initiating the action.
-
-   It is very important to note that this is not an exhaustive list; it
-   is intended as a small set of examples only.  Implementors must be
-   alert to the potential hazards on their target systems.
-
-6.  References
-
-    [RFC 1521]
-        Borenstein N., and N. Freed, "MIME (Multipurpose Internet
-        Mail Extensions) Part One:  Mechanisms for Specifying and
-        Describing the Format of Internet Message Bodies",
-        RFC 1521, Bellcore, Innosoft, September 1993.
-
-    [RFC 822]
-        Crocker, D., "Standard for the Format of ARPA Internet
-        Text Messages", STD 11, RFC 822, UDEL, August 1982.
-
-7.  Acknowledgements
-
-We gratefully acknowledge the help these people provided
-during the preparation of this draft:
-
-            Nathaniel Borenstein
-            Ned Freed
-            Keith Moore
-            Dave Crocker
-            Dan Pritchett
-
-
-
-
-
-
-
-
-
-Troost & Dorner               Experimental                      [Page 7]
-\f
-RFC 1806                  Content-Disposition                  June 1995
-
-
-8.  Authors' Addresses
-
-   Rens Troost
-   New Century Systems
-   324 East 41st Street #804
-   New York, NY, 10017 USA
-
-   Phone: +1 (212) 557-2050
-   Fax: +1 (212) 557-2049
-   EMail: rens@century.com
-
-
-   Steve Dorner
-   QUALCOMM Incorporated
-   6455 Lusk Boulevard
-   San Diego, CA 92121
-   USA
-
-   EMail: sdorner@qualcomm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Troost & Dorner               Experimental                      [Page 8]
-\f
diff --git a/doc/src/rfc2183.txt b/doc/src/rfc2183.txt
new file mode 100644 (file)
index 0000000..f16f127
--- /dev/null
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                          R. Troost
+Request for Comments: 2183                           New Century Systems
+Updates: 1806                                                  S. Dorner
+Category: Standards Track                          QUALCOMM Incorporated
+                                                        K. Moore, Editor
+                                                 University of Tennessee
+                                                             August 1997
+
+
+               Communicating Presentation Information in
+                           Internet Messages:
+                  The Content-Disposition Header Field
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo provides a mechanism whereby messages conforming to the
+   MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
+   2049] can convey presentational information.  It specifies the
+   "Content-Disposition" header field, which is optional and valid for
+   any MIME entity ("message" or "body part").  Two values for this
+   header field are described in this memo; one for the ordinary linear
+   presentation of the body part, and another to facilitate the use of
+   mail to transfer files.  It is expected that more values will be
+   defined in the future, and procedures are defined for extending this
+    set of values.
+
+   This document is intended as an extension to MIME.  As such, the
+   reader is assumed to be familiar with the MIME specifications, and
+   [RFC 822].  The information presented herein supplements but does not
+   replace that found in those documents.
+
+   This document is a revision to the Experimental protocol defined in
+   RFC 1806.  As compared to RFC 1806, this document contains minor
+   editorial updates, adds new parameters needed to support the File
+   Transfer Body Part, and references a separate specification for the
+   handling of non-ASCII and/or very long parameter values.
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 1]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+1.  Introduction
+
+   MIME specifies a standard format for encapsulating multiple pieces of
+   data into a single Internet message. That document does not address
+   the issue of presentation styles; it provides a framework for the
+   interchange of message content, but leaves presentation issues solely
+   in the hands of mail user agent (MUA) implementors.
+
+   Two common ways of presenting multipart electronic messages are as a
+   main document with a list of separate attachments, and as a single
+   document with the various parts expanded (displayed) inline. The
+   display of an attachment is generally construed to require positive
+   action on the part of the recipient, while inline message components
+   are displayed automatically when the message is viewed. A mechanism
+   is needed to allow the sender to transmit this sort of presentational
+   information to the recipient; the Content-Disposition header provides
+   this mechanism, allowing each component of a message to be tagged
+   with an indication of its desired presentation semantics.
+
+   Tagging messages in this manner will often be sufficient for basic
+   message formatting. However, in many cases a more powerful and
+   flexible approach will be necessary. The definition of such
+   approaches is beyond the scope of this memo; however, such approaches
+   can benefit from additional Content-Disposition values and
+   parameters, to be defined at a later date.
+
+   In addition to allowing the sender to specify the presentational
+   disposition of a message component, it is desirable to allow her to
+   indicate a default archival disposition; a filename. The optional
+   "filename" parameter provides for this.  Further, the creation-date,
+   modification-date, and read-date parameters allow preservation of
+   those file attributes when the file is transmitted over MIME email.
+
+   NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [RFC 2119].
+
+2.  The Content-Disposition Header Field
+
+   Content-Disposition is an optional header field. In its absence, the
+   MUA may use whatever presentation method it deems suitable.
+
+   It is desirable to keep the set of possible disposition types small
+   and well defined, to avoid needless complexity. Even so, evolving
+   usage will likely require the definition of additional disposition
+   types or parameters, so the set of disposition values is extensible;
+   see below.
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 2]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+   In the extended BNF notation of [RFC 822], the Content-Disposition
+   header field is defined as follows:
+
+     disposition := "Content-Disposition" ":"
+                    disposition-type
+                    *(";" disposition-parm)
+
+     disposition-type := "inline"
+                       / "attachment"
+                       / extension-token
+                       ; values are not case-sensitive
+
+     disposition-parm := filename-parm
+                       / creation-date-parm
+                       / modification-date-parm
+                       / read-date-parm
+                       / size-parm
+                       / parameter
+
+     filename-parm := "filename" "=" value
+
+     creation-date-parm := "creation-date" "=" quoted-date-time
+
+     modification-date-parm := "modification-date" "=" quoted-date-time
+
+     read-date-parm := "read-date" "=" quoted-date-time
+
+     size-parm := "size" "=" 1*DIGIT
+
+     quoted-date-time := quoted-string
+                      ; contents MUST be an RFC 822 `date-time'
+                      ; numeric timezones (+HHMM or -HHMM) MUST be used
+
+
+
+   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
+   parameter value containing only non-`tspecials' characters SHOULD be
+   represented as a single `token'.  A short parameter value containing
+   only ASCII characters, but including `tspecials' characters, SHOULD
+   be represented as `quoted-string'.  Parameter values longer than 78
+   characters, or which contain non-ASCII characters, MUST be encoded as
+   specified in [RFC 2184].
+
+   `Extension-token', `parameter', `tspecials' and `value' are defined
+   according to [RFC 2045] (which references [RFC 822] in the definition
+   of some of these tokens).  `quoted-string' and `DIGIT' are defined in
+   [RFC 822].
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 3]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+2.1  The Inline Disposition Type
+
+   A bodypart should be marked `inline' if it is intended to be
+   displayed automatically upon display of the message.  Inline
+   bodyparts should be presented in the order in which they occur,
+   subject to the normal semantics of multipart messages.
+
+2.2  The Attachment Disposition Type
+
+   Bodyparts can be designated `attachment' to indicate that they are
+   separate from the main body of the mail message, and that their
+   display should not be automatic, but contingent upon some further
+   action of the user.  The MUA might instead present the user of a
+   bitmap terminal with an iconic representation of the attachments, or,
+   on character terminals, with a list of attachments from which the
+   user could select for viewing or storage.
+
+2.3  The Filename Parameter
+
+   The sender may want to suggest a filename to be used if the entity is
+   detached and stored in a separate file. If the receiving MUA writes
+   the entity to a file, the suggested filename should be used as a
+   basis for the actual filename, where possible.
+
+   It is important that the receiving MUA not blindly use the suggested
+   filename.  The suggested filename SHOULD be checked (and possibly
+   changed) to see that it conforms to local filesystem conventions,
+   does not overwrite an existing file, and does not present a security
+   problem (see Security Considerations below).
+
+   The receiving MUA SHOULD NOT respect any directory path information
+   that may seem to be present in the filename parameter.  The filename
+   should be treated as a terminal component only.  Portable
+   specification of directory paths might possibly be done in the future
+   via a separate Content-Disposition parameter, but no provision is
+   made for it in this draft.
+
+   Current [RFC 2045] grammar restricts parameter values (and hence
+   Content-Disposition filenames) to US-ASCII.  We recognize the great
+   desirability of allowing arbitrary character sets in filenames, but
+   it is beyond the scope of this document to define the necessary
+   mechanisms.  We expect that the basic [RFC 1521] `value'
+   specification will someday be amended to allow use of non-US-ASCII
+   characters, at which time the same mechanism should be used in the
+   Content-Disposition filename parameter.
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 4]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+   Beyond the limitation to US-ASCII, the sending MUA may wish to bear
+   in mind the limitations of common filesystems.  Many have severe
+   length and character set restrictions.  Short alphanumeric filenames
+   are least likely to require modification by the receiving system.
+
+   The presence of the filename parameter does not force an
+   implementation to write the entity to a separate file. It is
+   perfectly acceptable for implementations to leave the entity as part
+   of the normal mail stream unless the user requests otherwise. As a
+   consequence, the parameter may be used on any MIME entity, even
+   `inline' ones. These will not normally be written to files, but the
+   parameter could be used to provide a filename if the receiving user
+   should choose to write the part to a file.
+
+2.4 The Creation-Date parameter
+
+   The creation-date parameter MAY be used to indicate the date at which
+   the file was created.  If this parameter is included, the paramter
+   value MUST be a quoted-string which contains a representation of the
+   creation date of the file in [RFC 822] `date-time' format.
+
+   UNIX and POSIX implementors are cautioned that the `st_ctime' file
+   attribute of the `stat' structure is not the creation time of the
+   file; it is thus not appropriate as a source for the creation-date
+   parameter value.
+
+2.5 The Modification-Date parameter
+
+   The modification-date parameter MAY be used to indicate the date at
+   which the file was last modified.  If the modification-date parameter
+   is included, the paramter value MUST be a quoted-string which
+   contains a representation of the last modification date of the file
+   in [RFC 822] `date-time' format.
+
+2.6 The Read-Date parameter
+
+   The read-date parameter MAY be used to indicate the date at which the
+   file was last read.  If the read-date parameter is included, the
+   parameter value MUST be a quoted-string which contains a
+   representation of the last-read date of the file in [RFC 822] `date-
+   time' format.
+
+2.7 The Size parameter
+
+   The size parameter indicates an approximate size of the file in
+   octets.  It can be used, for example, to pre-allocate space before
+   attempting to store the file, or to determine whether enough space
+   exists.
+
+
+
+Troost, et. al.             Standards Track                     [Page 5]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+2.8  Future Extensions and Unrecognized Disposition Types
+
+   In the likely event that new parameters or disposition types are
+   needed, they should be registered with the Internet Assigned Numbers
+   Authority (IANA), in the manner specified in Section 9 of this memo.
+
+   Once new disposition types and parameters are defined, there is of
+   course the likelihood that implementations will see disposition types
+   and parameters they do not understand.  Furthermore, since x-tokens
+   are allowed, implementations may also see entirely unregistered
+   disposition types and parameters.
+
+   Unrecognized parameters should be ignored. Unrecognized disposition
+   types should be treated as `attachment'. The choice of `attachment'
+   for unrecognized types is made because a sender who goes to the
+   trouble of producing a Content-Disposition header with a new
+   disposition type is more likely aiming for something more elaborate
+   than inline presentation.
+
+   Unless noted otherwise in the definition of a parameter, Content-
+   Disposition parameters are valid for all dispositions.  (In contrast
+   to MIME content-type parameters, which are defined on a per-content-
+   type basis.) Thus, for example, the `filename' parameter still means
+   the name of the file to which the part should be written, even if the
+   disposition itself is unrecognized.
+
+2.9  Content-Disposition and Multipart
+
+   If a Content-Disposition header is used on a multipart body part, it
+   applies to the multipart as a whole, not the individual subparts.
+   The disposition types of the subparts do not need to be consulted
+   until the multipart itself is presented.  When the multipart is
+   displayed, then the dispositions of the subparts should be respected.
+
+   If the `inline' disposition is used, the multipart should be
+   displayed as normal; however, an `attachment' subpart should require
+   action from the user to display.
+
+   If the `attachment' disposition is used, presentation of the
+   multipart should not proceed without explicit user action.  Once the
+   user has chosen to display the multipart, the individual subpart
+   dispositions should be consulted to determine how to present the
+   subparts.
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 6]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+2.10  Content-Disposition and the Main Message
+
+   It is permissible to use Content-Disposition on the main body of an
+   [RFC 822] message.
+
+3.  Examples
+
+   Here is a an example of a body part containing a JPEG image that is
+   intended to be viewed by the user immediately:
+
+        Content-Type: image/jpeg
+        Content-Disposition: inline
+        Content-Description: just a small picture of me
+
+         <jpeg data>
+
+   The following body part contains a JPEG image that should be
+   displayed to the user only if the user requests it. If the JPEG is
+   written to a file, the file should be named "genome.jpg".  The
+   recipient's user might also choose to set the last-modified date of
+   the stored file to date in the modification-date parameter:
+
+        Content-Type: image/jpeg
+        Content-Disposition: attachment; filename=genome.jpeg;
+          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
+        Content-Description: a complete map of the human genome
+
+        <jpeg data>
+
+   The following is an example of the use of the `attachment'
+   disposition with a multipart body part.  The user should see text-
+   part-1 immediately, then take some action to view multipart-2.  After
+   taking action to view multipart-2, the user will see text-part-2
+   right away, and be required to take action to view jpeg-1.  Subparts
+   are indented for clarity; they would not be so indented in a real
+   message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 7]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+        Content-Type: multipart/mixed; boundary=outer
+        Content-Description: multipart-1
+
+        --outer
+          Content-Type: text/plain
+          Content-Disposition: inline
+          Content-Description: text-part-1
+
+          Some text goes here
+
+        --outer
+          Content-Type: multipart/mixed; boundary=inner
+          Content-Disposition: attachment
+          Content-Description: multipart-2
+
+          --inner
+            Content-Type: text/plain
+            Content-Disposition: inline
+            Content-Description: text-part-2
+
+            Some more text here.
+
+          --inner
+            Content-Type: image/jpeg
+            Content-Disposition: attachment
+            Content-Description: jpeg-1
+
+            <jpeg data>
+          --inner--
+        --outer--
+
+4.  Summary
+
+   Content-Disposition takes one of two values, `inline' and
+   `attachment'.  `Inline' indicates that the entity should be
+   immediately displayed to the user, whereas `attachment' means that
+   the user should take additional action to view the entity.
+
+   The `filename' parameter can be used to suggest a filename for
+   storing the bodypart, if the user wishes to store it in an external
+   file.
+
+
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 8]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+5.  Security Considerations
+
+   There are security issues involved any time users exchange data.
+   While these are not to be minimized, neither does this memo change
+   the status quo in that regard, except in one instance.
+
+   Since this memo provides a way for the sender to suggest a filename,
+   a receiving MUA must take care that the sender's suggested filename
+   does not represent a hazard. Using UNIX as an example, some hazards
+   would be:
+
+   +    Creating startup files (e.g., ".login").
+
+   +    Creating or overwriting system files (e.g., "/etc/passwd").
+
+   +    Overwriting any existing file.
+
+   +    Placing executable files into any command search path
+        (e.g., "~/bin/more").
+
+   +    Sending the file to a pipe (e.g., "| sh").
+
+   In general, the receiving MUA should not name or place the file such
+   that it will get interpreted or executed without the user explicitly
+   initiating the action.
+
+   It is very important to note that this is not an exhaustive list; it
+   is intended as a small set of examples only.  Implementors must be
+   alert to the potential hazards on their target systems.
+
+6.  References
+
+   [RFC 2119]
+        Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, March 1997.
+
+   [RFC 2184]
+        Freed, N. and K. Moore, "MIME Parameter value and Encoded Words:
+        Character Sets, Lanaguage, and Continuations", RFC 2184, August
+        1997.
+
+   [RFC 2045]
+        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
+        Extensions) Part One: Format of Internet Message Bodies", RFC
+        2045, December 1996.
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 9]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+   [RFC 2046]
+        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
+        Extensions) Part Two: Media Types", RFC 2046, December 1996.
+
+   [RFC 2047]
+        Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+        Three: Message Header Extensions for non-ASCII Text", RFC 2047,
+        December 1996.
+
+   [RFC 2048]
+        Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose
+        Internet Mail Extensions) Part Four: Registration Procedures",
+        RFC 2048, December 1996.
+
+   [RFC 2049]
+        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
+        Extensions) Part Five: Conformance Criteria and Examples", RFC
+        2049, December 1996.
+
+   [RFC 822]
+        Crocker, D., "Standard for the Format of ARPA Internet Text
+        Messages", STD 11, RFC 822, UDEL, August 1982.
+
+7.  Acknowledgements
+
+   We gratefully acknowledge the help these people provided during the
+   preparation of this draft:
+
+        Nathaniel Borenstein
+        Ned Freed
+        Keith Moore
+        Dave Crocker
+        Dan Pritchett
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                    [Page 10]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+8.  Authors' Addresses
+
+   You should blame the editor of this version of the document for any
+   changes since RFC 1806:
+
+        Keith Moore
+        Department of Computer Science
+        University of Tennessee, Knoxville
+        107 Ayres Hall
+        Knoxville TN  37996-1301
+        USA
+
+        Phone: +1 (423) 974-5067
+        Fax: +1 (423) 974-8296
+        Email: moore@cs.utk.edu
+
+
+        The authors of RFC 1806 are:
+
+        Rens Troost
+        New Century Systems
+        324 East 41st Street #804
+        New York, NY, 10017 USA
+
+        Phone: +1 (212) 557-2050
+        Fax: +1 (212) 557-2049
+        EMail: rens@century.com
+
+
+        Steve Dorner
+        QUALCOMM Incorporated
+        6455 Lusk Boulevard
+        San Diego, CA 92121
+        USA
+
+        EMail: sdorner@qualcomm.com
+
+
+9. Registration of New Content-Disposition Values and Parameters
+
+   New Content-Disposition values (besides "inline" and "attachment")
+   may be defined only by Internet standards-track documents, or in
+   Experimental documents approved by the Internet Engineering Steering
+   Group.
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                    [Page 11]
+\f
+RFC 2183                  Content-Disposition                August 1997
+
+
+   New content-disposition parameters may be registered by supplying the
+   information in the following template and sending it via electronic
+   mail to IANA@IANA.ORG:
+
+     To: IANA@IANA.ORG
+     Subject: Registration of new Content-Disposition parameter
+
+     Content-Disposition parameter name:
+
+     Allowable values for this parameter:
+          (If the parameter can only assume a small number of values,
+          list each of those values.  Otherwise, describe the values
+          that the parameter can assume.)
+     Description:
+          (What is the purpose of this parameter and how is it used?)
+
+10. Changes since RFC 1806
+
+   The following changes have been made since the earlier version of
+   this document, published in RFC 1806 as an Experimental protocol:
+
+   +    Updated references to MIME documents.  In some cases this
+        involved substituting a reference to one of the current MIME
+        RFCs for a reference to RFC 1521; in other cases, a reference to
+        RFC 1521 was simply replaced with the word "MIME".
+
+   +    Added  a section on registration procedures, since none of the
+        procedures in RFC 2048 seemed to be appropriate.
+
+   +    Added new parameter types: creation-date, modification-date,
+        read-date, and size.
+
+
+   +    Incorporated a reference to draft-freed-pvcsc-* for encoding
+        long or non-ASCII parameter values.
+
+   +    Added reference to RFC 2119 to define MUST, SHOULD, etc.
+        keywords.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                    [Page 12]
+\f
diff --git a/doc/src/rfc2980.txt b/doc/src/rfc2980.txt
new file mode 100644 (file)
index 0000000..2def1be
--- /dev/null
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                          S. Barber
+Request for Comments: 2980                    Academ Consulting Services
+Category: Informational                                     October 2000
+
+
+                         Common NNTP Extensions
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   In this document, a number of popular extensions to the Network News
+   Transfer Protocol (NNTP) protocol defined in RFC 977 are documented
+   and discussed.  While this document is not intended to serve as a
+   standard of any kind, it will hopefully serve as a reference document
+   for future implementers of the NNTP protocol.  In the role, this
+   document would hopefully create the possibility for some level of
+   interoperability among implementations that make use of extensions.
+
+Introduction
+
+   RFC 977 [1] defines the NNTP protocol and  was released over a decade
+   ago.  Since then, NNTP has become one of the most popular protocols
+   in use on the Internet.  Many implementations of the protocol have
+   been created on many different platforms and operating systems.  With
+   the growth in use of the protocol, work began on a revision to NNTP
+   in 1991, but that work did not result in a new standard protocol
+   specification.  However, many ideas from that working group did find
+   their way into many implementations of NNTP.  Additionally, many
+   other extensions, often created by newsreader authors, are also in
+   use.  This document will capture and define all known extensions to
+   NNTP available in official NNTP server releases of some type as of
+   this writing.  Where possible, the server software first implementing
+   a particular extension will be noted.  It is the hope of the author
+   that using this document in tandem with RFC 977 will limit the
+   addition of new extensions that essentially do the same thing.
+   Software developers may wish to use this document and others [2] as a
+   resource for the  development of new software.
+
+
+
+
+
+Barber                       Informational                      [Page 1]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   This document does not specify an Internet Standard of any kind.  It
+   only attempts to document current practices.  While this document may
+   clarify some ambiguity in RFC 977, RFC 977 should be regarded as
+   authoritative in all cases.  There are some implementations that are
+   not strictly RFC 977 compliant and where necessary, these deviations
+   from the standard will be noted.  This document does reflect the work
+   of the IETF NNTP-EXT working group chaired by Ned Freed and Stan
+   Barber.
+
+   This document is provided to help implementers have a uniform source
+   of information about extensions, however, it is important for any
+   prospective implementer to understand that the extensions listed here
+   are NOT part of any current standard for NNTP.  In fact, some of the
+   ones listed in this document should not be included in new NNTP
+   implementations as they should no longer be used modern NNTP
+   environments.  Such commands should be considered historic and are
+   documented as such in this document.
+
+   Extensions fall into three categories: transport, newsreader and
+   other.  Transport extensions are additions to the NNTP specification
+   that were made specifically to move news articles from one server to
+   another server.  Newsreader extensions are additions to the NNTP
+   specification that were made to assist NNTP clients in selecting and
+   retrieving news articles from servers.  Other extensions to the NNTP
+   specification are those which did not specifically fall into either
+   of the other two categories.  Examples of other extensions include
+   authentication and time-of-day extensions.  For each command, the
+   format of section 3 of RFC 977 will be used.
+
+1. Transport Extensions
+
+   A transport extension is one which is primarily used in inter-server
+   communications.  Following are the descriptions of each transport
+   extension commands and the responses which will be returned by those
+   commands.
+
+   Each command is shown in upper case for clarity, although case is
+   ignored in the interpretation of commands by the NNTP server.  Any
+   parameters are shown in lower case.  A parameter shown in [square
+   brackets] is optional.  For example, [GMT] indicates that the
+   triglyph GMT may present or omitted.  A parameter that may be
+   repeated is followed by an ellipsis.
+
+
+
+
+
+
+
+
+
+Barber                       Informational                      [Page 2]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+1.1.1  The CHECK command
+
+   CHECK <message-id>
+
+   CHECK is used by a peer to discover if the article with the specified
+   message-id should be sent to the server using the TAKETHIS command.
+   The peer does not have to wait for a response from the server before
+   sending the next command.
+
+   From using the responses to the sequence of CHECK commands, a list of
+   articles to be sent can be constructed for subsequent use by the
+   TAKETHIS command.
+
+   The use of the CHECK command for streaming is optional.  Some
+   implementations will directly use the TAKETHIS command and send all
+   articles in the send queue on that peer for the server.
+
+   On some implementations, the use of the CHECK command is not
+   permitted when the server is in slave mode (via the SLAVE command).
+
+   Responses that are of the form X3X must specify the message-id in the
+   response.
+
+1.1.2.  Responses
+
+      238 no such article found, please send it to me
+      400 not accepting articles
+      431 try sending it again later
+      438 already have it, please don't send it to me
+      480 Transfer permission denied
+      500 Command not understood
+
+1.2.1  The MODE STREAM command
+
+   MODE STREAM
+
+   MODE STREAM is used by a peer to indicate to the server that it would
+   like to suspend the lock step conversational nature of NNTP and send
+   commands in streams.  This command should be used before TAKETHIS and
+   CHECK.  See the section on the commands TAKETHIS and CHECK for more
+   details.
+
+1.2.2.  Responses
+
+      203 Streaming is OK
+      500 Command not understood
+
+
+
+
+
+Barber                       Informational                      [Page 3]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+1.3.1  The TAKETHIS command
+
+   TAKETHIS <message-id>
+
+   TAKETHIS is used to send articles to a server when in streaming mode.
+   The entire article (header and body, in that sequence) is sent
+   immediately after the peer sends the TAKETHIS command.  The peer does
+   not have to wait for a response from the server before sending the
+   next command and the associated article.
+
+   During transmission of the article, the peer should send the entire
+   article, including header and body, in the manner specified for text
+   transmission from the server.  See RFC 977, Section 2.4.1 for
+   details.
+
+   Responses that are of the form X3X must specify the message-id in the
+   response.
+
+1.3.2.  Responses
+
+      239 article transferred ok
+      400 not accepting articles
+      439 article transfer failed
+      480 Transfer permission denied
+      500 Command not understood
+
+1.4.1  The XREPLIC command
+
+   XREPLIC ggg:nnn[,ggg:nnn...]
+
+   The XREPLIC command makes is possible to exactly duplicate the news
+   spool structure of one server in another server.  It first appeared
+   in INN.
+
+   This command works similarly to the IHAVE command as specified in RFC
+   977.  The same response codes are used.  The command line arguments
+   consist of entries separated by a single comma.  Each entry consists
+   of a news group name, a colon, and an article number.  If the server
+   responds with a 335 response, the article should be filed in the news
+   group(s) and article number(s) specified in the XREPLIC command line.
+   If the server cannot do successfully install the article once it has
+   accepted it, a 436 or 437 response code can be used to indicate the
+   failure.
+
+   This command should only be used when the receiving server is being
+   fed by only one other server.  It is likely that when used with
+   servers that have multiple feeds that this command will frequently
+   fail.
+
+
+
+Barber                       Informational                      [Page 4]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   XREPLIC slaving has been deprecated in INN version 1.7.2 and later.
+   INN now has the ability to slave servers via transparent means,
+   simply by having the article's Xref header transferred.  (In previous
+   versions, this header was generated locally and stripped off on
+   outgoing feeds.)
+
+   It is likely that future versions of INN will no longer support
+   XREPLIC.
+
+1.4.2.  Responses
+
+      235 article transferred ok
+      335 send article to be transferred.  End with <CR-LF>.<CR-LF>
+      435 article not wanted - do not send it
+      436 transfer failed - try again later
+      437 article rejected - do not try again
+
+2. Newsreader Extensions
+
+   Newsreader extensions are those which are primarily used by
+   newsreading clients.  Following are the descriptions of each
+   newsreader extension commands and the responses which will be
+   returned by those commands.
+
+   Each command is shown in upper case for clarity, although case is
+   ignored in the interpretation of commands by the NNTP server.  Any
+   parameters are shown in lower case.  A parameter shown in [square
+   brackets] is optional.  For example, [GMT] indicates that the
+   triglyph GMT may present or omitted.  A parameter that may be
+   repeated is followed by an ellipsis.  Mutually exclusive parameters
+   are separated by a vertical bar (|) character.  For example,
+   ggg|<message-id> indicates that  a group name or a <message-id> may
+   be specified, but not both.  Some parameters, notably <message-id>,
+   is case specific.  See RFC 1036 for these details.
+
+   Also, certain commands make use of a pattern for selection of
+   multiple news groups.  The pattern in all cases is based on the
+   wildmat [4] format introduced by Rich Salz in 1986.  Arguments
+   expected to be in wildmat format will be represented by the string
+   wildmat.  This format is discussed in detail in section 3.3 of this
+   document.
+
+2.1.1 Extensions to the LIST command
+
+   The original LIST command took no arguments in RFC 977 and returned
+   the contents of the active file in a specific format.  Since the
+   original newsreaders made use of other information available in the
+   news transport software in addition to the active file, extensions to
+
+
+
+Barber                       Informational                      [Page 5]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   the LIST command were created to make that information available to
+   NNTP newsreaders.  There may be other extensions to the LIST command
+   that simply return the contents of a file.  This approach is
+   suggested over the addition of over verbs.  For example, LIST MOTD
+   could be used instead of adding XMOTD.
+
+2.1.2 LIST ACTIVE
+
+   LIST ACTIVE [wildmat]
+
+   LIST ACTIVE is exactly the same as the LIST command specified in RFC
+   977.  The responses and the format should exactly match the LIST
+   command without arguments.  If the optional matching parameter is
+   specified, the list is limited to only the groups that match the
+   pattern.  Specifying a single group is usually very efficient for the
+   server, and multiple groups may be specified by using wildmat
+   patterns (described later in this document), not regular expressions.
+   If nothing is matched an empty list is returned, not an error.  This
+   command first appeared in the UNIX reference version.
+
+2.1.3 LIST ACTIVE.TIMES
+
+   LIST ACTIVE.TIMES
+
+   The active.times file is maintained by some news transports systems
+   to contain information about the when and who created a particular
+   news group.  The format of this file generally include three fields.
+   The first field is the name of the news group.  The second is the
+   time when this group was created on this news server measured in
+   seconds since January 1, 1970.  The third is the email address of the
+   entity that created the news group.  When executed, the information
+   is displayed following the 215 response.  When display is completed,
+   the server will send a period on a line by itself.  If the
+   information is not available, the server will return the 503 error
+   response.  This command first appeared in the UNIX reference version.
+
+2.1.3.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+2.1.4 LIST DISTRIBUTIONS
+
+   LIST DISTRIBUTIONS
+
+   The distributions file is maintained by some news transport systems
+   to contain information about valid values for the Distribution: line
+   in a news article header and about what the values mean.  Each line
+
+
+
+Barber                       Informational                      [Page 6]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   contains two fields, the value and a short explanation on the meaning
+   of the value.  When executed, the information is displayed following
+   the 215 response.  When display is completed, the server will send a
+   period on a line by itself.  If the information is not available, the
+   server will return the 503 error response.  This command first
+   appeared in the UNIX reference version.
+
+2.1.4.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+2.1.5 LIST DISTRIB.PATS
+
+   LIST DISTRIB.PATS
+
+   The distrib.pats file is maintained by some news transport systems to
+   contain default values for the Distribution:  line in a news article
+   header when posting to particular news groups.  This information
+   could be used to provide a default value for the Distribution: line
+   in the header when posting an article.  The information returned
+   involves three fields separated by colons.  The first column is a
+   weight.  The second is a group name or a pattern that can be used to
+   match a group name in the wildmat format.  The third is the value of
+   the Distribution:  line that should be used when the group name
+   matches and the weight value is the highest.  All this processing is
+   done by the news posting client and not by the server itself.  The
+   server just provides this information to the client for it to use or
+   ignore as it chooses.  When executed, the information is displayed
+   following the 215 response.  When display is completed, the server
+   will send a period on a line by itself.  If the information is not
+   available, the server will return the 503 error response.  This
+   command first appeared in INN.
+
+2.1.5.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+2.1.6 LIST NEWSGROUPS
+
+   LIST NEWSGROUPS [wildmat]
+
+   The newsgroups file is maintained by some news transport systems to
+   contain the name of each news group which is active on the server and
+   a short description about the purpose of each news group.  Each line
+   in the file contains two fields, the news group name and a short
+   explanation of the purpose of that news group.  When executed, the
+
+
+
+Barber                       Informational                      [Page 7]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   information is displayed following the 215 response.  When display is
+   completed, the server will send a period on a line by itself.  If the
+   information is not available, the server will return the 503
+   response.  If the optional matching parameter is specified, the list
+   is limited to only the groups that match the pattern (no matching is
+   done on the group descriptions).  Specifying a single group is
+   usually very efficient for the server, and multiple groups may be
+   specified by using wildmat patterns (similar to file globbing), not
+   regular expressions.  If nothing is matched an empty list is
+   returned, not an error.
+
+   When the optional parameter is specified, this command is equivalent
+   to the XGTITLE command, though the response code are different.
+
+      215 information follows
+      503 program error, function not performed
+
+2.1.7 LIST OVERVIEW.FMT
+
+   LIST OVERVIEW.FMT
+
+   The overview.fmt file is maintained by some news transport systems to
+   contain the order in which header information is stored in the
+   overview databases for each news group.  When executed, news article
+   header fields are displayed one line at a time in the order in which
+   they are stored in the overview database [5] following the 215
+   response.  When display is completed, the server will send a period
+   on a line by itself.  If the information is not available, the server
+   will return the 503 response.
+
+   Please note that if the header has the word "full" (without quotes)
+   after the colon, the header's name is prepended to its field in the
+   output returned by the server.
+
+   Many newsreaders work better if Xref: is one of the optional fields.
+
+   It is STRONGLY recommended that this command be implemented in any
+   server that implements the XOVER command.  See section 2.8 for more
+   details about the XOVER command.
+
+2.1.7.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+
+
+
+
+
+
+Barber                       Informational                      [Page 8]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.1.8 LIST SUBSCRIPTIONS
+
+   LIST SUBSCRIPTIONS
+
+   This command is used to get a default subscription list for new users
+   of this server.  The order of groups is significant.
+
+   When this list is available, it is preceded by the 215 response and
+   followed by a period on a line by itself.  When this list is not
+   available, the server returns a 503 response code.
+
+2.1.8.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+2.2 LISTGROUP
+
+   LISTGROUP [ggg]
+
+   The LISTGROUP command is used to get a listing of all the article
+   numbers in a particular news group.
+
+   The optional parameter ggg is the name of the news group to be
+   selected (e.g. "news.software.b").  A list of valid news groups may
+   be obtained from the LIST command.  If no group is specified, the
+   current group is used as the default argument.
+
+   The successful selection response will be a list of the article
+   numbers in the group followed by a period on a line by itself.
+
+   When a valid group is selected by means of this command, the
+   internally maintained "current article pointer" is set to the first
+   article in the group.  If an invalid group is specified, the
+   previously selected group and article remain selected.  If an empty
+   news group is selected, the "current article pointer" is in an
+   indeterminate state and should not be used.
+
+   Note that the name of the news group is not case-dependent.  It must
+   otherwise match a news group obtained from the LIST command or an
+   error will result.
+
+2.2.1  Responses
+
+      211 list of article numbers follow
+      412 Not currently in newsgroup
+      502 no permission
+
+
+
+
+Barber                       Informational                      [Page 9]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.3 MODE READER
+
+   MODE READER is used by the client to indicate to the server that it
+   is a news reading client.  Some implementations make use of this
+   information to reconfigure themselves for better performance in
+   responding to news reader commands.  This command can be contrasted
+   with the SLAVE command in RFC 977, which was not widely implemented.
+   MODE READER was first available in INN.
+
+2.3.1 Responses
+
+      200 Hello, you can post
+      201 Hello, you can't post
+
+2.4 XGTITLE
+
+   XGTITLE [wildmat]
+
+   The XGTITLE command is used to retrieve news group descriptions for
+   specific news groups.
+
+   This extension first appeared in ANU-NEWS, an NNTP implementation for
+   DEC's VMS.  The optional parameter is a pattern in wildmat format.
+   When executed, a 282 response is given followed by lines that have
+   two fields, the news group name (which matches the pattern in the
+   argument) and a short explanation of the purpose of the news group.
+   When no argument is specified, the default argument is the current
+   group name.  When display is completed, the server sends a period on
+   a line by itself.
+
+   Please note that this command and the LIST NEWSGROUP command provide
+   the same functionality with different response codes.
+
+   Since this command provides the same functionality as LIST NEWSGROUP
+   it is suggested that this extension be deprecated and no longer be
+   used in newsreading clients.
+
+   Note that there is a conflict in one of the response codes from
+   XGTITLE and some of the authentication extensions.
+
+2.5.1 Responses
+
+      481 Groups and descriptions unavailable
+      282 list of groups and descriptions follows
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 10]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.6 XHDR
+
+   XHDR header [range|<message-id>]
+
+   The XHDR command is used to retrieve specific headers from specific
+   articles.
+
+   The required parameter is the name of a header line (e.g.  "subject")
+   in a news group article.  See RFC 1036 for a list of valid header
+   lines.  The optional range argument may be any of the following:
+
+               an article number
+               an article number followed by a dash to indicate
+                  all following
+               an article number followed by a dash followed by
+                  another article number
+
+   The optional message-id argument indicates a specific article.  The
+   range and message-id arguments are mutually exclusive.  If no
+   argument is specified, then information from the current article is
+   displayed.  Successful responses start with a 221 response followed
+   by a the matched headers from all matched messages.  Each line
+   containing matched headers returned by the server has an article
+   number (or message ID, if a message ID was specified in the command),
+   then one or more spaces, then the value of the requested header in
+   that article.  Once the output is complete, a period is sent on a
+   line by itself.  If the optional argument is a message-id and no such
+   article exists, the 430 error response is returned.  If a range is
+   specified, a news group must have been selected earlier, else a 412
+   error response is returned.  If no articles are in the range
+   specified, a 420 error response is returned by the server.  A 502
+   response will be returned if the client only has permission to
+   transfer articles.
+
+   Some implementations will return "(none)" followed by a period on a
+   line by itself if no headers match in any of the articles searched.
+   Others return the 221 response code followed by a period on a line by
+   itself.
+
+   The XHDR command has been available in the UNIX reference
+   implementation from its first release.  However, until now, it has
+   been documented only in the source for the server.
+
+
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 11]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.6.1 Responses
+
+      221 Header follows
+      412 No news group current selected
+      420 No current article selected
+      430 no such article
+      502 no permission
+
+2.7 XINDEX
+
+   XINDEX ggg
+
+   The XINDEX command is used to retrieve an index file in the format of
+   originally created for use by the TIN [6] news reader.
+
+   The required parameter ggg is the name of the news group to be
+   selected (e.g. "news.software.b").  A list of valid news groups may
+   be obtained from the LIST command.
+
+   The successful selection response will return index file in the
+   format used by the TIN news reader followed by a period on a line by
+   itself.
+
+   When a valid group is selected by means of this command, the
+   internally maintained "current article pointer" is set to the first
+   article in the group.  If an invalid group is specified, the
+   previously selected group and article remain selected.  If an empty
+   news group is selected, the "current article pointer" is in an
+   indeterminate state and should not be used.
+
+   Note that the name of the news group is not case-dependent.  It must
+   otherwise match a news group obtained from the LIST command or an
+   error will result.
+
+   The format of the tin-style index file is discussed in the
+   documentation for the TIN newsreader.  Since more recent versions of
+   TIN support the news overview (NOV) format, it is recommended that
+   this extension become historic and no longer be used in current
+   servers or future implementations.
+
+2.7.1 Responses
+
+      218 tin-style index follows
+      418 no tin-style index is available for this news group
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 12]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.8 XOVER
+
+   XOVER [range]
+
+   The XOVER command returns information from the overview database for
+   the article(s) specified.  This command was originally suggested as
+   part of the OVERVIEW work described in "The Design of a Common
+   Newsgroup Overview Database for Newsreaders" by Geoff Collyer.  This
+   document is distributed in the Cnews distribution.  The optional
+   range argument may be any of the following:
+
+               an article number
+               an article number followed by a dash to indicate
+                  all following
+               an article number followed by a dash followed by
+                  another article number
+
+   If no argument is specified, then information from the current
+   article is displayed.  Successful responses start with a 224 response
+   followed by the overview information for all matched messages.  Once
+   the output is complete, a period is sent on a line by itself.  If no
+   argument is specified, the information for the current article is
+   returned.  A news group must have been selected earlier, else a 412
+   error response is returned.  If no articles are in the range
+   specified, a 420 error response is returned by the server.  A 502
+   response will be returned if the client only has permission to
+   transfer articles.
+
+   Each line of output will be formatted with the article number,
+   followed by each of the headers in the overview database or the
+   article itself (when the data is not available in the overview
+   database) for that article separated by a tab character.  The
+   sequence of fields must be in this order: subject, author, date,
+   message-id, references, byte count, and line count.  Other optional
+   fields may follow line count.  Other optional fields may follow line
+   count.  These fields are specified by examining the response to the
+   LIST OVERVIEW.FMT command.  Where no data exists, a null field must
+   be provided (i.e. the output will have two tab characters adjacent to
+   each other).  Servers should not output fields for articles that have
+   been removed since the XOVER database was created.
+
+   The LIST OVERVIEW.FMT command should be implemented if XOVER is
+   implemented.  A client can use LIST OVERVIEW.FMT to determine what
+   optional fields  and in which order all fields will be supplied by
+   the XOVER command.  See Section 2.1.7 for more details about the LIST
+   OVERVIEW.FMT command.
+
+
+
+
+
+Barber                       Informational                     [Page 13]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   Note that any tab and end-of-line characters in any header data that
+   is returned will be converted to a space character.
+
+2.8.1 Responses
+
+      224 Overview information follows
+      412 No news group current selected
+      420 No article(s) selected
+      502 no permission
+
+2.9 XPAT
+
+   XPAT header range|<message-id> pat [pat...]
+
+   The XPAT command is used to retrieve specific headers from specific
+   articles, based on pattern matching on the contents of the header.
+   This command was first available in INN.
+
+   The required header parameter is the name of a header line (e.g.
+   "subject") in a news group article.  See RFC 1036 for a list of valid
+   header lines.  The required range argument may be any of the
+   following:
+
+               an article number
+               an article number followed by a dash to indicate
+                  all following
+               an article number followed by a dash followed by
+                  another article number
+
+   The required message-id argument indicates a specific article.  The
+   range and message-id arguments are mutually exclusive.  At least one
+   pattern in wildmat must be specified as well.  If there are
+   additional arguments the are joined together separated by a single
+   space to form one complete pattern.  Successful responses start with
+   a 221 response followed by a the headers from all messages in which
+   the pattern matched the contents of the specified header line.  This
+   includes an empty list.  Once the output is complete, a period is
+   sent on a line by itself.  If the optional argument is a message-id
+   and no such article exists, the 430 error response is returned.  A
+   502 response will be returned if the client only has permission to
+   transfer articles.
+
+2.9.1 Responses
+
+      221 Header follows
+      430 no such article
+      502 no permission
+
+
+
+
+Barber                       Informational                     [Page 14]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.10 The XPATH command
+
+   XPATH <message-id>
+
+   The XPATH command is used to determine the filenames in which an
+   article is filed.  It first appeared in INN.
+
+   The required parameter message-id is the message id of an article as
+   shown in that article's message-id header.  According to RFC 1036
+   [3], all message ids for all articles within the netnews environment
+   are unique, but articles may be crossposted to multiple groups.  The
+   response to an XPATH command will include a listing of all filenames
+   in which an article is stored separated by spaces or a response
+   indicating that no article with the specified message-id exists.  The
+   returned data is only useful if the news client knows the
+   implementation details of the server.  Because of this, it is
+   recommended that client avoid using this command.
+
+2.10.1  Responses
+
+      223 path1[ path2 ...]
+      430 no such article on server
+
+2.11 The XROVER command
+
+   XROVER [range]
+
+   The XROVER command returns reference information from the overview
+   database for the article(s) specified.  This command first appeared
+   in the Unix reference implementation.  The optional range argument
+   may be any of the following:
+
+               an article number
+               an article number followed by a dash to indicate
+                    all following
+               an article number followed by a dash followed by
+                   another article number
+
+   Successful responses start with a 224 response followed by the
+   contents of reference information for all matched messages.  Once the
+   output is complete, a period is sent on a line by itself.  If no
+   argument is specified, the information for the current article is
+   returned.  A news group must have been selected earlier, else a 412
+   error response is returned.  If no articles are in the range
+   specified, a 420 error response is returned by the server.  A 502
+   response will be returned if the client only has permission to
+   transfer articles.
+
+
+
+
+Barber                       Informational                     [Page 15]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   The output will be formatted with the article number, followed by the
+   contents of the References: line for that article, but does not
+   contain the field name itself.
+
+   This command provides the same basic functionality as using the XHDR
+   command and "references" as the header argument.
+
+2.11.1 Responses
+
+      224 Overview information follows
+      412 No news group current selected
+      420 No article(s) selected
+      502 no permission
+
+2.12 XTHREAD
+
+   XTHREAD [DBINIT|THREAD]
+
+   The XTHREAD command is used to retrieve threading information
+   in format of originally created for use by the TRN [6] news
+   reader.
+
+   The command XTHREAD DBINIT may be issued prior to entering
+   any groups to see if a thread database exists.  If it does,
+   the database's byte order and version number are returned
+   as binary data.
+
+   If no parameter is given, XTHREAD THREAD is assumed.
+
+   To use XTHREAD THREAD, a news group must have been selected
+   earlier, else a 412 error response is returned.
+
+   A 502 response will be returned if the client only has
+   permission to transfer articles.  A 503 response is returned
+   if the threading files are not available.
+
+   The format of the trn-style thread format is discussed in
+   the documentation for the TRN newsreader.  Since more recent
+   versions of TRN support the news overview (NOV) format, it
+   is recommended that this extension become historic and no
+   longer be used in current servers or future implementations.
+
+2.12.1 Responses
+
+      288 Binary data to follow
+      412 No newsgroup current selected
+      502 No permission
+      503 program error, function not performed
+
+
+
+Barber                       Informational                     [Page 16]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+3. Other Extensions
+
+3.1 AUTHINFO
+
+   AUTHINFO is used to inform a server about the identity of a user of
+   the server.  In all cases, clients must provide this information when
+   requested by the server.  Servers are not required to accept
+   authentication information that is volunteered by the client.
+   Clients must accommodate servers that reject any authentication
+   information volunteered by the client.
+
+   There are three forms of AUTHINFO in use.  The original version, an
+   NNTP v2 revision called AUTHINFO SIMPLE and a more recent version
+   which is called AUTHINFO GENERIC.
+
+3.1.1 Original AUTHINFO
+
+   AUTHINFO USER username
+   AUTHINFO PASS password
+
+   The original AUTHINFO is used to identify a specific entity to the
+   server using a simple username/password combination.  It first
+   appeared in the UNIX reference implementation.
+
+   When authorization is required, the server will send a 480 response
+   requesting authorization from the client.  The client must enter
+   AUTHINFO USER followed by the username.  Once sent, the server will
+   cache the username and may send a 381 response requesting the
+   password associated with that username.  Should the server request a
+   password using the 381 response, the client must enter AUTHINFO PASS
+   followed by a password and the server will then check the
+   authentication database to see if the username/password combination
+   is valid.  If the combination is valid or if no password is required,
+   the server will return a 281 response.  The client should then retry
+   the original command to which the server responded with the 480
+   response.  The command should then be processed by the server
+   normally.  If the combination is not valid, the server will return a
+   502 response.
+
+   Clients must provide authentication when requested by the server.  It
+   is possible that some implementations will accept authentication
+   information at the beginning of a session, but this was not the
+   original intent of the specification.  If a client attempts to
+   reauthenticate, the server may return 482 response indicating that
+   the new authentication data is rejected by the server.  The 482 code
+   will also be returned when the AUTHINFO commands are not entered in
+   the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO
+   PASS preceding AUTHINFO USER).
+
+
+
+Barber                       Informational                     [Page 17]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   All information is passed in cleartext.
+
+   When authentication succeeds, the server will create an email address
+   for the client from the user name supplied in the AUTHINFO USER
+   command and the hostname generated by a reverse lookup on the IP
+   address of the client.  If the reverse lookup fails, the IP address,
+   represented in dotted-quad format, will be used.  Once authenticated,
+   the server shall generate a Sender:  line using the email address
+   provided by authentication if it does not match the client-supplied
+   From: line.  Additionally, the server should log the event, including
+   the email address.  This will provide a means by which subsequent
+   statistics generation can associate newsgroup references with unique
+   entities - not necessarily by name.
+
+3.1.1.1 Responses
+
+      281 Authentication accepted
+      381 More authentication information required
+      480 Authentication required
+      482 Authentication rejected
+      502 No permission
+
+3.1.2 AUTHINFO SIMPLE
+
+   AUTHINFO SIMPLE
+   user password
+
+   This version of AUTHINFO was part of a proposed NNTP V2
+   specification, which was started in 1991 but never completed, and is
+   implemented in some servers and clients.  It is a refinement of the
+   original AUTHINFO and provides the same basic functionality, but the
+   sequence of commands is much simpler.
+
+   When authorization is required, the server sends a 450 response
+   requesting authorization from the client.  The client must enter
+   AUTHINFO SIMPLE.  If the server will accept this form of
+   authentication, the server responds with a 350 response.  The client
+   must then send the username followed by one or more space characters
+   followed by the password.  If accepted, the server returns a 250
+   response and the client should then retry the original command to
+   which the server responded with the 450 response.  The command should
+   then be processed by the server normally.  If the combination is not
+   valid, the server will return a 452 response.
+
+   Note that the response codes used here were part of the proposed NNTP
+   V2 specification and are violations of RFC 977.  It is recommended
+   that this command not be implemented, but use either or both of the
+   other forms of AUTHINFO if such functionality if required.
+
+
+
+Barber                       Informational                     [Page 18]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+3.1.2.1 Responses
+
+      250 Authorization accepted
+      350 Continue with authorization sequence
+      450 Authorization required for this command
+      452 Authorization rejected
+
+3.1.3 AUTHINFO GENERIC
+
+   AUTHINFO GENERIC authenticator arguments...
+
+   AUTHINFO GENERIC is used to identify a specific entity to the server
+   using arbitrary authentication  or identification protocols.  The
+   desired protocol is indicated by the authenticator parameter, and any
+   number of parameters can be passed to the authenticator.
+
+   When authorization is required, the server will send a 480 response
+   requesting authorization from the client.  The client should enter
+   AUTHINFO GENERIC followed by the authenticator name, and the
+   arguments if any.  The authenticator and arguments must not contain
+   the sequence "..".
+
+   The server will attempt to engage the server end authenticator,
+   similarly, the client should engage the client end authenticator.
+   The server end authenticator will then initiate authentication using
+   the NNTP sockets (if appropriate for that authentication protocol),
+   using the protocol specified by the authenticator name.  These
+   authentication protocols are not included in this document, but are
+   similar in structure to those referenced in RFC 1731 [8] for the
+   IMAP-4 protocol.
+
+   If the server returns 501, this means that the authenticator
+   invocation was syntactically incorrect, or that AUTHINFO GENERIC is
+   not supported.  The client should retry using the AUTHINFO USER
+   command.
+
+   If the requested authenticator capability is not found, the server
+   returns the 503 response code.
+
+   If there is some other unspecified server program error, the server
+   returns the 500 response code.
+
+   The authenticators converse using their protocol until complete.  If
+   the authentication succeeds, the server authenticator will terminate
+   with a 281, and the client can continue by reissuing the command that
+   prompted the 380.  If the authentication fails, the server will
+   respond with a 502.
+
+
+
+
+Barber                       Informational                     [Page 19]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   The client must provide authentication when requested by the server.
+   The server may request authentication at any time.  Servers may
+   request authentication more than once during a single session.
+
+   When the server authenticator completes, it provides to the server
+   (by a mechanism herein undefined) the email address of the user, and
+   potentially what the user is allowed to access.  Once authenticated,
+   the server shall generate a Sender:  line using the email address
+   provided by the authenticator if it does not match the user-supplied
+   From: line.  Additionally, the server should log the event, including
+   the user's authenticated email address (if available).  This will
+   provide a means by which subsequent statistics generation can
+   associate newsgroup references with unique entities - not necessarily
+   by name.
+
+   Some implementations make it possible to obtain a list of
+   authentication procedures available by sending the server AUTHINFO
+   GENERIC with no arguments.  The server then returns a list of
+   supported mechanisms followed by a period on a line by itself.
+
+3.1.3.1 Responses
+
+      281 Authentication succeeded
+      480 Authentication required
+      500 Command not understood
+      501 Command not supported
+      502 No permission
+      503 Program error, function not performed
+      nnn  authenticator-specific protocol.
+
+3.2 DATE
+
+   DATE
+
+   The first NNTP working group discussed and proposed a syntax for this
+   command to help clients find out the current time from the server's
+   perspective.  At the time this command was discussed (1991-1992), the
+   Network Time Protocol [9] (NTP) was not yet in wide use and there was
+   also some concern that small systems may not be able to make
+   effective use of NTP.
+
+   This command returns a one-line response code of 111 followed by the
+   GMT date and time on the server in the form YYYYMMDDhhmmss.
+
+3.2.1 Responses
+
+      111 YYYYMMDDhhmmss
+
+
+
+
+Barber                       Informational                     [Page 20]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+3.3 The WILDMAT format
+
+   The WILDMAT format was first developed by Rich Salz based on the
+   format used in the UNIX "find" command to articulate file names.  It
+   was developed to provide a uniform mechanism for matching patterns in
+   the same manner that the UNIX shell matches filenames.  Patterns are
+   implicitly anchored at the beginning and end of each string when
+   testing for a match.  There are five pattern matching operations
+   other than a strict one-to-one match between the pattern and the
+   source to be checked for a match.  The first is an asterisk (*) to
+   match any sequence of zero or more characters.  The second is a
+   question mark (?) to match any single character.  The third specifies
+   a specific set of characters.  The set is specified as a list of
+   characters, or as a range of characters where the beginning and end
+   of the range are separated by a minus (or dash) character, or as any
+   combination of lists and ranges.  The dash can also be included in
+   the set as a character it if is the beginning or end of the set.
+   This set is enclosed in square brackets.  The close square bracket
+   (]) may be used in a set if it is the first character in the set.
+   The fourth operation is the same as the logical not of the third
+   operation and is specified the same way as the third with the
+   addition of a caret character (^) at the beginning of the test string
+   just inside the open square bracket.  The final operation uses the
+   backslash character to invalidate the special meaning of the a open
+   square bracket ([), the asterisk, backslash or the question mark.
+   Two backslashes in sequence will result in the evaluation of the
+   backslash as a character with no special meaning.
+
+3.3.1 Examples
+
+   a. [^]-] -- matches any single character other than a close square
+               bracket or a minus sign/dash.
+
+   b. *bdc  -- matches any string that ends with the string "bdc"
+               including the string "bdc" (without quotes).
+
+   c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
+               character.
+
+   d. a??d  --  matches any four character string which begins
+                with a and ends with d.
+
+
+
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 21]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+3.4 Additional Headers
+
+   Many NNTP implementations add headers to Usenet articles when then
+   are POSTed via NNTP.  These headers are discussed in this section.
+   None of these headers conflict with those specified in RFC 1036 and
+   should be passed unchanged by Usenet transports conforming to RFC
+   1036.
+
+3.4.1 NNTP-Posting-Host
+
+   This line is added to the header of a posted article by the server.
+   The contents of the header is either the IP address or the fully
+   qualified domain name of the client host posting the article.  The
+   fully qualified domain name should be determined by doing a reverse
+   lookup in the DNS on the IP address of the client.  If the client
+   article contains this line, it is removed by the server before
+   acceptance of the article by the Usenet transport system.
+
+   This header provides some idea of the actual host posting the article
+   as opposed to information in the Sender or From lines that may be
+   present in the article.  This is not a fool-proof methodology since
+   reverse lookups in the DNS are vulnerable to certain types of
+   spoofing, but such discussions are outside the scope of this
+   document.
+
+3.4.2 X-Newsreader and others
+
+
+   There are other lines that are added by clients as well.  Most of
+   these indicate the type of newsreader software that is posting the
+   article.
+
+4.0 Common Implementation Issues
+
+   Many NNTP implementations do not follow the specifications in RFC
+   977.  In this section, some common implementation issues are
+   summarized.
+
+4.1 The Response to the LIST command
+
+   RFC 977 says that the fourth field of the "list of valid newsgroups
+   associated information" returned must be "either 'y' or 'n'
+   indicating whether posting to this newsgroup is allowed ('y') or
+   prohibited ('n').  Most implementations simply output the exact
+   contents of the transport system's active newsgroup list.  For more
+   implementations, the fourth field usually has more values that 'y' or
+   'n'.
+
+
+
+
+Barber                       Informational                     [Page 22]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+4.2 The Required Headers in an Article and the POST command
+
+   RFC 977 notes in section 3.10.1 that articles presented "should
+   include all required header lines." In fact, modern implementations
+   only require From, Subject, and Newsgroups header lines and will
+   supply the rest; further, many implementers believe that it is best
+   for clients to generate as few headers as possible, since clients
+   often do not format other headers correctly.
+
+   This implementation behavior is consistent with both Bnews and Cnews
+   which would supply missing headers for articles directly submitted to
+   them.
+
+4.3 Article Numbering
+
+   RFC 977 does not directly address the rules concerning articles
+   number.  However, the current practice is simple: article numbers are
+   monotonically increasing, articles may disappear, and therefore the
+   high and low water marks returned in a GROUP command should be
+   treated as maximum minima, and minimum maxima, respectively.
+
+4.4 Availability of commands defined in RFC 977
+
+   Some implementations permit administrators to disable commands
+   defined RFC 977.  Some implementations have some set of commands
+   disabled by default.  This means that client implementations cannot
+   depend on the availability of the disabled set of commands.  This
+   increases the complexity of the client and does not encourage
+   implementors to optimize the implementation of commands that don't
+   perform well.
+
+   NEWNEWS is one of the commands frequently disabled.
+
+4.5 The Distribution header and NEWNEWS
+
+   In section 12.4 of RFC 977, the optional distributions argument is
+   described.  This argument, according to RFC 977, would limit the
+   responses to articles that were in newsgroups with prefixes that
+   matched the optional distributions argument.
+
+   Some implementations implement this by matching the Distributions
+   header in articles to the distribution argument.  Others do the match
+   against segments of the newsgroup's name.
+
+   This variation is probably best explained by the evolution of the
+   USENET article format.  At the time RFC 977 was specified, the
+   newsgroup name defined how the group was distributed throughout
+   USENET.  RFC 1036 changed this convention.  So, those that are
+
+
+
+Barber                       Informational                     [Page 23]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   strictly implementing RFC 977 would match the newsgroup name prefix
+   against the distribution argument and only display matches.  Those
+   that implement against the intent of the command (as modified by the
+   redefinition of the article format)would match the Distributions
+   header against the distribution argument and only display those
+   matches.
+
+5.0 Further Work
+
+   With the continued use of NNTP on the Internet, there remains an
+   interest in creating an optimized transport protocol for server-to-
+   server transfers and an optimized client protocol for client-to-
+   server interactions.  There is also considerable interest is building
+   better mechanisms to provide audit information on which news groups
+   are being read by which users.
+
+   An IETF working group has been formed and it is the hope of this
+   author that these issues will be addressed in that forum.
+
+6.0 Security Considerations
+
+   The use of the AUTHINFO is optional.  This command as documented has
+   a number of security implications.  In the original and simple forms,
+   all passwords are passed in plaintext and could be discovered by
+   various forms of network or system surveillance.  The AUTHINFO
+   GENERIC command has the potential for the same problems if a
+   mechanism is used that also passes cleartext passwords.  RFC 1731 [8]
+   discusses these issues in greater detail.
+
+7.0 References
+
+   [1]  Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
+        977, February 1986.
+
+   [2]  Limoncelli, Tom, "Read This Before You Write a Newsreader",
+        http://mars.superlink.net/tal/news-software-authors.html, June,
+        1996.
+
+   [3]  Horton, M. and R. Adams, "Standard for interchange of USENET
+        messages",  RFC 1036, December 1987.
+
+   [4]  Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
+        distribution, UUNET Technologies, Revision 1.10, April, 1992.
+
+   [5]  Robertson, Rob, "FAQ: Overview database / NOV General
+        Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
+        nov.Z, January, 1995.
+
+
+
+
+Barber                       Informational                     [Page 24]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   [6]  Lea, Iain, "FAQ about the TIN newsreader",
+        http://www.cs.unca.edu/~davidson/handouts/tinfaq.html
+
+   [7]  Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
+        2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/
+        software/readers/%5Bnews.software.readers%5D_trn_newsreader
+        _FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
+        -hierarchy/news/software/readers/%5Bnews.software.readers
+        %5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.
+
+   [8]  Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
+        December 1994.
+
+   [9]  Mills, D., "Network Time Protocol (Version 3), Specification,
+        Implementation and Analysis", RFC 1305, March 1992.
+
+8.0 Notes
+
+   DEC is a registered trademark of Compaq Computer Corporation.  UNIX
+   is a registered trademark of The Open Group.  VMS is a registered
+   trademark of Compaq Computer Corporation.
+
+9.0 Acknowledgments
+
+   The author gratefully acknowledges the comments and additional
+   information provided by the following individuals:
+
+   Wayne Davison <davison@armory.com>
+   Chris Lewis <clewis@bnr.ca>
+   Tom Limoncelli <tal@lucent.com>
+   Eric Schnoebelen <eric@egsner.cirr.com>
+   Rich Salz <rsalz@osf.org>
+
+   This work was precipitated by the work of various newsreader authors
+   and newsserver authors which includes those listed below:
+
+   Rick Adams    -- Original author of the NNTP extensions to the RN
+                    newsreader and last maintainer of Bnews
+   Stan Barber   -- Original author of the NNTP extensions to the
+                    newsreaders that are part of Bnews.
+   Geoff Collyer -- Original author of the OVERVIEW database proposal and
+                    one of the original authors of CNEWS
+   Dan Curry     -- Original author of the xvnews newsreader
+   Wayne Davison -- Author of the first threading extensions to the
+                    RN newsreader (commonly called TRN).
+   Geoff Huston  -- Original author of ANU NEWS
+
+
+
+
+
+Barber                       Informational                     [Page 25]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   Phil Lapsey   -- Original author of the UNIX reference
+                    implementation
+   Iain Lea      -- Original maintainer of the TIN newsreader
+   Chris Lewis   -- First known implementor of the AUTHINFO GENERIC
+                    extension
+   Rich Salz     -- Original author of INN
+   Henry Spencer -- One of the original authors of CNEWS
+   Kim Storm     -- Original author of the NN newsreader
+
+10.0 Author's Address
+
+   Stan Barber
+   P.O. Box 300481
+   Houston, Texas, 77230
+
+   EMail: sob@academ.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 26]
+\f
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+11.0 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 27]
+\f