[NNTP] Capabilities in responses (Was: MODE READER)

[Clive D.W. Feather]

Mark Crispin said:
> Sometimes you have to make compromises in order to accomplish a desirable 
> result.  The elimination of several RTTs is a highly desirable result.

I agree. The question is whether we can do so without breaking anything
already there. And I think I can come close.

> A way that this could be gotten around may be to restrict the 
> auto-announced extensions to a certain set which are meaningful for 
> session startup; that is, the extensions for TLS, authentication, and 
> (sigh) MODE READER.

Right now, yes. But will this change? Who knows.

>> What you're talking about is a specific use of what I would call
>> "asynchronous messages" - messages not in immediate response to a command.
> No.  It's piggy-backing additional status information on an existing 
> synchronous response.  Both IMAP and SMTP does this.  SMTP has no 
> "asynchronous messages".

I think this is a terminology thing. What we're looking at is status
changes that are caused by, rather than specified by, commands. I see
notification of these as independent of the main responses; I agree that
technically they're not asynchronous, but a capability for the latter can
be used for the former as well.

>> Our existing response code model doesn't have anywhere to insert
>> asynchronous messages from the server. It can't go in the free text area
>> for the reasons given above, so it needs to go somewhere else.
> What is so special about NNTP that it can not do exactly what IMAP and 
> SMTP did?

What exactly was done, and what was the installed base?

And if a cleaner solution exists, why not use it? [Please answer this
generically, before arguing whether my proposals are cleaner.]

====

Okay, accepting for the moment your view that all we need is piggybacking,
and agreeing that the aim is to reduce the number of round trips, let's see
if we can find a workable compromise.

First, I'd like to reinforce a point which people - including Russ - seem
to have missed (perhaps I didn't put it well). This is *VERY* late in the
day to be making significant changes to the wire protocol, particular
when these changes are forced on all clients whether they like it or not,
and when there seem to be ramifications (e.g. piggybacking on the SASL
completion response) that still aren't clear. Technically these changes
are probably out of scope, and do we really want to be including them
without any test implementations (both client and server)?

Fortunately, it isn't necessary to do this in the core protocol unless.
There's a solution which:
- decouples this from the core standardisation path;
- only invokes the feature on client demand, rather than always;
- doesn't require restricting output to a few "important" extensions
- meets my concerns about uncleanliness;
- costs only one RTT at most compared with your approach, while still
  saving round trips compared with the existing protocol.

The answer is to define this facility as an extension, in a separate
document (though it could be rolled back into the core at a later date).
That does the decoupling. The specific proposal meets the other three
objectives.

====

The proposed extension is called LEAN ("LIST EXTENSIONS automatic
notification"). It defines no new commands.

If LIST EXTENSIONS is invoked with the argument AUTO and the server
supports LEAN, auto-notify mode is activated; this is described below.
[We can either allow NOAUTO to turn off auto mode, or we can not have any
way to turn it off.]

[Um, I've just realized that we need to allow "LIST EXTENSIONS AUTO" in
the core protocol to avoid the need to see if LEAN is supported before
using it.]

In auto mode, any command can generate a 101 response code. This indicates
that the LIST EXTENSIONS output has changed. The new output follows the 101
code, followed by the original response line. LIST EXTENSIONS shows that
auto mode is in effect by using the 101 response itself, followed by a
203 response (since the normal 202 means the list would follow).

    [S] 200 NNTP server ready
    [C] LIST EXTENSIONS AUTO
    [S] 101 Auto mode selected
    [S] _NNTP_ 2
    [S] LEAN
    [S] AUTHINFO USER SASL
    [S] .
    [S] 203
    [C] AUTHINFO USER fred
    [S] 101 New extension list
    [S] _NNTP_ 2
    [S] LEAN
    [S] STREAMING
    [S] .
    [S] 281 Authentication accepted

A POSSIBLE optimisation is to provide a "delta" mode where the server sends
changes to the list rather than a new list. This could be done by flagging
the response, for example with a FULL/DELTA argument to the 101 response
and then + and - prefixes:

    [S] 200 NNTP server ready
    [C] LIST EXTENSIONS AUTO
    [S] 101 FULL Auto mode selected
    [S] _NNTP_ 2
    [S] LEAN
    [S] AUTHINFO USER SASL
    [S] .
    [S] 203
    [C] AUTHINFO USER fred
    [S] 101 DELTA Change extension list
    [S] - AUTHINFO USER SASL
    [S] + STREAMING
    [S] .
    [S] 281 Authentication accepted

But this is an add-on; it's not a core part of my proposal.

====

If Russ is confident that a significant change to the core protocol can be
put through at this stage, my proposal can be rolled into the core
protocol simply by removing the fact that it's an 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            |                            |