[ietf-nntp] What commands can be implemented?

[Clive D.W. Feather]

What non-core commands can a server implement, and what must it
advertise? This question relates to a comment Russ made earlier this month.

The current text addresses this issue in three places:

Section 5.3.2 (LIST EXTENSIONS):

    The server MUST NOT list the same extension twice in the response, and
    MUST list all supported extensions.

Section 8 (framework for extensions):

    A private extension need not be included in the output of LIST
    EXTENSIONS. A server MAY provide additional keywords - either for new
    commands or new variants of existing commands - as part of a private
    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". 

Section 8.2 (standard extensions):

    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. 

These three texts are not consistent with one another.

Let us start from first principles. The commands implemented by any given
server may be:
(1) a core command in [NNTP]
(2) a command from one of the extensions in [NNTP]
(3) a command from another extension in the IANA registry (e.g. AUTHINFO)
(4) a command in a private extension.

The term "standard extension" means (2) alone; (2) and (3) together are
described as "extension[s] registered with IANA" or similar terms.

The same command could be in all of (2), (3), and (4). For example, OVER
could be defined by [NNTP], by a new UNDER extension in another document,
and by a private extension.

** Do we want to put something in the IANA requirements that two different
registered extensions can't each use the same command name?

** The wording concerning the LIST EXTENSIONS output is not consistent. If a
server does not support any registered extensions, it need not provide the
LIST EXTENSIONS command. However, if it *does* support the command, then
what should the requirements for the output be:
(A) it MUST list all extensions, including private ones;
(B) it MUST list registered extensions and SHOULD list private ones;
(C) it MUST list registered extensions and MAY list private ones.

** We currently say that the names of private extensions SHOULD begin with
an X. Do we want to change that to a MUST, or will it break too many
servers? Or we could say that the name MUST NOT be the same as one in the
IANA registry.  If we leave the present text, how does a client know that
extension "OVER" means the one specified in [NNTP]?

** The 8.2 text currently forbids a private extension providing a command
with the same name as a standard extension. This means that anyone
implementing LIST OVERVIEW.FMT without OVER is non-compliant. Is this what
we want? I guess not; apart from anything else, it could make
implementations retroactively non-compliant if a new extension is
registered. However, we need to say *something* to ensure that if LIST
EXTENSIONS returns "OVER", then the OVER command does what [NNTP] says.

Comments thus far?

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