[NNTP] LIST EXTENSIONS (again)

[Russ Allbery]

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

>> It's really easy to take a list of extensions and parse it.  It's a bit
>> more annoying when you have to special-case the _NNTP_ extension and
>> parse its arguments and use that to decide what commands are available,
>> when for OVER it's just a regular extension.

> Is it? If I want to use LIST HEADERS, I have to look for HDR in the
> list, whereas if I want to use LIST ACTIVE.TIMES, I have to look for
> LIST with ACTIVE.TIMES as an argument.

Right, but there's a mapping between the extension labels and the
commands.  If I see HDR, I know I can use these commands.  If I see OVER,
I know I can use those commands.  I don't have to look at the parameters
to figure out what commands I can use except for AUTHINFO or LIST
subcommands, which are something of a special case.

> One concern I have is that structuring the document (or, in particular,
> "READER") as a set of extensions will make it incomprehensible to the
> average reader. I believe there is a fundamental distinction between
> capabilities and extensions. POST isn't an extension that some servers
> offer; it's a core facility that is sometimes locked away from the
> dangerous users.

> To be selfish for a moment, I'm the Editor and this document is going
> out with my name on every page. I am not willing to see it be a mess.

I think you were on the right track with a STATUS command, getting away
from the whole extension concept which has turned out to be too limiting
for what we're trying to represent.  How do you feel about going to
CAPABILITY (just because that matches closer what other protocols use) and
calling these capabilities instead of extensions?  Does that make it feel
like less of a mess?

> I'll accept that we have capabilities and extensions, and each gets its
> own line in the LIST EXTENSIONS output (which really really needs
> renaming, but never mind). So there will be separate lines for IHAVE and
> for reading capability, for example. [I think that POST looks better as
> a property of READER, just like HDR MSGID, since it's a subset of
> reading; you can't have POST on its own.]

You can -- you can configure INN that way -- but it's an uncommon
configuration for only very special cases that likely wouldn't be hurt by
just returning 502 to the reader commands.  So that's not necessarily an
argument against what you're proposing, although the reader commands and
the POST command really are independent.

But, for example, an automated system that generates reports by posting
them to a local newsgroup doesn't need read access and is sometimes
configured to only have posting access.

> In return, you accept my concerns about namespace issues and all these
> core capabilities have names outside the extension-label namespace. So
> that means leading underscores, asterisk, !, or anything else that
> people think gives the message "core capability as opposed to
> extension".

The reason why I'm not as worried about the namespace issues is that we
have something that C and POSIX don't have, namely IANA and the ability to
require that people register their use of the namespace.  In essence,
anything that *doesn't* begin with an X is reserved for standard published
by the IETF, which significantly reduces the worries about conflicting
with extensions.  Does that change how you feel at all?

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