Date: Thu, 11 Jul 91 19:28:43 -0400 From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) To: Eliot Cc: ietf-nntp@turbo.bio.net In-Reply-To: Eliot's message of Mon, 8 Jul 91 09:50:45 -0700 (PDT), Subject: Re: Here's the first cut.. Reply-To: tytso@ATHENA.MIT.EDU Address: 308 High Street, Medford, MA 02155 Phone: (617) 395-0154 Well, here's a set of comments. They're not grammatical errors, so I'm sending them to the list, but most of them are fairly nit-picky..... Section 2.6 Response codes The separation of Simple, Status, and Extended Response is a big win, IMHO. However, I think each response needs to be classified as to whether it is a Simple, Status, or Extended Response (perhaps in section 5), and in the case of the Status Reponses, the format of each response code needs to be more tightly specified as to what should be allowed and what shouldn't be allowed. For example, take the response code: 221 article retrieved - head follows Which of the following responses should be considered legal? 221 12 <1234@tsx-11.mit.edu> article retrieved - head follows 221 12 1234@tsx-11.mit.edu article retrieved - head follows 221 12 <1234@tsx-11.mit.edu> OK, bub! Here's them header lines! 221-12 <1234 221 @tsx-11.mit.edu> article retrieved - head follows etc. I know, I'm being picky, but in a protocol spec, I think we need to be careful about such things. Section 2.6.3 In the first example, "S: Send list of Message-ID's" is missing a response code. Section 3.3.2 It should be stated somewhere that response code 451 can appear in response to any command. At least, I'm assuming that's what was intended. In the example, 3.3.3.A, for example, we see the response code 451 in response to an IHAVE command, and 451 is not listed as one of the possible responses to an IHAVE command in section 3.11.1.2. (or in response to any other command, for that matter). Section 3.6.2 One of the possible responses to the NEWNEWS command should be "Permission denied", in case a site wants to stop another site from using nntpxfer. Section 3.7 Do we need to specify quoting rules for the cases when contains a space or other non-printing characters? I don't know if we want to get into the morass about defining double quotes, or backslashing conventions. It might be wise to punt and say that may not contain white space, and if someone wants an option that requires a that might have white space, he/she is responsible for specifying quoting rules. That is a bit lame, though. Section 3.7.1 The second paragraph, last sentence in this section seems to imply (in the last sentence) that the following sequence is required: C: OPTION BINARY=ON BATCH=20000 COMPRESSION=LZW-12 S: 104 BINARY=ON S: 104 BATCH=20000 S: 104 COMPRESSION=OFF instead of what is implied in sections 3.7.2 and 3.7.3. Section 3.11 What happens if the BINARY or IMAGE options are set, and the client sends a "IHAVE " without the bytecount? Is it an error, or should the server fall back to a textual transfer. Section 3.11.4.2 The response code "531 DATA-PATH option not set" should probably be changed to be "531 DATA-PATH or BATCH option not set", and include 531 as one of the possible response codes in section 3.11.3.2. Actually, to allow for future news distribution options, that should probably read "531 Option allowing argumentless IHAVE not set". Section 3.20. See my comments for section 3.11. As I've said, these comments are fairly nit-picking, and were produced after I did a first quick read-through of the draft. All in all, it looks like a very good job on Eliot's part; we should all thank him for all of the work that he's put into it. - Ted