[NNTP] Future-proofing for including capabilities in responses

[Clive D.W. Feather]

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

> Is this response sent in the clear, or is it encrypted?

Encrypted; it would go after the existing STARTTLS transactions.

> Actually, there is a response, just not one that conforms to NNTP.  The 
> TLS exchange will finish with a success/failure.  Adding a response to 
> NNTP would just be redundant (since both the client and server already 
> know the result), but I won't argue this point very strongly.

The purpose of providing an NNTP-like response is purely to let us hook
other NNTP things to it; I agree it's redundant.

>> 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:
[...]
>> (2) A flag, either before or after the three digit code, indicates that
>> capability information will follow:
[...]
>> (3) A flag before the three digit code of a response indicates another
>> response will follow:

> The only variants that would work with AUTHINFO are (2) and (3).  Since 
> AUTHINFO SASL might negotiate a security layer, the capabilities stuff 
> MUST NOT be returned until AFTER the SASL exchange has completed, which 
> may not be until a 283 response (server success data).

Well, with (1) the client could accept the results anyway, overwriting what
it knew from before, and then the 283 tells it to throw away anything except
from an immediately preceding 6xx. But I agree it's messy.

> Of the two, I prefer (2) since (3) has back-to-back response codes.  (2) 
> has the feel of transforming what would normally be a single line 
> response into a multi-line response, which seems cleaner IMHO.

Whereas I prefer (3), for reasons I'll cover below.

> Actually, if the client enables the "unsolicited capabilities response" 
> feature do we even need an indicator like "+", since the client will 
> already know to expect the capabilities after STARTTLS, AUTHINFO and 
> MODE READER?

If we're going to create a mechanism like this, I don't want to limit it to
just one special situation. As such:
- it should be possible for STARTTLS etc. *not* to return the information;
- it should be syntactically possible to include or exclude the data in any
  response code, so that an XENCRYPT feature can use it just as well as
  STARTTLS;
- it should be possibly to use this mechanism for things other than
  resending the entire capabilities list, so it should be extensible.

To me, these all say that we're looking for a way to provide multiple
responses to a command. The exact syntax is unimportant at this stage,
but (2) requires the use of multiple flags while (3) just requires a
"another response coming" flag.

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