Network News Transfer Protocol (NNTP)
RFC 3977
Note: This ballot was opened for revision 27 and is now closed.
(Scott Hollenbeck) (was Discuss, Yes) Yes
Comment (2005-06-16)
No email
send info
send info
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."
(Harald Alvestrand) No Objection
Comment (2004-04-15 for -)
No email
send info
send info
Reviewed by Spencer Dawkins, Gen-ART Truly amazing to see this document (close to) finished at last!
(Brian Carpenter) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
(Thomas Narten) No Objection
(Jon Peterson) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
(Alex Zinin) No Objection
(Steven Bellovin) (was Discuss) Abstain
Comment (2004-04-15)
No email
send info
send info
-
(Ted Hardie) Abstain
Comment (2004-04-13 for -)
No email
send info
send info
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
(Russ Housley) Abstain
Comment (2004-04-13 for -)
No email
send info
send info
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].