Re: ietf-nntp New draft available
Stan Barber <sob@academ.com> Tue, 02 September 1997 16:08 UTC
Received: from cnri by ietf.org id aa10282; 2 Sep 97 12:08 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 MAA24256 for <ietf-archive@cnri.reston.va.us>; Tue, 2 Sep 1997 12:11:36 -0400 (EDT)
Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.8.5) id LAA24468; Tue, 2 Sep 1997 11:06:55 -0500 (CDT)
Received: from academ.com (sob@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.8.5) with ESMTP id LAA24463 for <ietf-nntp@ANNOUNCER.ACADEM.COM>; Tue, 2 Sep 1997 11:06:54 -0500 (CDT)
Received: (from sob@localhost) by academ.com (8.8.5/8.8.5) id LAA07450; Tue, 2 Sep 1997 11:06:49 -0500 (CDT)
Message-Id: <199709021606.LAA07450@academ.com>
From: Stan Barber <sob@academ.com>
Date: Tue, 02 Sep 1997 11:06:49 -0500
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: "Clive D.W. Feather" <clive@demon.net>, ietf-nntp@academ.com
Subject: Re: ietf-nntp New draft available
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 Good idea. > > Section 4 page 3: surely there MUST be only one GREETING step as well; > there is no way to repeat it. That's not what INN does. Try entering "mode reader" and you will see a new greeting. > > Section 5.1 page 6: the third example is missing a [ at the start. I will fix this in the next release of the document. > > Section 6 page 7: the last paragraph is probably superfluous, and certainly > refers to the wrong place. I will fix this in the next release of the document. > > 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. I will see what I can do about clarifying it. Perhaps Chris can comment on this further. > 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 ... I will rewrite this section once we come to consensus on breaking it into four sections or keeping it as one and clarifying it. > > 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. It will be changed in a new version of the document. > > 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 I will see if I can make the text clearer. I am trying to avoid adding examples until after the text is as clear as possible. > > 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. Good point. You didn't mention it in draft 3, so I didn't put it in this document. > Section 10.4.8.1 page 24: what is the response if there is no such group ? 411 is the response. This will be included in a future release of this document. > Section 10.4.9 page 25: can an empty list be returned ? Good question. What does everyone think? I have not seen this behavior myself. The implementations I am familiar with have a default set of overview information that it will create if overview.fmt is null. They will even collect it directly from the article if there is no overview database. > 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 ? This will be clarified in a future release of the document. > > 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. I agree with the first change. Why the second one? Is there something unclear about the text as written? If so, please be more specific about this. > > 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. Good point. It will be fixed in a future release of the document. > > Add at the end of the last paragraph of the section: > > Also, the same message-id may appear more than once in the list. Ditto. > > 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. I will give it some thought and clarify it in a future release of the document. The intent is for the LIST EXTENSIONS to return the third option you list. > Section 15.2 page 34: there is no 'a' in my email address. This will be fixed in the next release of the document. > Section 15.3 page 34: the expiry date seems a bit previous. Ditto. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.
- 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