[NNTP] Future-proofing for including capabilities in responses

[Russ Allbery]

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

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

[...]

One thing that I should have mentioned is that I was aiming for enough
leeway that would allow servers to return capabilities in the initial
greeting as well as in response to commands.  That's why the reservation
for all freeform text; that catches the initial greeting as well.  (I
certainly don't expect that all commands will be allowed to return
capabilities!  That's just the minimal change to the current draft to
reserve the right leeway.)

Sending CAPABILITIES with an additional argument or allowing multiline
replies to AUTHINFO or STARTTLS doesn't solve the initial greeting
problem.

Being able to turn any arbitrary reply into a multiline reply the way that
SMTP can do would be nice, but I think that's one of those things we're
far too late to be able to add to NNTP.

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

If one of the goals is to allow capabilities to be presented during the
initial greeting, I don't see any way around this.

However, the purpose is to reserve enough leeway that people can
experiment, not hash out the best scheme on the list (since I think we've
already established that consensus is unlikely).  Towards that end, I
would be happy to reserve enough leeway for anyone's preferred schemes, if
there are other provisions you can see that would make it easier to do
something like this later.

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