[NNTP] Capabilities in responses (Was: MODE READER)

[Ken Murchison]

Mark Crispin wrote:

> On Tue, 9 Nov 2004, Clive D.W. Feather wrote:
> 
>>>> Our existing response code model doesn't have anywhere to insert
>>>> asynchronous messages from the server. It can't go in the free text 
>>>> area
>>>> for the reasons given above, so it needs to go somewhere else.
>>>
>>> What is so special about NNTP that it can not do exactly what IMAP and
>>> SMTP did?
>>
>> What exactly was done, and what was the installed base?
> 
> 
> What is the installed base of SMTP, POP3, and IMAP?
> 
> SMTP added extended response codes.  SMTP also requires that an ESMTP 
> capable server include "ESMTP" somewhere in the greeting.
> 
> POP3 added the APOP authentication token in the greeting.
> 
> IMAP added status response codes, among which are capabilities in the 
> greetings.

I don't have any hard numbers, but my guess is that if you just look at 
open source products (Sendmail, Qpopper and UW IMAP respectively), we're 
talking about thousands (if not 10K or 100K) of servers that were 
deployed with these changes without the client world coming to an abrupt 
end.

The reason being that the above changes as well as those being proposed 
for NNTP and *completely* backwards compatible with an RFC 977 client. 
Its a completely "take it or leave it" facility, not a "take it or else 
you're screwed" facility.


>> This is *VERY* late in the
>> day to be making significant changes to the wire protocol, particular
>> when these changes are forced on all clients whether they like it or not,
>> and when there seem to be ramifications (e.g. piggybacking on the SASL
>> completion response) that still aren't clear.

We're not *forcing* anything on the client.  We're simply putting some 
structured text in the free-text area that a client is free to use or 
ignore as they see fit.  An "enlightened" client such as Pine would use 
the capability info in these responses to reduce roundtrips.  An 
"unenlightened" client (such as legacy clients or those written by 
authors that don't care to read specs) wouldn't be impacted as all.  My 
guess is that most currnt clients ignore the free-text that comes with 
"success" responses anyways.

Please point out the unclear SASL ramifications, so we can address them. 
  If we're talking about the 283 response, I don't see any problems.  If 
we're talking about SASL security layers, this is nothing new and isn't 
a show stopper.


>> Technically these changes
>> are probably out of scope, and do we really want to be including them
>> without any test implementations (both client and server)?
> 
> 
> A client and server implementation could probably be produced in a few 
> hours.

I'd volunteer to put this in the Cyrus code and Mark could test against 
it with Pine, as we've done in the past.

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