Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.toronto.edu!ietf-nntp-distribution-owner Message-ID: <9106251318.AA15863@funet.fi> Original-To: sob@tmc.edu (Stan Barber) Original-Cc: lear@turbo.bio.net (Eliot), ietf-nntp@turbo.bio.net Subject: Re: should batch/ibatch/image/et al apply to the article command? References: Your message of Mon, 24 Jun 91 19:14:40 -0500. <9106250014.AA25541@tmc.edu> Date: Tue, 25 Jun 1991 09:18:54 -0400 From: Harri.Salminen@funet.fi (Harri K Salminen) Newsgroups: list.ietf-nntp Distribution: list Sender: list-admin@cs.toronto.edu Approved: list.ietf-nntp@mail.cs.toronto.edu Lines: 61 Your message dated: Mon, 24 Jun 91 19:14:40 CDT > NEWNEWS and ARTICLE were really invented for news readers, not news transfer > Therefore, I believe these features should not be addedto NEWNEWS/ARTICLE. > Perhaps part of NNRP, but not NNTP. As I said in my earlier letter about extending newnews et al I think it's very important to improve the newnews and article support also for NNTP transfer. I think that it it's VERY important to support newsgroup and article selection to transfer at least articles for some interval of of time from a PSECIFIC newsgroup. My vision is that we NEED support for building hierarchical caching news distribution backbone in which at least leaf sites don't need to keep copy of ALL articles in ALL available newsgroups for one year just because some users might sometimes need that. The news servers might be able to keep list of newsgroups or even subject index (a la nn but applied to a news server) but not bodies of all articles from which a user could select an article that is fetched to a local cache from a backbone or archival server that keeps longer term copies. Keeping archives on anon ftp is not a solution every end user likes or even manages to use. The basic support for these using newsgroup masks and time (article?) intervals shouldn't be complicated but would help a lot to manage the traffic growth. There's more and more need for sparse public and closed distributions which could be handled more efficiently this way than hopefully the coming listserv like service which I hope to merge with netnews gateways to offer at least to the user a single easy to use service that is also easy for us to manage. I this sense I don't think too strong division between NNTP and NNRP makes sense when building cache style hierachical support. You might support even user level authentication some levels up or to several sites or archives. The more complex future feature would be an intelligent and robust routing protocol for newsgroups but I agree it might be out of scope for the basic set of services and does need further study before making it even optional. Anyway we need option support also for experimental enhancements. I think we definitely NEED OPTIONS negotiation not some general MODEs. You could do it faster by sending an OPTIONS option-count command followed with a sorted list of options you'd like to have. The other end would respond back with the subset of options it accepts. This could continue further untill the originating side agrees to the reply by just starting the normal session. Since the system could remember the values from the last session it could just use the previous set next time unless there's a change of version (did we have something similar to SOA record check in the beginning already?) number or explicit request. Also most common sets of options could have a shorthand name like (NNRP-BASIC-OPTIONS) if you insist on something looking like MODE NNRP support. This way startup would normally be very fast even if we had dozens of options. We definitely need options for image, multimedia, several authentication schemes, several search facilities (subject/keyword/etc a la nngrab or fulltext), experiments etc. > Stan internet: sob@bcm.tmc.edu Director, Networking > Olan uucp: rutgers!bcm!sob and Systems Support > Barber Opinions expressed are only mine. Baylor College of Medicine Harri