lear@turbo.bio.net (Eliot) (06/04/91)
Here is the state of the world with the new version of NNTP. I am in the process of writing a draft, which I hope to post to this group within the next week or so. That draft currently has ALL the proposed changes listed in Brian Kantor's draft. I saw a note from Brian questioning his method of options negotiation in that draft, but for the moment, I intend to set up what I'm working on as a strawman (there are a few parts that I definitely want to change). In the draft I'm breaking down the functionality into three groups - commands needed for news readering functionality, commands needed for transfer functionality, and commands needed for both. The goal is that eventually (probably not this release) we ought to be able to drop the commands needed for news reading functionality, when the news reading protocol is done. To that end, I now invite your comments about how a news reader protocol ought to be organized. For example: - Should the protocol retain an ASCII command interface, like NNTP? - How can we handle network database access? What interface should be provided for a database? Natural language? Some form of regular expression search? etc? - What form of access control / authentication mechanism should we include? Comments? Eliot Lear [lear@turbo.bio.net]
seven@ftp.com (Benjamin M. Levy) (06/05/91)
From: Eliot <lear@turbo.bio.net>
To: ietf-nntp@turbo.bio.net
Subject: a new nntp draft
To that end, I now invite your comments about how a news reader protocol
ought to be organized. For example:
- Should the protocol retain an ASCII command interface, like NNTP?
yes
- How can we handle network database access? What interface should be
provided for a database? Natural language? Some form of regular
expression search? etc?
IMAP-2 (RFC-1064) has a search command for mail messages. With it
you can search for messages with a given string in CC, BODY, TO, and
TEXT (entire msg). FROM and HEADER should be added to that list.
Also you can search for messages sent BEFORE, SINCE, or ON a certain
date. Also it would be useful to be able to exclude messages.
Something I'd like to see added to NNRP, is a command for getting
the size of a message (like STAT in POP3).
Eliot Lear
[lear@turbo.bio.net]
--
---Ben Levy FTP Software Inc. seven@ftp.com
-----------------------------------------------------------------------
Member of the International Ameoba Society:
"United We Stand, Divided We Multiply"ojala@funet.fi (Petri Ojala) (06/05/91)
> - Should the protocol retain an ASCII command interface, like NNTP? Absolutely. It makes the debugging and client writing much easier. A complex protocol usually requires a complex language to use it but system like News should be possible to be used by a Perl script for example. > - How can we handle network database access? What interface should be > provided for a database? Natural language? Some form of regular > expression search? etc? I think that regexp would be reasonably enough if the search can be limited to certain basic news components like receiver, subject, header or body text. One idea might be to be able to define a number of search rules (what to search, what to exclude, where to search) and then do the actual search based on the previously defined rules. This would make the search very flexible. > Comments? 8bit transparency ? I think that it would be a good idea to have the 8bit support mentioned for the protocol already. The NETF-MHS proposal for 8bit support will include 'magic cookie' for 8bit detection in the HELO-message (SMTP). This might be a possible addition to the new NNTP protocol too ? Regards, Petri Ojala
Harri.Salminen@funet.fi (Harri K Salminen) (06/06/91)
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
Harri.Salminen@funet.fi (Harri K Salminen) (06/06/91)
Your message dated: Tue, 04 Jun 91 13:42:47 PDT
> - What form of access control / authentication mechanism should we include?
My colleague Pekka Kyt|laakso who's just about to join this list
brought just to my attention the version 5 of Kerberos which
is currently in beta test. It seems that it doesn't have anymore
licensing problems since you can ad whatever encryption libraries you
want (and we do have European public DES implementations on the Eurpean
Internet). In addition it seems to support now large interdomain
connectivity and multiple addressing (in case you wanted to run NNTP
over decnet or OSI) etc. There should be more info at the MIT Athena
archive (or nic.funet.fi). So as standard methods we could have
password/userid authentication mode and Kerberos at least. Maybe a separate
command to select some other than standard DES encryption too.
Harri