[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