ietf-nntp Re: IMAP for News?

[Ben Polk]

At 04:04 PM 10/21/96 -0700, Mark Crispin wrote:
>On Mon, 21 Oct 1996 15:36:42 -0700 (PDT), Chris Newman wrote:
>> For now, LIST and LSUB will have to do as
>> they are.  We can deprecate them later.
>
>Agreed -- I think that all of the stuff that ACAP does better should
>eventually be yanked out of IMAP: LIST, LSUB, CREATE, DELETE, RENAME,
>SUBSCRIBE, UNSUBSCRIBE.
>
>> All of these are very important features, most of which are not available
>> in NNTP.  I also think adding any more client support functions to NNTP is
>> a mistake.  NNTP is network news *TRANSFER* protocol, not *access*
>> protocol or *client* protocol.

Hoo boy.  I suppose this was bound to come up.

We're wandering into religious ground.  Here's what I think:

0. I believe in IMAP.  Netscape believes in IMAP.  We are committed
to it, and have been from before the meeting up in Seattle last
year.  Soon it will be the core protocol in our mail products.  In
the future I hope it will be our main newsreading protocol as well.
But...

1. NNTP was orignally designed as a transfer protocol, but from the
very first days clients were using it as well.  And it has had from 
the days of RFC 977 capabilities that were designed explicitly for 
clients: NEWGROUPS, ARTICLE, BODY, HEADER, and so on.  I have
heard the claim that NNTP is a "*TRANSFER*" protocol before, but
just because that's part of it's name doesn't mean that's all
it is designed to do.

2. There are at least an order of magnitude more people reading
News using NNTP than IMAP.  It *is* a client protocol, just look 
around.

3. In spite of both of the items above, I think that we should
try to build IMAP clients and servers that support news well.
I hope IMAP will eventually replace NNTP as a client reader
protocol.  I think that mail/news message access will need many
new things going forward, (I18N enhancements, MIME enhancements, 
partial message fetching, who-knows-what-else) and it is wasteful 
to do all this work in multiple protocols.  (Yes, I know, some
of this is already in IMAP.)

4. But I don't believe that the way to get to a common protocol
is for IMAP people to to somehow freeze NNTP development.  The way 
to do it is to develop good IMAP products that perform this function 
better than the NNTP products can.  If this is really feasible, 
and we build IMAP products that do this well, eventually it will 
be obvious to everyone that IMAP is the right choice.

5. This will take time.  There are hundreds of thousands of NNTP
servers out there, and it will be a long time before all those
sites put in parallel IMAP servers.  

Not everyone that works with NNTP believes that IMAP will
make a better client protocol for news.  The way to convince
them isn't to tell them they are wrong, it is to build and
deploy products that *show* them that IMAP is the right
way to go.  And until they are convinced it won't work
to tell them to stop innovating and building better products.

>Tell that to the people who are putting lots of IMAP features (such as SEARCH)
>into NNTP.

As we've discussed before, IMAP SEARCH does not operate across
containers and the undocumented mechanism for doing this leaves a lot
to be desired.  If all we cared about was searching within a newsgroup
we'd just live with XPAT.

>> Adding the few news-related features that
>> IMAP4 is missing is the way to solve the problem.  There is no reason for
>> your mail reader and news reader to be separate programs or to use
>> separate access protocols.
>
>This contradicts what you said above about leaving LIST and LSUB alone.

The IMAP posse needs to determine how far it is willing to
ride to catch the news bad guys.  ;)


Ben "Only half a news bad guy" Polk