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

[Mark Crispin]

On Thu, 4 Nov 2004, Clive D.W. Feather wrote:
>>> The problem is the other way round: a conforming RFC 977 server can already
>>> produce such responses with meaningless contents.
>> It is not, however, particularly likely that an RFC 977 is going to
>> produce such a response which contains the "NNTPv2" capability.
> It doesn't matter; you can't rely on it. That's building on sand, not
> drawing a line in it :-)

Sometimes you have to make compromises in order to accomplish a desirable 
result.  The elimination of several RTTs is a highly desirable result.

I know that I'm sounding like a broken record, but both MIME and IMAP 
exist as precedents.  I know because I was personally involved in both; 
and in both cases there were objections much as you have raised.

Nevertheless, the predicted problems never came to pass.

Actually, now that I think about it, SMTP has *also* done this!!!!!!!

> There's also the problem that response lines are limited in length and
> there may not be room for the message as well as the existing response.

That, now, is a real issue.

However, I note that the the response line limit is 512 octets.  This is 
enough for the existing set of extensions, although I would recommend a 
larger limit.

A way that this could be gotten around may be to restrict the 
auto-announced extensions to a certain set which are meaningful for 
session startup; that is, the extensions for TLS, authentication, and 
(sigh) MODE READER.  So, the client still has to do a single LIST 
EXTENSIONS when it's actually ready to do actual reading.  That's one 
addtional RTT, which is still better than the status quo.

> What you're talking about is a specific use of what I would call
> "asynchronous messages" - messages not in immediate response to a command.

No.  It's piggy-backing additional status information on an existing 
synchronous response.  Both IMAP and SMTP does this.  SMTP has no 
"asynchronous messages".

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

Both IMAP and SMTP have piggy-backing, and both did it on what was 
previously a free-text area.

I repeat: what is so special about NNTP?!?!

> Having said that, and purely as a proof of concept, I'll sketch out such an
> extension to show that it does what you want. I'll call it "EVENTS", having
> pinched the name from X11.

If you're going to add what IMAP calls "unsolicited data" to NNTP, then 
you have a l-o-n-g way to go.  Don't forget that I've been in that 
business with IMAP for nearly 20 years.

At that point, the question becomes "why not flush NNTP in favor of IMAP."

Fortunately, you don't need unsolicted data.  You just need piggybacking.

-- Mark --

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