[ietf-nntp] What commands can be implemented?

Clive D.W. Feather clive at demon.net
Mon Jul 26 07:00:45 PDT 2004


>> Let us start from first principles. The commands implemented by any given
>> server may be:
[...]

In the absence of any other comments, I've implemented Russ's views (all of
which I'm happy with).

Diffs:

Section 3.2:

-Neither this document nor any extension registered with IANA (see
+Neither this document nor any registered extension (see
 Section 8) will specify any response codes of the x9x pattern.

Section 5.3.2 (LIST EXTENSIONS):

 This command MUST be implemented by any server that implements any
-extensions defined in this document or any other extension in the
-IANA registry, and is optional otherwise.
+registered extension, and is optional otherwise.

 The server MUST NOT list the same extension twice in the response,
-and MUST list all supported extensions.
+MUST list all supported registered extensions,
+and SHOULD list all supported private extensions.

Section 8.1 (extensions):

 An extension is either a private extension or else it is included in
-the IANA registry and is defined in an RFC.
+the IANA registry and is defined in an RFC
+(in which case it is a "standard extension" or "registered extension").

 To avoid the risk of a clash with a future
 registered extension, the names of private extensions and commands
-defined by them SHOULD begin with "X".
+defined by them SHOULD begin with "X"
+and MUST NOT be the same as the name of a registered extension.
+
+If the server provides a registered extension (indicated by listing it in
+the output of LIST EXTENSIONS), it MUST implement all of the commands in
+the specification of the extension except for those marked as optional.
+If it does not implement the extension as specified, it MUST NOT list
+the extension in the output of LIST EXTENSIONS under its registered name;
+in this case it MAY, but SHOULD NOT, provide a private extension (not
+listed, or listed with a different name) that implements part of the
+extension or implements the commands of the extension with a different
+meaning.

Section 8.2 (standard extensions):

+N.B. while these extensions are standard extensions, the term includes
+all extensions in the IANA registry, not just these three.

-If the server provides an extension, it MUST implement all of the
-commands in the specification of the extension except for those
-marked as optional.  If it does not provide an extension, it MUST NOT
-implement any of the commands in the specification of that extension.

Section 10 (IANA considerations):

 As described in Section 8, names beginning
 with X are reserved for private use while all other names
-are to be associated with a specification in an RFC
+are expected to be associated with a specification in an RFC
 on the standards-track or
 defining an IESG-approved experimental protocol.
+
+Different entries in the registry MUST use different extension-labels.
+
+Different entries in the registry MUST NOT use the same command name.
+For this purpose, variants distinguished by a second or subsequent
+keyword (e.g. "LIST HEADERS" and "LIST OVERVIEW.FMT") count as different
+commands. If there is a need for two extensions to use the same command,
+a single harmonised specification MUST be registered.

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