ietf-nntp LIST EXTENSIONS

[Ken Murchison]

Russ Allbery wrote:
> Ken Murchison <ken at oceana.com> writes:
> 
> 
>>After re-reading the LIST EXTENSIONS text, I'd like to propose the
>>following change to section 5.3.2:
> 
> 
>>old:
> 
> 
>>"It is not required that the client issues this command before attempting
>>to make use of any extension."
> 
> 
>>new:
> 
> 
>>"Clients SHOULD issue this command before attempting to make use of any
>>extension."
> 
> 
> I'm afraid I still really don't see the point of this, particularly for
> extensions that are nearly universally implemented.  This would reduce the
> compliance of basically every existing client to conditional, even when
> they would otherwise be fine, and client authors are going to look at that
> and go "why?"
> 
> I don't understand what the benefit is.  I mean, people have said things
> in the past about how it makes sure that security-related extensions
> aren't used unless they're advertised, but I don't see what problem in
> practice is caused by this.
> 
> What's wrong with trying the extension and getting an error code?  NNTP
> has worked that way since the invention of the protocol, so it's clearly
> not actually broken....


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?  Just throw 
it out and let clients go back to the trial-n-error method.

2. IMO its bad form for a client to NOT use it.  Why would I try a bunch 
of commands (each with a roundtrip) just to find out that they aren't 
supported, when in one roundtrip I can discover what I can and can't do? 
And given that commands may become available or unavailable based on a 
"mode change" (MODE READER, STARTTLS, AUTHINFO), this discovery might 
have happen multiple times.  Obviously, we can mandate good behavior, 
but why not encourage it?  Server authors seem to worry about bandwidth 
an awful lot (both network and CPU), so why would I want clients to 
waste it on extension discovery?

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?  As a user, I wouldn't trust a client to get this 
right if its required for some commands and not others.  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.  IMO 
any good client should be encouraged to use LIST EXTENSIONS as the first 
command upon connection or after any "mode change".

4. Note that LIST EXTENSIONS doesn't effect any existing commands other 
than LISTGROUP and AUTHINFO USER/PASS.  All of the other capabilites 
listed in LIST EXTENSIONS are either new (OVER, HDR) or not widely 
deployed (STARTTLS).  So saying that client SHOULD use LIST EXTENSIONS 
really doesn't break any existing client or make then less compliant.


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

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

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp