Re: ietf-nntp New draft available
"Clive D.W. Feather" <clive@demon.net> Tue, 02 September 1997 12:06 UTC
Received: from cnri by ietf.org id aa04562; 2 Sep 97 8:06 EDT
Received: from announcer.academ.com (majordomo@ANNOUNCER.ACADEM.COM [198.137.249.60]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA23342 for <ietf-archive@cnri.reston.va.us>; Tue, 2 Sep 1997 08:09:38 -0400 (EDT)
Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.8.5) id HAA23717; Tue, 2 Sep 1997 07:05:09 -0500 (CDT)
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.8.5) with ESMTP id HAA23712 for <ietf-nntp@ANNOUNCER.ACADEM.COM>; Tue, 2 Sep 1997 07:05:07 -0500 (CDT)
Received: from demon.net (internal.mail.demon.net [193.195.224.3]) by academ.com (8.8.5/8.8.5) with ESMTP id HAA05468 for <ietf-nntp@academ.com>; Tue, 2 Sep 1997 07:05:03 -0500 (CDT)
Received: from office.demon.net (office.demon.net [193.195.224.1]) by demon.net with SMTP id NAA16822 for <ietf-nntp@academ.com>; Tue, 2 Sep 1997 13:04:39 +0100 (BST)
Subject: Re: ietf-nntp New draft available
To: ietf-nntp@academ.com
Date: Tue, 02 Sep 1997 13:04:33 +0100
From: "Clive D.W. Feather" <clive@demon.net>
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-ID: <873201873.26424.0@office.demon.net>
Sender: owner-ietf-nntp@academ.com
Precedence: bulk
I've made a fairly rapid pass through the document, and have the following comments. Section 3 page 2: this defines a new version of NNTP, and it should explicitly be stated to do so. Call it (say) NNTP version 2.0. Furthermore, add a command (probably in section 12) to return the supported version: VERSION The VERSION command returns the version of NNTP supported by the server. The successful response contains the supported version number "2.0". Servers conforming to version 1.0 [RFC 977] might not recognise this command, and so a 5xx response should be treated as equivalent to "109 1.0". Responses 109 2.0 NNTP version supported Section 4 page 3: surely there MUST be only one GREETING step as well; there is no way to repeat it. Section 5.1 page 6: the third example is missing a [ at the start. Section 6 page 7: the last paragraph is probably superfluous, and certainly refers to the wrong place. Section 9.1.2 page 12: I don't understand the comment about "reissuing the command that prompted the 350". It *appears* to me that this is saying that *any* command can return a 350 code, even if the specific description doesn't mention it. If not, what does it mean ? The only references to 350 I can find are in the AUTHINFO command itself, and the request for authentication is actually a 205 response from the greeting or MODE READER. Whatever's going on here, it needs rewriting. Section 10.2.1 page 17: I would suggest that the best way to present this is: 10.2.1 ARTICLE, HEAD, BODY, and STAT ARTICLE [<message-id>|nnn] HEAD [<message-id>|nnn] BODY [<message-id>|nnn] STAT [<message-id>|nnn] These commands are identical except that the successful response has a different code and returns different parts of the article: ARTICLE: 220, returns headers and body separated by a blank line HEAD: 221, returns header only with no blank line BODY: 222, returns body only STAT: 223, nothing follows the response Note that STAT does not return a line consisting of a dot, unlike the other three commands. The optional parameter nnn ... Section 10.2.1 page 17: the optional parameter nnn need not be chosen from the range of articles provided when the news group was selected, since a new article may have appeared. For example, GROUP might return a range of 20 to 25, but NEXT can step you on to 26 and ARTICLE 26 would then be valid. Section 10.3.1 page 18 and section 10.3.2 page 19/20: the sequence of events is extremely unclear here. It appears to me that two separate responses are sent to a single command; assuming this is right, text something like the following would be useful: 10.3.1.2 Flow of events Client sends POST OR Client sends POST Server sends 340 Server sends 440 Client sends article Client sends next command Client sends a dot Server sends 240 or 441 Client sends next command and 10.3.2.2 Flow of events Client sends IHAVE <id> OR Client sends IHAVE <id> Server sends 335 Server sends 435 Client sends article Client sends next command Client sends a dot Server sends 235, 436, or 437 Client sends next command Section 10.4.1 page 20: the paragraph beginning "The <first> and <last>" should be replaced by a cross-reference to the discussion in 10.1.1.1. Section 10.4.8.1 page 24: what is the response if there is no such group ? Section 10.4.9 page 25: can an empty list be returned ? Section 10.4.10 page 26: how are the headers from the various articles distinguished ? Can I determine the article numbers from the returned data ? If so, how ? Section 12.4 page 28: change "6 digits" to "6 or 8 digits". Change the last sentence of the same paragraph to: If the first two digits of the year are not specified, the year is taken to be in the range 1951 to 2050 inclusive. Section 12.5 page 29: I understood that the normal format for newsgroups is a set of wildmats: The newsgroups parameter is either a single wildmat or several wildmats separated by commas. Add at the end of the last paragraph of the section: Also, the same message-id may appear more than once in the list. Sections 8 and 13: I am unclear exactly what is returned by the LIST EXTENSIONS command for a given extension. For example, you show an "overview support" extension. Which of the following does LIST EXTENSIONS return ? (1) Overview support (2) OVER (3) OVER possibly the other way round LIST OVERVIEW.FMT possibly interlaced with other names What is the difference between a "keyword" and a "verb" ? When would a keyword mentioned in the reponse have a parameter, or are you taking "OVERVIEW.FMT" to be a parameter ? Do you really mean that some commands have more than one keyword ? I'm not sure exactly how to fix this, but I think that the terminology badly needs cleaning up. Section 15.2 page 34: there is no 'a' in my email address. Section 15.3 page 34: the expiry date seems a bit previous. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 181 371 1138 Director of | Home: <clive@davros.org> | Fax: +44 181 371 1037 Software Development | Demon Internet Ltd. |
- Re: ietf-nntp New draft available Paul Overell
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Chris Lewis
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Stan Barber
- ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Jonathan Grobe
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Paul Overell
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Jack Hudler
- Re: ietf-nntp New draft available Brian Kantor
- Re: ietf-nntp New draft available Paul Overell
- Re: ietf-nntp New draft available Clive D.W. Feather
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Clive D.W. Feather
- Re: ietf-nntp New draft available Paul Overell
- Re: ietf-nntp New draft available Stan Barber