ietf-nntp Section 8

[Clive D.W. Feather]

> 8. The CAPABILITIES DISCOVERY Step

This is the only command I can find where the responses aren't explained as
a group. I don't see the current arrangement as particularly easy to read.
Here's a proposed rewrite:

  8. The CAPABILITIES DISCOVERY Step

  An NNTP client that wishes to use extensions to NNTP can query the
  server to determine which extensions are available. This is done with
  the LIST EXTENSIONS command.

[Here and elsewhere I've changed "a client NNTP" to "an NNTP client", since
the former doesn't make sense.]

  If a particular extension is unavailable, the client can attempt to
  work around it or it may wish to terminate the session.

  See section 12 for further discussion of extensions.

  8.1  LIST EXTENSIONS

  The LIST EXTENSIONS command allows a client to determine which
  extensions are supported by the server.

  This command MAY be issued at anytime during a session. It is
  not required that the client issues this command before
  attempting to make use of any extension. The response
  generated by this command MAY change during a session because
  of other state information. However, an NNTP client MUST NOT
  cache (for use in another session) any information returned if
  the LIST EXTENSIONS command succeeds. That is, an NNTP client
  is only able to get the current and correct information
  concerning available extensions during a session by issuing a
  LIST EXTENSIONS command during that session and processing
  that response.

  A successful response is followed by a list of extensions, one per line.
  Each line MUST begin with exactly one space

[What's the point of this ? Despite what the draft says, it can't be to
prevent confusion with the terminating dot as that's what dot stuffing
is for. Is it too late to change it ?]

                                              followed by an
  extension-label and optionally one or more parameters (separated by
  single spaces). The extension-label and the meaning of the parameters
  will be specified as part of the definition of the extension. The
  extension-label will be in uppercase.

[I see no point in making it "nominally case insensitive".]

  The server MUST NOT list the same extension twice in the response,
  and MUST list all supported extensions. The order in which the
  extensions are listed is not significant. The server need not even
  consistently return the same order.

  If the server does not support any extensions, it SHOULD return a 402
  failure response but MAY return an empty list instead.

[The following text should be moved to section 12 and edited appropriately:

  The extension-label to be used in the
  response to the LIST EXTENSIONS command will be specified as
  each new extension is added to the NNTP command set.  Often it
  will be the name of a new command added; however this IS NOT
  required.  In fact, it IS NOT required that a new feature
  actually adds a new command or keyword.  Any parameters
  included are to be specified with the definition of the
  command concerned.

  Except where stated otherwise, the commands in this document
  are understood (even if not supported) by all servers and are
  not described in the list of features returned by the LIST
  EXTENSIONS command.
]
 
  8.1.1  Responses

  202        extension list follows (multiline)
  400        service about to terminate
  402        no extensions available
  502        [no meaning given]
  503        unable to list extensions

  Following a 503 response an extension might still be available, and
  the client MAY attempt to use it.

  The LIST EXTENSIONS command is optional, and a server MAY issue a 500
  or 501 response to it.

[I've omitted text like the following:

  Text following the return code on the first line of the reply
  is free form, and not interpreted, and has no practical use,
  as this text is not expected to be revealed to end users.  The
  syntax of other reply lines is precisely defined, and if
  present, MUST be exactly as specified.

  The end of the list is defined by the usual period on a line
  by itself.
 
as this just copies the rules in section 4.1.]


  8.1.2  LIST EXTENSION examples

  Example of a successful response:
 
          [C] LIST EXTENSIONS
 
          [S] 202 Extensions supported:
 
          [S]  OVER
 
          [S]  PAT
 
          [S]  LISTGROUP
 
          [S] .
 
  The particular extensions shown here are simply examples of
  what might be defined in other places, and no particular meaning
  should be attributed to them.

[I'll send a separate message about 400 and 502 responses.]

-- 
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 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646