[NNTP] Future-proofing for including capabilities in responses

Russ Allbery rra at stanford.edu
Tue Mar 22 15:57:40 PST 2005


We previously had a discussion about returning new capabilities after
commands such as STARTTLS and AUTHINFO, and possibly also in the server
welcome banner, but didn't reach any consensus on how to do it.

Rather than reopening that, I'm wondering how people would feel about
adding some provisions that would make it easier to propose a way to do
this at a future date.  In particular, those provisions would be:

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

 * 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.  It would
also give server authors some advance warning around using [] (or some
other pair), giving them a chance to eliminate those characters as part of
the effort to comply with this standard and making it a bit less worrisome
if those characters are given extra meaning later.

How do people feel about this?

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



More information about the ietf-nntp mailing list