[NNTP] LIST EXTENSIONS (again)

[Clive D.W. Feather]

Russ Allbery said:
>> Can I make a proposal here? It might sound odd, but bear with me.
> 
>> *IF* an SASL security layer is negotiated, the server replies with two
>> responses:
>> * a 180 response meaning "security layer negotiated"
>> * the 281 or 283 response as normal
>> with the security layer coming into effect at the end of the 180, *not* the
>> 28x.

[Following comments from Ken, I think, I modified this to do them the other
way round: 281/283 as the last step of SASL negotiation, and 180 after the
security layer is in place.]

> I'm really leery of sending two responses in response to a command.  Other
> NNTP commands don't do that; we'd be adding a new style of response

I can see that it looks like two responses, but actually it isn't.

What I'm suggesting - as modified - is that after a change to the
underlying transport encoding, the server sends a new initial greeting.
I'm suggesting 180 as the code, but it could even be 200/201. This would
happen in two circumstances in our present situation:
- successful TLS negotiation
- successful SASL security layer negotiation
though I could envisage other places where it could happen (e.g. a COMPRESS
extension that starts compression on the transport layer).

The primary purpose of this is to provide a response on to which hang any
extension capability information (however done), but it also improves
consistency by starting each protected session in the same way as the
initial unprotected one.

> (since
> you're not sending the terminating .CRLF of a multiline response either).

It's not a multiline response, which is something different.

> After reading all this discussion, I'm becoming inclined to just give
> further attempts to reduce the RTTs for an initial client connection a
> pass for the time being,

That's what I suggested, though I note that Mark is violently against it.

> except possibly for putting something into the
> 200 response.

Sigh. See rant below.

> I know that in an ideal world STARTTLS or SASL should have
> had some way of communicating this sort of information after completion,
> but none of the other protocols do this (except IMAP, which has a
> capability for out of order responses that we don't have).

See above. And see also Mark's comments to the effect that this is how he
would have done it in hindsight.

> We've been brainstorming, which is good, but we also need to limit our
> sights a little so that we can get something published, because right now
> the situation with NNTP is hideous and we need to at least get some sort
> of standard out there for people to use now.

Agreed.

> Most of these decisions
> aren't final, and we can always revisit this and come up with some neat
> solution later on provided we don't trap ourselves in a corner.

However, having STARTTLS and SASL leave the protocol in client-next state
is, I think, going to be one of those corner traps.

> It sounds like providing extensions information as part of 281 or 283
> doesn't work from a protocol standpoint because that response is not
> protected, which means that there really isn't anything that we can say in
> the existing documents (without changing NNTP in fundamental ways like
> returning multiple responses) that helps or hurts for solving this problem
> down the road.

Well, I'd argue the "fundamental".

====

Rant follows.

I wish you people would make your bloody minds up as to how you want to do
things.

When I argue for putting core capabilities in one line in the extensions
output, I get told that we need to make things easy and consistent for
clients to parse, so we need to put each capability on a separate line.

Yet at the same time you're proposing putting capability information in two
totally separate places (LIST EXTENSIONS output and the free-text part of
response codes) in two totally different formats that will need to be parsed
in two totally different ways and will carry two different levels of
completeness. When I suggest a way to make the two arrangments consistent
with each other, I get told it's too complex. You've got a strange idea of
what is and isn't simple.

[End rant. I now have to go off and try to get the Department of Trade and
Industry to do something more about spam. I may be some time.]

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