Re: "checklist" for NIR Report

April Marine <> Sun, 17 October 1993 20:03 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa19033; 17 Oct 93 16:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19029; 17 Oct 93 16:03 EDT
Received: from by CNRI.Reston.VA.US id aa10997; 17 Oct 93 16:03 EDT
Via:; Sun, 17 Oct 1993 21:03:03 +0100
X-Version: Mailbase (TM) Enhanced List Manager Version 2.3
Received: from [+JANET.000040010500/FTP.MAIL] by; Sun, 17 Oct 1993 20:56:52 +0100
Received: from by with Internet SMTP id <>; Sun, 17 Oct 1993 20:56:11 +0100
Received: from by with SMTP (PP); Sun, 17 Oct 1993 12:56:02 -0700
To: "Karen R. Sollins" <>
Subject: Re: "checklist" for NIR Report
In-Reply-To: Your message of "Mon, 11 Oct 1993 20:42:10 EDT." <>
Date: Sun, 17 Oct 1993 12:56:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: April Marine <>
Reply-To: April Marine <>
Precedence: list
Message-ID: <9310171603.aa10997@CNRI.Reston.VA.US>


Thank you for your very thoughtful reading and reply to the checklist
I sent out a week or more ago (time flies...).  Apologies for not
getting back to you sooner.  I think you brought up some excellent
points, a few of which were wandering around my head as well.

>First, did any of the labels include the issue of whether the service
>in question required importation of information in order to be
>accessible?  The question is whether, for example, a particular
>service sits on top of an existing set of NFS's and AFS's, accessing
>information by going through the requisite file system, or whether the
>files or other objects must be imported into the service in order to
>be accessible through it.

The checklist did not include such information, but it was something
I did wonder about including.  It would probably be a good thing to
include, but is probably not something I'm able to come up with on
my own (one reason I decided to leave it out of the first go round).

>There is another issue that I think is important in information
>retrieval systems.  Some systems are designed specifically as single
>user applications.  There may be several interfaces to them, such as a
>window-based on or a dumb-terminal interface, or perhaps Xmosaic.  But
>there is one set of functions that the system is designed to support
>for users, so the applications are extremely limited.  Other systems
>are designed to be infrastructure on top of which a variety of
>applications might be built.  Of course, there will be vanilla
>applications that provide somewhat direct browsing, but these systems
>were designed with the idea in mind that they were multi-purpose,
>perhaps browsing, editing, usable by other services to provide
>enhanced (and perhaps at present unforseeable) services and

Ah.  I have no objections to changing the checklist around to include
this idea, although I'm not sure how to define its scope.  How
infrastructure-friendly is friendly enough to get a check mark in
this column?

>A third part of the table that I find a little confusing is the
>section on platforms.  Especially in the case of clients there seems
>to be a confusion between platforms and protocols.

:-) Yet something else I was worried about, knowing my own confusions
here!  There were indeed times when I was confused about which bits
of info to pluck out of the longer descriptions of the report (we might
want to check and make sure those descriptions are consistent as well).
I was hoping the WG could help clean this part up.

Basically (this directed to all, not Karen in particular), I tried to
come up with something the whole WG could pick at and improve.  It
is much easier to do that when there is something in front of us
than out of the air.  At the same time, I wanted to keep it as simple
as possible, answering in the checklist format only those first
basic questions someone would have.  After isolating an application
via the checklist, more detailed info could be found in the lengthier
descriptions in the report.