[NNTP] Future-proofing for including capabilities in responses

[Russ Allbery]

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

> Is there really a need for this? Is the initial CAPABILITIES command
> really a problem?

It's a problem in the sense that it's another round trip.  I don't think
that's a huge problem, but I can see why someone might want to eliminate
it.  The point wasn't to decide what to do, since I already know that
we're not going to reach an agreement on that, but to figure out what
leeway we can insert so that people can experiment in this area later.

> If you do it this way, you've still got the parsing problem, in that the
> line has to be parsed in a totally different manner to the normal
> CAPABILITIES response, and you've also got the question of what to do if
> the capabilities list is too long to fit into the initial greeting.

Right, I understand.  Those are all the reasons why we weren't going to
reach consensus in this group around doing things that way.  Some people
feel that it's still worth it, and other people don't.

> That's not what I'm suggesting (I agree it's far too late). I'm
> suggesting a "multi-line response" extension, or - if you prefer - a
> "response can include capability information" extension. But it's an
> *extension* that only gets invoked when the client asks for it (and so
> expects it).

Yes, I can definitely see the merits of this approach.

Okay, we're going down the path of arguing about the best solution, which
is exactly what I was trying to avoid.  My understanding is that you feel
there's already enough leeway for someone to add capability responses
after STARTTLS or AUTHINFO in the existing draft provided that we add that
final response to STARTTLS?

Do we have a consensus to add that final response to STARTTLS to enable
work in this area in the future?  Ken, are you uncomfortable doing that
given the existence of earlier implementations that don't return a final
response?

If we don't have consensus on reserving characters in free-form text for
future extensions in this area, we don't have consensus, and we should
move on.

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