Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.toronto.edu!ietf-nntp-distribution-owner Date: Mon, 24 Jun 1991 15:58:38 -0400 From: Jim.Thompson@Central.Sun.COM (Jim Thompson) Message-ID: <9106241958.AA29235@neuromancer.Central.Sun.COM> Original-To: ietf-nntp@turbo.bio.net, rsalz@bbn.com, lear@turbo.bio.net Subject: Re: July IETF Meeting Newsgroups: list.ietf-nntp Distribution: list Sender: list-admin@cs.toronto.edu Approved: list.ietf-nntp@mail.cs.toronto.edu Lines: 48 From ietf-nntp-request@turbo.bio.net Mon Jun 24 12:34:01 1991 From: Eliot Rich, reader additions to the protocol are on hold until we see just how far we can get on an NNRP. I don't have any particular objections to the MODE command, other than that the default MODE needs to handle the old functionality. This assumes that whatever is listening on the other 'end' of the connections handles all the current requests. In this case, that is not true. In my opinion, the original spec errored in being to tied to a particular implimentation. Among other things it would not require an additional port assignment. Why should NNRP not be granted an additional port assignment? Heck, POP has three of 'em now! Stan likes the idea of the OPTION command. As long as you can lump all the options together, I won't object, either. Brian's suggestion was to flush the OPTION command. NNTP should be for transfering news. NNRP should be for reading news. As far as IMAGE, while it is true that changing into and back out of the '\r\n' line termination on Un*x, there is a simple solution for this as well. Don't transform the '\r\n' on input if you're just going to store the article. "But this breaks our storage model, because the newsreaders have direct access to the files!", someone will object. Time to catch up with technology, man. The current storage model is broken. Just ask anyone who attempts to keep 6 months of news on-line. Jim Eliot Lear [lear@turbo.bio.net]