> If I use http basic authentication, I can enforce a login.  
> Or I can use
> source IP to tell who they are...

Please no! This causes havoc within HE when we might have students
working from home, or non-University owned accomodation. I've even seen
source ip used for sessioning, which confounds multiple clients on the
same machine or caching (we once found a commercial website, where I
would do the search and my boss got the results due to the fact we were
both going through the same university cache!)

> But without an explicit request to terminate the session, 
> there appears
> to be no other mechanisms than to either
> a) after each search request, leave each user logged in until their
> session times out, or
> b) terminate the session immediately after every search 
> response is sent.

(b) is possible behaviour and is what I believe Ralph effectively does
(or at least wanted the option to do). Assuming a static (or almost
static) database, then any SRW request could be handled by repeating the
previous query with a different start and end to the records returned.
You can then start optimising by caching the last x queries where x is
some value determined by available resources.
 
> It isn't really an issue of resources consumed by open 
> sessions, I could
> care less about that.  Its more of a question on how to accomodate the
> business model where institutional access to a database is sold on a
> simultaneous user basis.  In this model, users are counted as
> simultaneous users from the moment they do their first search, until
> they explicitly logout, or timeout.

As Rob has indicated this is a business model, and one where we have had
quite a bit of discussion. Unlike Z39.50 SRW is not necessarily tied
down to a simultaneous user model where a connected user may be
consuming resources without actually doing anything. SRW works on a
simultaneous request model. Given that the number of active users don't
all issue a query simultaneously, the number of active users can be much
larger that the number of active requests - i.e. SRW can support
implementations that are more efficient than the connection based ones.
 
> One possible way to tell the difference between 'normal' users who are
> doing searches and 'federated systems' might be to compare 
> their values
> for maximumRecords.  I suspect most clients searching a single target
> will have some positive value here and many federated system 
> might have
> maximumRecords=0 if they are in the discovery mode.  My 
> server could log
> out any user after responding to a maximumRecords=0 request, but
> otherwise leave them logged in.

Possibly - however, a client may send a maximumRecords=0 request if they
want to find out how large a record set is before retrieving results,
but having got the size of the result set, then go on to retreive the
first 10 records, next 10 records etc. 

As Rob indicates, one possibility is the 1.1 resultSetTTL value which
the client can use to indicate how long the result set should hang
around. I can't remember all the discussion on this, but perhaps a
resultSetTTL of 0 could be used to explicitly terminate the result set.

However, it isn't clear to me that this is a session in your business
model? i.e. a user logs in, does some (possibly more than one search)
and logs out. We don't define how in SRW an authentication token is
obtained, and ditto for how it is released. Also if you are using HTTP
1.1 you also have the option of using keep-alive, i.e. the http
connection stays open for multiple http requests/response so you can
regard the sesison as over when the http connection is closed.

Of course, for this to work in the general federated case, you probably
want all the SRW servers you are searching to have the same behaviour.
This is probably best done as a federated SRW profile than part of the
core SRW spec (others may differ on this point).

Matthew