I very much appreciate Eric's response to my message about this
subject. This is a followup to the message from Eric Thomas
<[log in to unmask]> dated Sun, 24 Jan 1999 01:17:03 +0100.

>>As I understand it, in LISTSERV for VM the access-level specified
>>as the fourth word in the value of the Notebook= keyword controls
>>all of the following types of access:
>>
>>1. Who can retrieve the list archive notebooks with the "GET"
>>   command
>>
>>2. Who can retrieve specific messages from the list archive
>>   notebooks with the "GETPOST" command
>>
>>3. Who can retrieve specific messages from the list archive
>>   notebooks by sending an (edited) index back to the
>>   listname-SEARCH-REQUEST address
>
>#3 is just a front-end for #2. I cannot think of any reason to
>enable the one but not the other - some INDEX users may use the
>-SEARCH-REQUEST method while others will send a GETPOST command,
>as a matter of personal preference.

I certainly don't have a strong case for permitting only one of
#2 or #3, but not the other. My (admittedly weak) argument for
permitting #3 but not #2 is that it encourages people to only
retrieve articles from recent Indexes, rather than to fish around
in the archives. While I'd prefer that #2 and #3 could be
controlled separately, I wouldn't have any problem if they could
only be controlled as a combined facility.

>From a security standpoint, there is no reason to allow one of the
>commands in this group but not the others.

You are right that from a security standpoint, if a user has any
of these mechanisms available, he can get all the archived material
and he can then search it all (on his client, if necessary). The
only real distinction is that if the user had the new "SEARCH"
command and nothing else, he really couldn't get any of the
messages. I can't see why you'd want to allow someone to search the
archive, but prevent him from retrieving any messages. On the other
hand, from an obscurity standpoint, it might well be desirable to
allow only certain of these types of access in order to discourage
(although not prevent) behavior that we don't want and to
encourage behavior we do want (by making it easy).

>                                            From a resource
>standpoint, there does not seem to be any reason either. None of
>these commands are resource intensive, except GET if the file is
>really huge, which can be avoided by going from yearly or monthly
>to weekly.

From a resource standpoint, I'm not concerned with items 1, 2, or 3
(listed above), but rather with items 4 and 5 (listed immediately
below).

>>4. Who can search/retrieve the list archive notebooks with CJLI
>>   database search jobs
>>
>>5. Who can search the list archive notebooks with the new
>>   "SEARCH" command
>
>My advice (as I told Noel) would be to work on improving the
>performance of #5, which is suboptimal by default on VM as a large
>increase in VMSIZE is required,

I assume that you mean you advise L-Soft to work on improving the
performance of #5. Or do you just mean that we should run LISTSERV
in a larger virtual machine? Or am I missing something?

>                   and then see what it would take to disable #4.

[Some of Eric's text elided.]

>                                         This means you will not
>get any significant enhancement to #4 (which is easy to disable
>globally). The function you are asking for can be implemented by
>modifying the REXX code, so you could develop it locally.

How would L-Soft's support be affected by our modifying some REXX
code to disable #4? Would it matter whether we disabled #4 on a
per-list basis or site-wide? Would L-Soft be willing to suggest the
change to be made (even if that change were not formally supported?)

>Personally I would try to talk my users into switching to the new
>functions, and then I would disable the old functions completely
>for notebook searches.

I agree. Except that my current level of frustration is such that
"try to talk my users into switching to the new functions" = tell
the users that the old functions will be unavailable as of some
specific date in the relatively near future.

>#5 is a legitimate requirement, although on most systems it is not
>an issue. Of course, on time-sharing systems there is always the
>issue of limited resources at peak hours.

I'm not sure whether you are agreeing that it is legitimate to want
to disable #5 without disabling the retrieval mechanisms (items 1,
2, and 3) or you are saying that it is legitimate to want #5 to run
extremely efficiently. (I hope that you mean both of them.)

>Do other sites need this functionality?

I assume that you asking about the ability to disable #5 without
disabling the retrieval mechanisms (items 1, 2, and 3).

>>One way to accomplish this would be to continue to use the
>>access-level currently specified as the fourth word in the value
>>of the Notebook= keyword to control WHO has access and add a new
>>facility for specifying WHICH of the access methods are available.
>
>Note that this would not work because 'access-level' is any number
>of words.

I may not have been sufficiently clear. I was suggesting that the
Notebook= keyword should stay exactly the way it is today and that
(preferably) there be another header keyword that controlled
exactly what types of access to the archive were available. For
example, the keyword "Archive" might be defined as follows:

Archive= Get|NoGET,Getpost|NoGetpost,Index|NoIndex,CJLI|NoCJLI,
         Search|NoSearch
(to control turning on or off access types 1 through 5 listed above)

Somewhat less preferably, if it couldn't be implemented on per-list
basis (as a list header keyword), then the fall back would be to
implement it on a site-wide basis (as a site configuration keyword).

/David Rosenberg