-

Since this document updates the NNTP specification to use UTF-8 instead of
ASCII, it would be useful to define the terms "NUL", "TAB", "LF", "CR, and "space" etc.
with reference to UTF-8 instead of to ASCII.  The restrictions to printable
US-ASCII should specify those or refer to a specification for them (in UTF-8
terms, again).

In 3.1., the document says


   Note that texts using an encoding (such as UTF-16 or UTF-32) that may
   contain the octets NUL, LF, or CR other than a CRLF pair cannot be
   reliably conveyed in the above format. However, except when stated
   otherwise, this specification does not require the content to be
   UTF-8 and it is possible for octets above and below 128 to be mixed
   arbitrarily.

Does not make sense to me.  The document describes this as a
request-response protocol using the utf-8 encoding, but allows the
content of responses to be in some other encoding, where some of
those encoding are known not to be reliably conveyed by the
request/response format.

The document says

   Certain responses contain arguments such as numbers and names in
   addition to the status indicator. In those cases, to simplify
   interpretation by the client the number and type of such arguments is
   fixed for each response code, as is whether or not the code
   introduces a multi-line response. Any extension MUST follow this
   principle as well, but note that, for historical reasons, the 211
   response code is an exception to this.

What the exception is not stated at this point in the text;  the next usage is 
in an example, which is thus rendered hard to interpret.

The draft says this:

The content of a header SHOULD be in UTF-8. However, if a server
   receives an article from elsewhere that uses octets in the range 128
   to 255 in some other manner, it MAY pass it to a client without
   modification. Therefore clients MUST be prepared to receive such
   headers and also data derived from them (e.g. in the responses from
   the OVER extension (Section 8.5)) and MUST NOT assume that they are
   always UTF-8.

If a client receives headers in some encoding which it does not
support, what does this MUST mean?

I concluded that I should abstain on this document while reading section 3.4,
and I did not review further

  I do not want to block progress of this specification.  However, the
  security considerations section requires an understanding of XSECRET
  and XENCRYPT which are not described in the document.  Further, the
  XSECRET command seems to have a similar use as AUTHINFO in [RFC2980].