ietf-nntp LIST EXTENSIONS

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> 1. If clients aren't going to use the extension discovery mechanism (or
> we don't recommend that they do), why even bother having it?

I agree that we should say clients should use it.  I just don't agree that
we should tell clients they SHOULD use it.  SHOULD to me implies that
there's protocol breakage involved, which I don't believe is actually the
case; the old method is just {ugly,bad form,obsolete}.

> 2. IMO its bad form for a client to NOT use it.

I agree.  But the standard at the SHOULD and MUST level should be about
interoperability, not about bad form.

> 3. If we're going to strongly encourage LIST EXTENSIONS be used before
> AUTHINFO (for security reasons), why not recommend that it be used
> before any extension?

Well, because the issues aren't the same?

> As a user, I wouldn't trust a client to get this right if its required
> for some commands and not others.

This seems like a quality of implementation issue to me more than a
protocol issue.

> As a client author (which I'm not), I'd be pissed if the base document
> tells me that LIST EXTENSIONS is completely optional (therefore I don't
> use it), and then some extension comes along and tells me that I MUST
> use it.

Well, I'm unconvinced that MUST is the right language even for AUTHINFO
(although it is for AUTHINFO SASL, but that's because it's part of the
SASL protocol -- and I can't imagine people being upset about implementing
it then when they're adding SASL, which is a much larger issue), so it's
more a matter of the base document strongly encouraging its use and an
extension upgrading that because it's part of an additional negotiation
protocol.

> This just seems like common sense to me.  What am I missing?  What is
> the big pushback?

I've been on too many working groups that throw around protocol
requirements like SHOULD and MUST like they're going out of style, so I
tend to scrutinize those extremely closely.  *wry heh*.

> All of the similar messaging protocols (IMAP, POP3, SMTP) have capability
> discovery commands, and clients are encouraged to and do use them.

I just reviewed RFC 3501 (IMAP) and RFC 2449 (POP3) and didn't see in
either a SHOULD-level requirement for the client to issue the CAPABILITIES
or CAPA command.  SASL obviously requires that such a command be used
before beginning authentication, since negotiation of the authentication
type is part of the SASL protocol (and I should have remembered that
earlier), but apart from that there doesn't seem to be any particular
statement in those drafts.

SMTP is a different issue entirely since with SMTP the server returns its
capabilities as a response to the normal client greeting.

NNTP is oddly different in that it's very common for NNTP connections to
be unauthenticated, which is pretty much unheard of for POP.  That is more
common with IMAP, so IMAP seems to be the closest parallel, and I can't
find a requirement for the client to issue CAPABILITIES in the IMAP
standard.  Maybe I'm just missing it?

I'm quite happy to follow existing practice in other standards; clearly at
this date we don't want to be taking a lot of time to reinvent the wheel.

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