[NNTP] LIST EXTENSIONS and an NNTPv2 capability

[Ken Murchison]

Clive D.W. Feather wrote:

  > Firstly, I'm not sure that NNTP is significantly different (but see 
below).
> However, I suspect that it's simply that none of them have run into the
> problems I discuss *yet*. And SMTP *has* sort of had the versioning
> problem, with the HELO v EHLO commands.

Well *sort* of.  The EHLO command was introduced as the extension 
discovery command (akin to LIST EXTENSIONS).  Prior to EHLO, there was 
no extension discovery mechanism.  So your example is kind of a mixed bag.

I think where we diverge is that the NNTPv2 proposal follows the KISS 
principal and only solves the existing problem(s); by putting a line in 
the sand w.r.t. base functionality and existing extensions which we are 
standardizing.  Your proposal wants to try to solve any problems with 
extensions moving forward.  My response to this is:

1)  Based on past history of IMAP/POP3/SMTP, few, if any, extensions 
will have their functionality changed in any significant way.

2)  If the functionality *is* changed in a drastic, non-backwards 
compatible way, then a new extension should be advertised rather than 
trying to wedge it into the existing extension.

3) If the previous two assumptions turn out to be false, then we can 
always address this issue at a later time.  The existing LIST EXTENSIONS 
syntax already allows for extension labels to take arguments, which 
could be used for versioning and/or enabled/disabled flags.


> I also don't accept "orders of magnitude".

I used this phrase in reference to your original STATUS proposal which 
seemed overwhelmingly complex.  It seems that you have pared down your 
proposal since then.  In that respect I overstated things a bit.


> My concerns, as explained in my previous messages, split into two areas:
> 
> (1) The ability to handle variations - version numbers - of extensions.
> This *will* happen to lots of protocols, even if it hasn't happened yet.

I agree that functionality *may* change for certain extensions, but my 
guess is that the WGs responsible for the other protocols would just 
create a new extension or separate extension label/capability.


> 
> (2) NNTP's unique (as far as I know) concept of "extensions that aren't
> available until you do something separate".

Well, this is *always* the case with the SASL PLAIN mechanism, which 
requires TLS before being advertised and/or used.  None of the other 
messaging protocols prevent a server from hiding extensions until the 
client jumps through the appropriate hoop(s).  In fact I think Mark's UW 
IMAP server hides most extensions until the client is authenticated.

I don't see this being an issue for clients.  They already know before 
they issue a command (e.g. AUTHINFO, STARTTLS, MODE READER) that it has 
the possibly of changing the output of LIST EXTENSIONS and should be 
prepared to [re-]issue LIST EXTENSIONS.

If we're interested in saving roundtrips, then we could always look at 
Mark's proposal (which I haven't seen get to the list yet) of allowing 
relevant responses to carry extension info.  IMAP already allows this. 
For example:

200 [NNTPv2 AUTHINFO=USER AUTHINFO=SASL:OTP,DIGEST-MD5,CRAM-MD5,NTLM 
STARTTLS STREAMING] toshiba.oceana.com Cyrus NNTP v2.3-alpha server 
ready, posting allowed
STARTTLS
382 Begin TLS negotiation now
LIST EXTENSIONS
202 Extension list follows:
NNTPv2
AUTHINFO USER SASL:LOGIN,OTP,DIGEST-MD5,CRAM-MD5,PLAIN,NTLM
STREAMING
.
GROUP misc.test
480 Authentication required
AUTHINFO SASL CRAM-MD5
383 PDU0NjI1NDYxMC43Nzc0NjE1QHRvc2hpYmEub2NlYW5hLmNvbT4=
bXJjIGRlMDhmZTVjYmQwZDEwNGRlNzY0YWM3NDhlNmFiNTRh
281 [NNTPv2 HDR LISTGROUP OVER STREAMING] Success (tls protection)
GROUP misc.test
211 0 1 0 misc.test


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