[NNTP] LIST EXTENSIONS (again)

[Russ Allbery]

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

> We've been through this before. NEWNEWS was mandatory in 977 and we
> agreed that there was no reason to change it.

Good point.  Maybe there's no reason to allow servers to disable it any
more (or at least to disable it frequently enough that it's worth special
note in LIST EXTENSIONS).

> We indicate POST through the initial greeting (and MODE
> READER). However, authentication could change this, so I'd be in favour
> of a POST argument to the _NNTP_ extension label.

The initial greeting has been a complete mess for years.  An extension
would be much more reliable and much more consistent.

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

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

In my mind, extension arguments are there to express some sort of
additional information about the extension other than just whether or not
it's available.  For AUTHINFO, this is what authentication mechanisms are
supported.  For OVER, this is whether OVER on a message ID is supported.
Whether POST, IHAVE, or reader commands are available doesn't feel to me
like the same sort of thing at all; in fact, that seems parallel to OVER
or HDR or the other extensions that are part of the list like any other.

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.  We wouldn't generally call that a fully-functional NNTP
server, but from a client perspective it looks just like any other one (it
just doesn't advertise the IHAVE capability).

> Can I make a proposal here? It might sound odd, but bear with me.

> *IF* an SASL security layer is negotiated, the server replies with two
> responses:
> * a 180 response meaning "security layer negotiated"
> * the 281 or 283 response as normal
> with the security layer coming into effect at the end of the 180, *not* the
> 28x.

I'm really leery of sending two responses in response to a command.  Other
NNTP commands don't do that; we'd be adding a new style of response (since
you're not sending the terminating .CRLF of a multiline response either).

After reading all this discussion, I'm becoming inclined to just give
further attempts to reduce the RTTs for an initial client connection a
pass for the time being, except possibly for putting something into the
200 response.  I know that in an ideal world STARTTLS or SASL should have
had some way of communicating this sort of information after completion,
but none of the other protocols do this (except IMAP, which has a
capability for out of order responses that we don't have).

We've been brainstorming, which is good, but we also need to limit our
sights a little so that we can get something published, because right now
the situation with NNTP is hideous and we need to at least get some sort
of standard out there for people to use now.  Most of these decisions
aren't final, and we can always revisit this and come up with some neat
solution later on provided we don't trap ourselves in a corner.

It sounds like providing extensions information as part of 281 or 283
doesn't work from a protocol standpoint because that response is not
protected, which means that there really isn't anything that we can say in
the existing documents (without changing NNTP in fundamental ways like
returning multiple responses) that helps or hurts for solving this problem
down the road.

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