ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt

[Chris Lewis]

In message "Re: ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt", 
'Chris.Newman at INNOSOFT.COM' writes:

>On Tue, 10 Dec 1996, Brian Hernacki wrote:
>> Interesting reading Nat. After the feedback we received, Ben and I had
>> also been changing our draft to have SEARCH return overview-like data
>> directly (without virtual groups). For demand searching (not profiles)
>> it seems to be a cleaner approach..and people seemd to like this lighter
>> weight approach to SEARCH better. 

>I think Nat has exactly the right idea -- take IMAP's SEARCH command,
>remove the stuff that doesn't apply to NNTP, then add the cross-group
>search using a syntax that could be added to IMAP4 via an extension.  Do
>it that way, and you don't have to fight the character set battle or
>address any of the other problems that IMAP has already solved.

Unless I misread things, I think it might also be worth while to mention
that I find the profile mechanism (having the server remember preferences)
somewhat awkward and too heavy-weight.  The obvious, simply having the
nnrpd (or equivalent) process remember the profile, can cause operational
problems if the server has to restart it for some reason or other.  The
notion of session (with today's offline newsreaders, batching newsreaders,
archaic versions of netscape which spawned nnrpd for every command ;-), and
operational considerations etc) hasn't been clear for quite some time.

A more complex solution, having nnrpd place the profile in a file for
later retrieval causes storage management issues not seen before.

I tend to not like the idea of the server having to retain any more
client-specific state than "current group" and "current article number".

Thus, I prefer a more stateless SEARCH mechanism.  As per syntax, reusing
someone else's standard sounds like a good idea to me.
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis at nortel.ca; Dept 4C16, Ottawa, Canada.  (613) 763-2935.