> >I agree - what Janifer is talking about is a user authentication token -
> >not a session id. The original objection to Janifer was that a session
> >id is much more easily forged than a username as password (as Rob has
> >pointed out a session id may be little more that an incremented number).

(I pointed out resultset id, but the same is true of a session id)

> I disagree. It is trivial to make a session ID secure.
> a) Let a session id be 64 bits (a bit short for a session id)

Which for SRU will be 64 of the 256 characters in the URL?

> The problem of not having an optional! session id is that some implementers
> will be forced to introduce set ids with implicit sessions ids. Some servers
> simply need session ids as soon as sets or authorisation are involved.

Yes.

For the record, I think we should distinguish between a session id and
user authentication.  You might want to have a session id /and/ user
authentication for useful access to closed databases. Or you might not
care about sessions (though the server would be much less useful, OAI on
crack basically) but you still need to limit access to it. Or you might
have an open access database with sessions.

Rob

--
      ,'/:.          Rob Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/
I L L U M I N A T I