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

[Clive D.W. Feather]

Mark Crispin said:
>> The problem is the other way round: a conforming RFC 977 server can already
>> produce such responses with meaningless contents.
> It is not, however, particularly likely that an RFC 977 is going to 
> produce such a response which contains the "NNTPv2" capability.

It doesn't matter; you can't rely on it. That's building on sand, not
drawing a line in it :-)

There's also the problem that response lines are limited in length and
there may not be room for the message as well as the existing response.

====

I've done some thinking about this and come to some conclusions.

What you're talking about is a specific use of what I would call
"asynchronous messages" - messages not in immediate response to a command.
IIRC, IMAP has these as a general possibility, as does (in a different
area) the X11 protocol.

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. For example,
a response line beginning "!" could indicate an asynchronous message (I
thought of using a response code range like 7xx, but it doesn't work well).
However, if we start sending these to existing clients they will get very
very confused.  This means that the client needs to explicitly indicate
that it is willing to receive these messages.

At which point I realize that we're talking about an extension to the
protocol which can be specified just like any other extension. So we don't
have to include it in the core document and we don't even have to agree it
right now. That means we don't need to let it affect the present work.

====

Having said that, and purely as a proof of concept, I'll sketch out such an
extension to show that it does what you want. I'll call it "EVENTS", having
pinched the name from X11.

If the extension is supported, LIST EXTENSIONS reports it as EVENTS
followed by one or more keywords indicating the event types available.
The initial set is:
  EXTENSIONS - report changes to the available set of extensions since
               the last LIST EXTENSIONS in this session.
  GROUPSIZE  - report a change in the low and/or high water marks of the
               current group.
  TELLUSER   - the server wishes the user to be informed of something.

A client indicates its willingness to receive events by issuing the EVENTS
command followed by the set of events it wants. "*" indicates all events;
an empty argument list cancels all previous requests. Response codes:
  206 - request successful
  503 - unsupported event type

An event is indicated by a response line beginning "!", instead of a three
digit response code, at *any* place where the server can send a response
(including both places in two-stage commands). A single-line event begins
with "! ", while a multi-line one begins "!. " and is dot-stuffed and
-terminated. The event is followed by another event (without limit) or
the actual response.

Initial list of events:

EXTENSIONS events. In the following, the "current extensions knowledge"
is the server's understanding of what the client knows about the available
extensions. This is an empty set at connection setup, and is set to the
response whenever a LIST EXTENSIONS command is successfully issued.

!. EXTENSIONS !
    The current extensions knowledge is replaced by the following material.
    This MUST be used after successful authentication or security level
    changes and whenever the server knows that the knowledge is wrong; this
    implies it will occur as part of the response to an EVENTS command if
    no LIST EXTENSIONS has been issued.

!. EXTENSIONS +
    The following material is added to the current extensions knowledge.

!. EXTENSIONS -
    The following material is removed from the current extensions knowledge.

GROUPSIZE events:

! GROUPSIZE number low high group
    If a GROUP command were issued with the name of the current group, the
    server would return a 211 response with these parameters.

TELLUSER events:

! TELLUSER text
    The server wishes the user to be informed of the contents of the text
    without delay.

Example:

    [C] EVENTS GROUPSIZE
    [S] 206
    [C] GROUP local.group
    [S] 211 5 100 107 local.group selected
    [C] STAT 107
    [S] 223 107 <a.message at id> selected
    [C] NEXT
    [S] 421 no next article
    [C] LAST
    [S] 223 106 <another at message.id> selected
    [C] NEXT
    [S] ! GROUPSIZE 6 100 108 local.group
    [S] 223 107 <a.message at id> selected
    [C] NEXT
    [S] 223 108 <new.message at id> selected

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