ietf-nntp New draft available

Stan Barber sob at academ.com
Tue Sep 2 09:06:49 PDT 1997


> 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 at 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.



More information about the ietf-nntp mailing list