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