[NNTP] LIST EXTENSIONS and an NNTPv2 capability

[Ken Murchison]

Clive D.W. Feather wrote:

>>The second problem is that, based on our drafts, at least one
>>implementation (INN) and possibly others have started adding LIST
>>EXTENSIONS.  However, the extension list was not finalized, and in
>>particular AUTHINFO was not advertised by the early INN implementation
>>even though AUTHINFO USER was supported.  A client that uses the extension
>>mechanism properly would therefore think that those servers didn't support
>>authentication when they do.
> 
> 
> This is *always* going to be a problem in the stage between an extension
> being invented and the specification being finalised. Agreed it's rather
> worse for the stuff that has been around for a while, but it's not unique
> to them.

I don't see that.  Either early implementations advertise the new 
extension label as soon as they support the new command(s) (risking 
incompatibility if the functionality is a moving target), or (ideally) 
new extensions are implemented as X- commands until finalized.


>>The proposed solution is this:  Specify in our base draft that any server
>>that fully complies with the new specification advertise the NNTPv2
>>capability as part of LIST EXTENSIONS.
> 
> 
> Right, stop here. I don't like this idea. It's a kludge, and an unstructured
> one at that.

I disagree that its a kludge, it simply states that the server is 
compliant with RFC 977bis.  Any server which does not advertise it, is 
at best compliant with RFC 977 and LIST EXTENSIONS may or may not be 
accurate (a.k.a. the currently deployed mess).  The beauty is in the 
simplicity.  As stated earlier, this approach has worked well for IMAP.


> Rather than saying that LIST EXTENSIONS is unreliable unless the server
> sets the "I got it right, honest" flag, I think we're better off having a
> new command. There's little downside because server implementers are going
> to have to make changes anyway. This can then also fix other problems.

I *could* be convinced that a new command is worthwhile, but I'd have to 
see a compelling argument.


> The two big issues I can see that are going to bite us one day (if indeed
> they haven't already) are:
> 
> (1) There's no good way to indicate conformance to particular versions of
> extension protocols. Adding a versioning facility usually turns out to be
> a good idea in the long run.

I don't think this is necessary.  If the functionality of an existing 
command changes, then a new extension label should be created.


> (2) It's better to indicate what capabilities are available altogether,
> rather than just what are available right now. It's better for a client to
> know "you can do TLS once you've done MODE READER" than for it to have
> to guess that doing MODE READER might make STARTTLS magically appear.

I also don't think this is necessary at all.  IMAP, POP and SMTP clients 
don't seem to have any problem.


> So let's fix these now, while we have the chance.
> 
> Let me present my idea first as a bit of protocol:
> 
>     [C] STATUS
>     [S] 101 1.0     List of available extensions follows
>     [S] OVER 1.0 + MSGID
>     [S] HDR 1.0-RAA +
>     [S] LISTGROUP 1.0 -MODE-READER
>     [S] STARTTLS 0.0-02 -502
>     [S] AUTHINFO 0.0-05-x -502 USER SASL:PLAIN,EXTERNAL
>     [S] STREAMING 0.0-perhaps +
>     [S] XSECRET -CDWF -483
>     [S] XDATA -CDWF +
>     [.]

Yikes!  This seems like complete overkill, not to mention incredibly 
complex.


> But I'd certainly like to encourage extensions to indicate both what is
> available and what is currently-unavailable, rather than just the former.
> And this is something that I'd like to see even if we don't adopt this
> STATUS proposal.

I don't see why this is necessary.  We really need client authors to 
weigh in here.  We, as server authors shouldn't be deciding what's good 
for clients in a vacuum.


> Or we can bite the bullet and say that servers must advertise every command
> that they implement.

*Every* command?  Why?  The NNTPv2 capability states all of the base 
commands that the server supports (other than the optional LIST xxx 
stuff -- which is still a klugde IMHO).  Any other commands MUST be 
advertised by an extension label.


> However, I'm not 100% convinced. If a server does AUTHINFO SASL to spec,
> and AUTHINFO GENERIC, what should it advertise?

AUTHINFO GENERIC is not standardized relative to RFC 977bis guidelines 
and doesn't have any extension label.  Since AUTHINFO SASL *is* 
standarized and provides equal, if not superior, functionality, that's 
what a client should use.  A client is still free to probe for AUTHINFO 
GENERIC if it so chooses.


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