[NNTP] Base document status

Clive D.W. Feather clive at demon.net
Thu Feb 10 00:20:40 PST 2005 

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.

-- 
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            |                            |

More information about the ietf-nntp mailing list