> Then it's not really a session id that's needed, but rather, a client id?

Well, if you want to have result sets persist over sessions, then I guess
so.  But then you're really just saying that a session can last for an
indefinite amount of time.

My suggestion would be:  When a client connects, if a session id is not
supplied, then it generates a new one and returns it. Otherwise resume the
previous session.  Then if the client choses to retain the id somehow, it
becomes a client id, but there's no way to mandate this behaviour
(obviously).

Session IDs IMO should go as a Must Understand SOAP header, but could
equally be part of the XML proper.

Rob

(The reason I bring this up is that I just wrote an implementation of SOAP
and this sort of thing was an issue for one of my projected uses)


> > > Not so. In SRW (unlike Z39.50) the result set name is really a result
> > > set identifier generated by the server rather than requested by the
> > > client. So in SRW the result set name effectively acts as a session id.
> >
> > Yes. But if they persist, which they must in some form, then they can be
> > operated on.
> > For example, I send to client A a result set named 'rs1'. The rogue DDOS
> > client then sends me a request against a result set named 'rs1' which
> > promptly disappears for the real user.
> > In the time between the server sending the resultset name to the client, a
> > different attacking client can send a request which uses that name. You
> > simply can't avoid that. You need to have a way of determining if the
> > client is allowed to operate on that result set.


--
      ,'/:.          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