[NNTP] LIST EXTENSIONS (again)

[Clive D.W. Feather]

Russ Allbery said:
>> They're arguments. The model I have is a single "core capabilities" line
>> in the LIST EXTENSIONS output.
> This I'm not sure I understand the reason for.
>
> Looking at this from the perspective of a client, I just want to know
> what's available to me to use.  I don't really care about the distinction
> between the core protocol and extensions; for all that I care, POST could
> be considered an extension.  I just want to know whether I can use it or
> not.

Agreed.

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

> It seems like it would be a lot more
> straightforward to just say that there's a POST capability that we
> advertise if POST is accepted, there's an IHAVE capability that we
> advertise if IHAVE is accepted, and there's a READER capability that we
> advertise if reader commands are allowed.

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.

> The whole distinction of what's an extension and what isn't is
> fundamentally arbitrary anyway -- the only real distinction is that
> extensions are things that are optional to implement.  In that sense,
> IHAVE is actually an extension, since you can write a standalone NNTP
> server that doesn't take any external feeds without ever writing an IHAVE
> implementation.

Except that if you're writing a transit server, you *have* to provide IHAVE
to make things work at all.

However, I'll offer you a compromise.

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

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

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