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

[Ballot comment]
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."

[Note]: 'Document shepherd: Russ Allbery <rra@stanford.edu><br>Returning to secure positive ballots needed due to AD changes since the document was last reviewed.' added by Scott Hollenbeck

IANA Last Call Comments:
Upon approval of this document the IANA will create a new registry for NNTP capability labels.  This registry will be populated with initial registrations described in this document.

[Ballot discuss]
This document is being held to address an old discuss first entered by Steve Bellovin:

"Are we going to see a standards-track i-d for authentication?  2980 is Informational; this document doesn't provide any authentication.  I might be persuaded that nothing stronger than IP address or DNS name is needed, but 11.3 strongly urges such things.  Should we really approve a protocol document that has no real security *and* says that it's needed?"

The working group is developing two drafts to address the security questions:

draft-ietf-nntpext-tls-nntp, and
draft-ietf-nntpext-authinfo

This document will move forward when the two security docs are ready.

[Ballot comment]
1:      What placeholder?  message-ids were an essential feature of
        the very first version of netnews, to squash duplicates in
        the flooding algorithm.  Nor do I see any text in 977 or 850
        to support that notion.  In fact, Section 3.1.2 of 977 says that
        Message-ID is required, as does Section 2 of 850.

[Ballot discuss]
What is the status of 2980 relative to this document?  Are the extensions listed in it to be included in the IANA registry?

Are we going to see a standards-track i-d for authentication?  2980 is Informational; this document doesn't provide any authentication.  I might be persuaded that nothing stronger than IP address or DNS name is needed, but 11.3 strongly urges such things.  Should we really approve a protocol document that has no real security *and* says that it's needed?

[Ballot comment]
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

[Ballot comment]
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].