Subject: [NNTP] Base document status

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 9 Feb 2005 11:17:23 +0000

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:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Russ Allbery <[email-masked]>
Date: Wed, 09 Feb 2005 14:44:25 -0800

>     A server MUST advertise either the IHAVE capability or the READER

Might it not advertise only an authentication capability and nothing else
until after authentication?

     
>        *  it MUST advertise the IHAVE capability;

Similar problem here with authentication.

>        *  it MUST advertise the READER capability;

And here.

I'm not sure the best way to rephrase it taking into account capabilities
that may not be available until after authentication.  Maybe we can omit
the bits about having to advertise IHAVE or READER and stick with just the
rules for advertising MODE-READER and the MUST NOT restrictions?

Other than that, it looks good to me.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 10 Feb 2005 07:05:49 +0000

> until after authentication?

Oh f*$%&#. You're quite right.

> that may not be available until after authentication.

This text derives from the earlier idea that a server was reader-only,
transit-only, both, or mode-switching. After all the changes, that's how it
ended up.

In fact, the requirement that we want there is:

    Except as an effect of the MODE READER command on a mode-switching
    server, once a server advertises either or both of the IHAVE or
    READER capabilities, it MUST NOT cease to advertise them later in the
    session.

I've changed it to that, and I'll reword the other stuff accordingly.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 10 Feb 2005 08:20:40 +0000

I'm going to write answers in the modifier thread, but it's already clear
that I'm at variance with everyone else. So I've taken them out of the
draft. If we think there's anything to salvage, it can go back in during
last call.

I've sent the draft to the I-D editor and made it available on my web site
at:

<http://www.davros.org/nntp-texts/draft25.txt>
<http://www.davros.org/nntp-texts/draft25.html>

Here's a list of further changes since my message yesterday.

[In 3.3.1]

- Each capability line consists of three parts:
- (1) Zero or more modifier tokens;
-     each such token begins with a character other than a letter or digit.
-     See [cross-ref] for more information about capability modifiers.
+ Each capability line consists of:
+
- (2) The capability label, which is a keyword indicating the capability.
+  o  The capability label, which is a keyword indicating the capability.
      A capability label may be defined by this specification or a
      successor, or may be defined by an extension.
- (3) Zero or more tokens
+  o  The label is then followed by zero or more tokens,
      which are arguments of the capability.
      The form and meaning of these tokens is specific to each capability.

[...]

+ Note that a capability line can only begin with a letter.
+ Lines beginning with other characters are reserved for future
+ versions of this specification. In order to inter-work with such versions,
+ clients MUST be prepared to receive lines beginning with other characters
+ and MUST ignore any they do not understand.

[In 3.3.2]

  MODE-READER
      This capability indicates that the server is mode-switching and the
-     MODE READER command is available.
+     MODE READER command needs to be used to enable the READER capability.

[Delete 3.3.3 "Capability modifiers" and renumber subsequent subsections.]

[In 3.3.4, was 3.3.5]

- IANA is requested to maintain a registry of NNTP capability labels and
- capability modifiers.
+ IANA is requested to maintain a registry of NNTP capability labels.
  All capability labels in the registry MUST be keywords and MUST NOT
  begin with X.
- All capability modifiers in the registry MUST NOT begin with a letter
- or digit.

[Table heading changed and modifiers removed.]

[In 3.4.1]

- A server MUST advertise either the IHAVE capability or the READER
- capability (or both). Except as an effect of the MODE READER command
- (see below), it MUST NOT change which of these it advertises during
- a session.
+ Except as an effect of the MODE READER command on a mode-switching
+ server, once a server advertises either or both of the IHAVE or READER
+ capabilities, it MUST NOT cease to advertise them later in the session.

[In 3.4.2]

  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 MUST NOT advertise the READER capability.
-    *  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 not advertise the MODE-READER capability;
     *  it MUST advertise the READER capability;
-    *  it MAY advertise the IHAVE capability;
+    *  it MAY NOT advertise the IHAVE capability even if it was
+       advertising it in transit mode.
-    *  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.
+ advertising the MODE-READER capability.

[In 5.2.2]

- The server MUST NOT list the same capability twice in the response
- with no modifiers or with the same set of modifiers.
+ The server MUST NOT list the same capability twice in the response,
+ even with different arguments.

[In 5.2.3]

- Example of a server using a modifier to show that posting is available
- after authentication:
-    [C] CAPABILITIES
-    [S] 101 Capability list:
-    [S] VERSION 2
-    [S] READER
-    [S] -480 READER POST
-    [S] LIST ACTIVE NEWSGROUPS
-    [S] AUTHINFO SASL
-    [S] SASL GSSAPI
-    [S] .

[In 5.3.3]

- Example of use of the MODE READER command on a transit server:
+ Example of use of the MODE READER command on a transit-only server
+ (which therefore does not providing reading facilities):

[...]

  Example of use of the MODE READER command on a mode-switching server:
     [C] CAPABILITIES
     [S] 101 Capability list:
     [S] VERSION 2
     [S] IHAVE
     [S] MODE-READER
-    [S] -MODE-READER READER
-    [S] -MODE-READER STARTTLS
-    [S] -MODE-READER -483 AUTHINFO USER
     [S] .
     [C] MODE READER
     [S] 200 Reader mode, posting permitted
     [C] CAPABILITIES
     [S] 101 Capability list:
     [S] VERSION 2
-    [S] -- IHAVE
-    [S] -- MODE-READER
     [S] READER
     [S] LIST ACTIVE NEWSGROUPS
     [S] STARTTLS
-    [S] -483 AUTHINFO USER
     [S] .
- In this case the server offers TLS privacy, and authentication on a
- secured connection, in its reading mode but not its transit mode.
+ In this case the server offers (but does not require) TLS privacy
+ in its reading mode but not its transit mode.

[In 9.4]

-   capability-line = *(capability-modifier WS) capability-entry
+   capability-line = capability-entry
    capability-entry = X-capability-entry
-   capability-modifier = X-capability-modifier
    X-capability-entry = capability-label *(WS capability-argument)
-   X-capability-modifier = P-NOTALNUM *P-CHAR
    capability-label = keyword
    capability-argument = token

[...]

- This syntax defines the specific capability modifiers described in this
- specification.
-
-   capability-modifier =/ capa-mod-unavailable
-   capa-mod-unavailable = "--" / "-480" / "-483" / "-" keyword

[In 9.7]

-   P-NOTALNUM = PUNCT / UTF8-non-ascii
[...]
-   PUNCT = %x21-2F / %x3A-40 / %x5B-60 / %x7B-7E

[In 9.8]

- capability-modifier
-    for each new capability modifier - the syntax of each entry MUST be
-    compatible with the definition of <X-capability-modifier>;

[...]

  it should be noted that:
- o  the non-terminals <command-line>, <command-continuation>, <response>,
-    and <multiline-response-content>
+ o  the non-terminals <command-line>, <command-datastream>,
+    <command-continuation>, <response>, and <multiline-response-content>
  describe basic concepts of the protocol and are not referred to by any
  other rule;

[In 10]

- This specification requires IANA to keep a registry of capability labels
- and capability modifiers.
+ This specification requires IANA to keep a registry of capability labels.

[...]

- Different entries in the registry MUST use different capability labels
- or capability modifiers.
+ Different entries in the registry MUST use different capability labels.