ietf-nntp New draft available
Clive D.W. Feather
clive at demon.net
Tue Sep 2 05:04:33 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
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 at demon.net> | Tel: +44 181 371 1138
Director of | Home: <clive at davros.org> | Fax: +44 181 371 1037
Software Development |
Demon Internet Ltd. |
More information about the ietf-nntp
mailing list