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

[Mark Crispin]

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.

All of these protocols either have incredibly stupid designers who can not 
see the problems that are the NNTP designers see -- or just maybe the 
problems are not substantial enough to be of concern.

> And if a cleaner solution exists, why not use it? [Please answer this
> generically, before arguing whether my proposals are cleaner.]

I'm afraid that you may not be seeing the higher-level picture.

The single aspect of NNTP and news header formats that sucks the worst is 
where they go off and do something different from email, all in the name 
of doing what someone in the news community thought was "cleaner".  This 
is an ongoing problem; the news community has a dismal history of 
insisting upon reinventing wheels that are already long-invented and 
well-understood.

The work involved to examine and consider reinvented wheels, and to create 
new tools for these wheels (as opposed to reusing existing tools) should 
not be underestimated.

It isn't as if there is no other work to do in NNTP, and thus there is the 
luxury of thinking about how to reinvent a better wheel.  It isn't as if 
the IESG, not to mention the entire community of client implementors, are 
twiddling their thumbs with nothing to do other than think about the 
latest wheel reinvention.

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

Now you are making me quite angry.

There is a reason why productive people haven't paid much attention to 
what is going on in the NNTPEXT and USEFOR working groups.  These groups 
have been so dysfunctional in the past that most of us stopped tracking 
them.  I wouldn't be here if Ken hadn't dragged me in with assurances that 
there was new leadership to stop it.

"Force changes on all clients"?!?  What the hell are you talking about? 
Every existing client is fully compatible with this change.  That's the 
advantage of using a free text field.

"SASL ramifications still aren't clear"?!?  Do you really think that NNTP 
is so unique that this is a problem that hasn't already been addressed?

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

> - costs only one RTT at most compared with your approach, while still
>  saving round trips compared with the existing protocol.

It's still a wasted RTT.

Your proposed AUTO mechanism is quite complicated and as such is extremely 
vulnerable to implementation problems.  I doubt that I would ever 
implement it.

Among other things, it adds the equivalent of IMAP unsolicited data to 
NNTP.  This is something that is extremely difficult to get right.  IMAP 
absolutely needs it.  NNTP does not.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.