ietf-nntp Draft 15 minor items

Clive D.W. Feather clive at demon.net
Thu Jan 3 07:09:47 PST 2002


In general there seem to be a number of blank lines missing that I would
expect to be present. For example, fourth level headings have no blank line
before them.

In general we seem to be inconsistent between using "command" and
"keyword".

Wherever a response is multiline I think we should simply say that it is a
"multiline response following the 2XX response code". Remove the continual
references to the trailing dot. I've tried to do this below but may have
missed some.


Page 5 para 2: the text:
    five octets "CRLF.CRLF"
should be:
    five octets CRLF "." CRLF

Page 5 paras 3 and 7 (concerning the maximum length of a line) would be
better merged.

Page 6 last para is clear that each response code has a fixed set of
parameters. It turns out that each code is either single or multiline, and
this is another principle worth keeping. It should also be noted that 211
and 221 are exceptions to this (but see my separate email about 221).
Proposed change:

    In those cases,
!   to simplify interpretation by the client the number and type of such
!   parameters is fixed for each response code, as is whether or not the
!   code introduces a multi-line response. Any extension MUST follow this
!   principle as well, but note that, for historical reasons, the 211 and
!   221 response codes are exceptions to this. In all other
    cases,

Page 12 section 5.4: the two examples that are not indented as much as the
others don't clearly line up with the text in the right hand column; they
should be moved up one line so as to be beside the first line of the
corresponding description.

Page 13 section 6: include a further paragraph (either before or after the
wildmat one):

    The name "<message-id>" or "message-id" for a command or response
    parameter indicates that it is the message id of an article as
    described in section 9.1. The actual parameter MUST include the angle
    brackets whether or not they are used in the description.

Page 14: delete the line:
    [C] Initial TCP connection completed

Page 15 para 4: this can be deleted now that the command is defined as not
streamable.

Page 19 last para: change "Message ids are defined in ..." to "Message-ids
are as defined in ...".

Page 20 last para: this is supposed to be a bullet list of three items:
  * The high water mark will ... less than the low water mark.
  * All three numbers will be zero.
  * The high water mark is greater ... non-empty group.

Page 21 last para: change this to:
    When a valid group is selected by means of this command, the
!   server MUST set the "current newsgroup" to the selected group and
!   the "current article pointer" to the first article in the group.
    If an invalid ...
This makes it clear that this is a server process, not something the client
needs to do. Equivalent changes are required in LISTGROUP (page 47 para 1).

Page 25 first example: would this be clearer if STAT was used instead of
ARTICLE ?

Page 25 and many other places in the document, "Demo User" is surrounded
by 0x93 and 0x94 rather than double quotes. There may be other funny
characters I've missed.

Page 35 section 9.3: change the text to:
     Article posting is done in one of two modes: individual
!    article posting from news reading clients using POST,
!    and article transfer from other news servers using IHAVE.
or some similar text that ties the two commands to the two uses.

Page 35 section 9.3.1 second paragraph: change "defined above (section 0)"
to "defined in section 4". In the same paragraph, can we change "period" to
"dot", please ?

Page 36 para 1: how can a response be "lost" ? We're talking about broken
connections, so change this to:
    ... it receives an affirmative
!   response from the server. If the session is interrupted before the
!   response is received, it is possible that an affirmative response was
!   sent but has been lost. Therefore, in any subsequent session
    the client SHOULD use
    the same message-id in the article when resending it ...

Page 38: the 435 and 437 responses include character 0x92 instead of an
apostrophe.

Page 40 section 9.4.1 first paragraph: change the first part to:
    The LIST [ACTIVE] command returns a list of valid newsgroups ...
The "first" and "last" fields are the wrong way round.

Page 40 section 9.4.1 second paragraph: the "may have leading zeroes"
contradicts an earlier "SHOULD NOT" (section 9.1). Do we want to comment on
that or remove that bit of 9.4.1 ? I feel it would be better to merge the
rest of that paragraph into the previous one, eliminating the bit about
"number of the last known article".

Pages 41 and 42, sections 9.4.1 and 9.4.2 last paragraphs: change "the
groups that match the pattern" to "the groups whose names match the
wildmat". This isn't just a nitpick: in section 5 "pattern" refers to the
components separated by comma, while "wildmat" refers to the whole thing.

Page 41 last para: I didn't realize RFC numbers had reached 28,000 !
The bit about sending the results is tangled. Here's better wording:
!   ... in RFC 2822. If the information is available it is sent
!   as a multiline response following the 215 response code. If
!   it is not, the server will return the 503 error response.
I think the bit about 501 isn't needed - see my separate messagge about
mandatory and optional commands. If it's kept, "SHOULD" -> "MUST".

Page 42 section 9.4.2.2 first example, there is a spurious space before the
terminating dot.

Page 43 para 1, page 44 para 2, and page 46 para 2: change the text
beginning "When executed" in the same way as specified for page 41.

Page 46 last para, change to:
!   If successful, the server will return a 211 response code followed
!   by a list of article numbers, one per line. The list MUST be in
!   numerical order. If the group is empty the 211 response will be
!   immediately followed by the terminating dot.

Page 55 last para: change to:
    ... The help
!   text will be presented as a multiline textual response.
    This text is not guaranteed to be in any particular format
!   and MUST NOT be used by clients as a replacement for the
    LIST EXTENSIONS command described in section 8.1.

Page 56 section 11.3:
* change "LIST command" to "LIST ACTIVE command" (makes it clear it isn't
  LIST NEWSGROUPS)";
* change "The date is sent as" to "The date is specified as";
* change "Time must also be specified. It must be as" to "The time is
  specified as".

Page 57 last para: change to:
! The message-ids of all articles added to a specific set of newsgroups
! since the given date-time will be listed. The set consists
! of all newsgroups whose name matches the wildmat. The list is sent
! as a multiline response with one message-id per line.
  The
  order of the response has no specific significance and may
  vary from response to response in the same session.
! A message-id MAY appear more than once; if it does so, it has the same
! meaning as if it appeared only once.

Page 58 section 11.4.1: delete "may be a".

Page 58 section 11.4.2: first example needs a terminating dot.

Page 59 para 5: delete "for client use".

Page 60 para 3: this seems to be mostly redundant and a little confusing.
It would suffice to say:
!   A server MUST NOT provide any extension, whether or not listed in
!   the output from LIST EXTENSIONS, unless it is either a registered
!   extension or a private extension.

Page 67 para 2: "the Marshall Rose" ?

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive at davros.org>  | Fax:  +44 20 8371 4037
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |



More information about the ietf-nntp mailing list