[NNTP] Future-proofing for including capabilities in responses

[Clive D.W. Feather]

Russ Allbery said:
>  * Add a final response to the STARTTLS protocol so that, after TLS
>    negotiation completes, the server sends a response to the client saying
>    that the TLS negotiation completed.  We discussed doing this before and
>    there was some support for doing it, but we didn't, as I recall, mostly
>    because other protocols didn't and there didn't seem to be a point.

I would be very much in favour of this. As I recall, I suggested re-sending
the 200 or 201 greeting.

Would you want a separate code for a failed TLS?

As a very minor point, it eliminates the anomaly that the 382 response is,
in effect, final rather than intermediate - there's no later 2xx/4xx/5xx
response.

>  * Reserve (i.e., forbid) the use of the characters [ and ] (or some other
>    pair, if another pair looks better) in all freeform text in NNTP
>    responses, with a warning that those characters may be used for
>    protocol purposes in later standards.
> 
> This would allow people to pursue proposals for returning capabilities in
> the final responses to AUTHINFO and STARTTLS, without sticking us with the
> task of hammering out exactly how to do so, how to deal with modifiers,
> and so forth that we weren't able to reach a consensus around.

I don't think we need this and I don't like the idea. Let me explain.

Firstly, we can leave the default behaviour alone. The CAPABILITIES command
is specified as taking an optional argument, so if people want unsolicited
updates then they can ask for them using such an argument (or, for that
matter, using a separate command). That's upwards-compatible in a way that
fiddling with the free text isn't.

Secondly, if information like this is put in the free text of responses, it
has to be parsed in a totally different way. We were unhappy with this in
the past (AUTHINFO SASL, I think) and I don't see that things have changed.

Off the top of my head, I can think of three ways that the information can
be provided once the feature has been turned on:

(1) Any response can be preceded by an update response code in the 6xx
block:

    [C] STARTTLS
    [S] 382 Continue with negotiation
    [TLS negotiation occurs here]
    [S] 601 New capability list follows
    [S] VERSION 2
    [S] READER POST
    [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
    [S] .
    [S] 201 Welcome to the secure server

(2) A flag, either before or after the three digit code, indicates that
capability information will follow:

    [C] STARTTLS
    [S] 382 Continue with negotiation
    [TLS negotiation occurs here]
    [S] 201+ Welcome to the secure server, capability information follows
    [S] VERSION 2
    [S] READER POST
    [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
    [S] .

(3) A flag before the three digit code of a response indicates another
response will follow:

    [C] STARTTLS
    [S] 382 Continue with negotiation
    [TLS negotiation occurs here]
    [S] +201 Welcome to the secure server
    [S] 101 Capability information follows
    [S] VERSION 2
    [S] READER POST
    [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
    [S] .

[In each case I'm using STARTTLS as the example, but the same could apply
to AUTHINFO and MODE READER among others.]

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