Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.toronto.edu!ietf-nntp-distribution-owner Message-ID: <9106052107.AA29442@funet.fi> Original-To: Eliot Original-Cc: ietf-nntp@turbo.bio.net Subject: Re: a new nntp draft References: Your message of Tue, 04 Jun 91 13:42:47 -0700. Date: Wed, 5 Jun 1991 17:07:53 -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: 73 One thing I already probably mentioned is the hierarchical support for longer term archives. This is a real need by many non technical new users in our network who have now started their own national newsgroups (maybe bionet too :-) where they would like to keep some information like course schedules beyond normal expriry limits (e.g. one year). The best solution today seems to be to post the messages regularly with some automatic program (like in news.announce.newusers) or build better ftp userinerface that is intergrated to netnews... Back to details. One way to ease the implementation of multiple levels of archival hierarchy would be to allow a date range in NEWNEWS command along with the names of newsgroup(s) you're interested in. In addition it should be possible to query the expiry information from your neighbours to see if they archive some groups longer than me. The information of the full archives could be distrbuted in some periodic posting (like the moderator information) and those sites could only allow direct NNTP transfers for articles in that specific group with dates older than a specified limit (say three months). The sites should also be able to specify that they want only batch transfers during some off hours. Actually this could be usefull in general nntp backbone as well to control load on some overloaded lines. I personally believe in NNTPLINK and ASAP delivery but others seem to believe that BITNET/EARN NJE based news backbone is more efficient than NNTP since they know how to store files on tape or put them on hold when lines get congested :-). In a conferencing system, real time operation is important to synchronize the discussion. Btw. the idea about sites modifying sys files seems to be underway with the discussion about Dynafeed. My idea was that you would still control a master sysfile (which could include much more information than today) and just let your neighbours set kind of filters to dynamically limit the number of newsgroups they want to get. One way to achieve this would be to define a command GROUPFILTER filternumber bytecount a.b.c x.y.z !e.f.g These could be then stored in files like sys.news.funet.fi.0(1,2...) and used to filter for example IHAVE or NEWNEWS output. With one command you could set the default filter from 0 something else. About the news reader protocol: US ASCII would probably make it simpler although it should not cause any restriction on the used character set on the actual messages which is possible if we are compatible with the SMTP extensions. To me a simple natural language interface which supports () * ? and or not " " like syntax for a free text search might be suitable. I think those would be able to offer any logical combination needed and it would be easily understood even by non-Unix gurus (unlike the regular regular expressions :-) Optional paramaters could be used to specify which parts of the message you would like to search, the default being the Subject: If some systems support only subject database they could indicate with some error reply that they can't support the full body search :-). The functionality of the MH pick command comes to my mind altough it's not a good example of a database since it isn't one... There should be some basic access control available to all. Maybe just password/userid type (tacacsd comes to mind) as the basic functionality (also for nntp transfers?). Optionally you should be able to select (automatically negotiate preferably) some more secure authentication like kerberos, RSA signatures or some new public algorithm without licensing problems. Naybe it's enough to provide hooks and negotiable options for in and out of band extensions where needed. Eliot, I hope you can make some sense of all my ideas to the draft, I'm even myself loosing the track of the current status of our ideas... A hypermedia (or cyberspace :-) would really help to keep track on this kind of idea development... Harri