[ietf-nntp] What commands can be implemented?

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

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

Hurm.  I'm not hugely fond of drawing a distinction between (2) and (3),
although I expect it won't matter all that much.  (Or, rather, I think a
"standard extension" should be equivalent to "an extension specified by a
standards-track RFC".)

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

Yes, I think so.  To me, that's a large part of the point of the registry,
to avoid having conflicting commands.  I'm trying to think of cases where
that would cause problems, and I can't think of any; if an extension has
varients that change the meanings of its commands, it seems like those
should be specified as parameters in the LIST EXTENSIONS output.

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

My preference would be (B).

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

I think we need to leave it as a SHOULD to handle the case of, say, a
server implementing OVER right now, before the extension has been formally
accepted by IANA.  SHOULD gives the right tone -- don't do it unless you
have some compelling reason, like being fairly certain that it's about to
be standardized under that name.

> Or we could say that the name MUST NOT be the same as one in the IANA
> registry.

I think this is a good idea.  Say that it SHOULD begin with an X and MUST
NOT conflict with an extension in the IANA registry.

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

Right, I don't like this too much.

> However, we need to say *something* to ensure that if LIST EXTENSIONS
> returns "OVER", then the OVER command does what [NNTP] says.

That seems like a separate question.  If LIST EXTENSIONS returns a
particular extension, then the commands specified by that extension must
work as specified.  If the server has a LIST OVERVIEW.FMT command without
OVER, it can't advertise the OVER extension, but it can still continue to
have a LIST OVERVIEW.FMT command.

Does that make sense?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>