zilinlin/RFC2PSM huggingface dataset:
Section 1. Introduction

This document specifies the Network News Transfer Protocol (NNTP),
   which is used for the distribution, inquiry, retrieval, and posting
   of Netnews articles using a reliable stream-based mechanism.  For
   news-reading clients, NNTP enables retrieval of news articles that
   are stored in a central database, giving subscribers the ability to
   select only those articles they wish to read.
   The Netnews model provides for indexing, cross-referencing, and
   expiration of aged messages.  NNTP is designed for efficient
   transmission of Netnews articles over a reliable full duplex
   communication channel.
   Although the protocol specification in this document is largely
   compatible with the version specified in RFC 977 [RFC977], a number
   of changes are summarised in Appendix D.  In particular:
   o  the default character set is changed from US-ASCII [ANSI1986] to
      UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8);
   o  a number of commands that were optional in RFC 977 or that have
      been taken from RFC 2980 [RFC2980] are now mandatory; and
   o  a CAPABILITIES command has been added to allow clients to
      determine what functionality is available from a server.
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
   An implementation is not compliant if it fails to satisfy one or more
   of the MUST requirements for this protocol.  An implementation that
   satisfies all the MUST and all the SHOULD requirements for its
   protocols is said to be "unconditionally compliant"; one that
   satisfies all the MUST requirements but not all the SHOULD
   requirements for NNTP is said to be "conditionally compliant".
   For the remainder of this document, the terms "client" and "client
   host" refer to a host making use of the NNTP service, while the terms
   "server" and "server host" refer to a host that offers the NNTP
   service.
1.1.  Author's Note
   This document is written in XML using an NNTP-specific DTD.  Custom
   software is used to convert this to RFC 2629 [RFC2629] format, and
   then the public "xml2rfc" package to further reduce this to text,
   nroff source, and HTML.
   No perl was used in producing this document.
Section 2. Notation

The following notational conventions are used in this document.
     UPPERCASE     indicates literal text to be included in the
                   command.
     lowercase     indicates a token described elsewhere.
     [brackets]    indicate that the enclosed material is optional.
     elliptical    indicates that the argument may be repeated any
     ... marks     number of times (it must occur at least once).
     vertical|bar  indicates a choice of two mutually exclusive
                   arguments (exactly one must be provided).
   The name "message-id" for a command or response argument indicates
   that it is the message-id of an article as described in Section 3.6,
   including the angle brackets.
   The name "wildmat" for an argument indicates that it is a wildmat as
   defined in Section 4.  If the argument does not meet the requirements
   of that section (for example, if it does not fit the grammar of
   Section 4.1), the NNTP server MAY place some interpretation on it
   (not specified by this document) or otherwise MUST treat it as a
   syntax error.
   Responses for each command will be described in tables listing the
   required format of a response followed by the meaning that should be
   ascribed to that response.
   The terms "NUL", "TAB", "LF", "CR, and "space" refer to the octets
   %x00, %x09, %x0A, %x0D, and %x20, respectively (that is, the octets
   with those codes in US-ASCII [ANSI1986] and thus in UTF-8 [RFC3629]).
   The term "CRLF" or "CRLF pair" means the sequence CR immediately
   followed by LF (that is, %x0D.0A).  A "printable US-ASCII character"
   is an octet in the range %x21-7E.  Quoted characters refer to the
   octets with those codes in US-ASCII (so "." and "<" refer to %x2E and
   %x3C) and will always be printable US-ASCII characters; similarly,
   "digit" refers to the octets %x30-39.
   A "keyword" MUST consist only of US-ASCII letters, digits, and the
   characters dot (".") and dash ("-") and MUST begin with a letter.
   Keywords MUST be at least three characters in length.
   Examples in this document are not normative but serve to illustrate
   usages, arguments, and responses.  In the examples, a "[C]" will be
   used to represent the client host and an "[S]" will be used to
   represent the server host.  Most of the examples do not rely on a
   particular server state.  In some cases, however, they do assume that
   the currently selected newsgroup (see the GROUP command,
   Section 6.1.1) is invalid; when so, this is indicated at the start of
   the example.  Examples may use commands or other keywords not defined
   in this specification (such as an XENCRYPT command).  These will be
   used to illustrate some point and do not imply that any such command
   is defined elsewhere or needs to exist in any particular
   implementation.
   Terms that might be read as specifying details of a client or server
   implementation, such as "database", are used simply to ease
   description.  Provided that implementations conform to the protocol
   and format specifications in this document, no specific technique is
   mandated.
Section 11. IANA Considerations

This specification requires IANA to keep a registry of capability
   labels.  The initial contents of this registry are specified in
   Section 3.3.4.  As described in Section 3.3.3, labels beginning with
   X are reserved for private use, while all other names are expected to
   be associated with a specification in an RFC on the standards track
   or defining an IESG-approved experimental protocol.
   Different entries in the registry MUST use different capability
   labels.
   Different entries in the registry MUST NOT use the same command name.
   For this purpose, variants distinguished by a second or subsequent
   keyword (e.g., "LIST HEADERS" and "LIST OVERVIEW.FMT") count as
   different commands.  If there is a need for two extensions to use the
   same command, a single harmonised specification MUST be registered.