Network News Transfer Protocol (NNTP)
draft-ietf-nntpext-base-27

Note: This ballot was opened for revision 27 and is now closed.

(Scott Hollenbeck; former steering group member) (was Discuss, Yes) Yes

Late-breaking note from the WG:

"Just in case the base doc gets spun again, the title for the NNTP-STREAM 
reference is incorrect (cut-n-paste error), and the NNTP-AUTH, NNTP-TLS 
and NNTP-STREAM file revisions are all out of date."

(Alex Zinin; former steering group member) No Objection

(Allison Mankin; former steering group member) No Objection

(Bert Wijnen; former steering group member) No Objection

(Bill Fenner; former steering group member) No Objection

(Brian Carpenter; former steering group member) No Objection

(David Kessens; former steering group member) No Objection

(Harald Alvestrand; former steering group member) No Objection

Reviewed by Spencer Dawkins, Gen-ART
Truly amazing to see this document (close to) finished at last!

(Jon Peterson; former steering group member) No Objection

(Margaret Cullen; former steering group member) No Objection

(Mark Townsley; former steering group member) No Objection

(Thomas Narten; former steering group member) No Objection

(Russ Housley; former steering group member) Abstain

  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].

(Steven Bellovin; former steering group member) (was Discuss) Abstain

-

(Ted Hardie; former steering group member) Abstain

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