[NNTP] Base document status

[Clive D.W. Feather]

Okay, here's where things are with the base document.

I circulated snapshot 6 a month or so ago. There were some minor comments
and two more contentious ones - some MODE READER stuff and CAPABILITIES
modifiers. The former is now resolved.

I'm not sure how we handle the modifiers question. I'll take this to a
separate thread.

Here's the changes since snapshot 6. I can issue a snapshot 7 if needed,
but I'd rather not if I don't have to.

* Boilerplate stuff, not expanded here.

* 401 response code, add:

    The server MUST NOT use this response code except as specified by the
    definition of the capability in question.

* LISTGROUP was moved from being a separate capability to being an argument
  of READER. The definition of the latter now reads:

  READER
    This capability indicates that the server implements the various
    commands useful for reading clients. If and only if the LISTGROUP
    command is implemented, there MUST be a single argument LISTGROUP.
    If and only if posting is permitted using the POST command, there
    MUST be a single argument POST. (These arguments may appear in
    either order.)

  Also consequential changes in examples.

* MODE-READER capability definition is now:

  MODE-READER
    This capability indicates that the server is mode-switching
    and the MODE READER command is available.

  (second line is new).

* Added to capability modifiers, first paragraph:

    Where the same capability appears both with and without modifiers,
    or with two different sets of modifiers, it indicates an alternative
    - both cases are available simultaneously. Where several modifiers
    appear on a capability line, it indicates that all the properties of
    the individual modifiers apply.

* In the discussion of modifiers beginning with a dash, change from:

    -label   the capability can be enabled by use of the facility with
             this capability label; in particular, -MODE-READER indicates
             that the server is a mode-switching server and the capability
             can be enabled by use of the MODE READER command.
to:

    -label   the capability can be enabled by use of the facility with
             this capability label; the server MUST NOT use this modifier
             except as specified by the definition of the latter
             capability.

    In particular, -MODE-READER indicates that the server is a
    mode-switching server and the capability can be enabled by use of the
    MODE READER command.

    Where several steps are required to make a capability available, the
    modifiers MUST all appear, in the order required (thus -483 -480
    indicates that privacy is required and then authentication).

* In initial IANA registry:

    IHAVE changed to:
      IHAVE command available
    LISTGROUP deleted
    MODE READER changed to:
      Mode-switching server and MODE READER command available
    SASL changed to:
      Supported SASL mechanisms

* In reading-v-transit, added the parenthetic wording in:

    A server MUST advertise either the IHAVE capability or the READER
    capability (or both).

* Section 3.4.2 now reads:

    An implementation MAY, but SHOULD NOT, provide both transit and
    reader facilities on the same server but require the client to select
    which it wishes to use.  Such an arrangement is called a 
    "mode-switching" server. 
     
    A mode-switching server has two modes: 
    o  Transit mode, which applies after the initial connection: 
       *  it MUST advertise the MODE-READER capability;
       *  it MUST advertise the IHAVE capability;
       *  it MUST not advertise the READER capability unless prefixed
          with the -MODE-READER modifier;
       *  it MAY advertise other capabilities with the -MODE-READER
          modifier; if these have other modifiers as well, -MODE-READER
          should be first.
       However, the server MAY cease to advertise the MODE-READER
       capability after the client uses any command except CAPABILITIES.
    o  Reading mode, after a successful MODE READER (Section 5.3)
       command:
       *  it MUST advertise the READER capability;
       *  it MAY advertise the IHAVE capability;
       *  it MUST not advertise the MODE-READER capability unless
          prefixed with the -- modifier;
       *  it SHOULD advertise, without the -MODE-READER modifier, any
          other capabilities it was advertising with that modifier.

    A client SHOULD only issue a MODE READER command to a server if it is
    advertising the MODE-READER capability without a modifier.  If the
    server does not support CAPABILITIES (and therefore does not conform
    to this specification), the client MAY use the following heuristic:
    o  if the client wishes to use any "reader" commands, it SHOULD use
       the MODE READER command immediately after the initial connection;
    o  otherwise it SHOULD NOT use the MODE READER command.
    In each case it should be prepared for some commands to be
    unavailable that would have been available if it had made the other
    choice.

* Wildmat syntax in section 4 is marked as being an extract from the formal
  syntax later on.

* Initial connection tagged as non-pipelineable.

* In CAPABILITIES, added the last 4 words in:

    The response generated by this command MAY change during a session
    because of other state information (which in turn may be changed by
    the effects of other commands or by external events).

* In CAPABILITIES, append the second line in:

    The server MUST NOT list the same capability twice in the response
    with no modifiers or with the same set of modifiers.

* In MODE READER, change:

    The client MUST NOT send this command after any other command except
    CAPABILITIES (in particular, it MUST NOT send this command twice in a
    session); if it does so, the server MAY violate this specification
    even if it returns a successful response (for example, the server MAY
    forget the currently selected newsgroup or change its privacy or
    authentication status).
to:
    The client MUST NOT issue MODE READER more than once in a session
    or after any security or privacy commands are issued. When the MODE
    READER command is issued, the server MAY reset its state to that
    immediately after the initial connection before switching mode.

* Added command-datastream and UNDEFINED to the syntax.

* Syntax bug-fix: article-ref and range-ref now don't include the
  leading WS, which is instead made explicit in the syntax. Before the
  changes, OVER needed two white space characters before the range-ref!

* Trivial consequential changes to the above.

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