 |
 |
I agree with Theo (I think). The current model we have of an essentially sessionless WebService but with the ability to maintain state via result set ids, I believe works. Provided we use an approach such as Rob Koopman suggests we shouldn't be open to DDOS attacks. Provided the TTL values are reasonable there should be no need to have an explicit delete result set operation (which is what Ray seems to be edging towards). Whilst a server shouldn't delete result sets before an id's TTL has expired, such rules would be broken if the server were overloaded (when we would be in error condition mode regardless of whether the server decided to delete existing unexpired result sets or refuse to create new ones). Also I feel that introducing session id as an optional parameter is going to get very messy and introduce interoperability issues. We may need to look at the authentication model a little more closely. At present I believe we can optionally send a username/password in the SOAP:Headers? We may wish to allow the server to optionally respond (again in headers) with an authentication token that the client can subsequently use in preference to the username/password. However, the server should not reject a request just because the client chose to resend the username/password instead of the assigned token. I think that introduces a way to address Janifer's issues without major interoperability problems. If there is strong feeling to start re-introducing Z39.50 machinery such as client named result sets with delete operations etc. I would suggest that those who need that sort of thing should opt for my parallel ZiNG suggestion of wrapping XER in SOAP (after all it is only an implementers agreement that we do BER over TCP/IP - this isn't prescribed in the Z39.50 standard, and I gather from the ASN.1 crowd that technically the way we do it isn't correct ISO8825 behaviour anyway, in that the client/server should be able to negotiate the encoding). Matthew > -----Original Message----- > From: Theo van Veen [mailto:[log in to unmask]] > Sent: 15 June 2002 02:38 > To: [log in to unmask] > Subject: Re: session ids and result set ids > > > On 14 Jun 02, at 17:53, Ray Denenberg wrote: > > > The folks who want the session id seem to be happy > > if it's optional. Nobody seems to object to an > > *optional* session id. There is at least one > > implementor who claims not to support result set > > ids (Ralph). Is it fair to say, though, that if > > you do support result set ids then you support > > session ids? > > No. We support resultset ids but not session ids. A resultset > is an existing set of records. Sessions we just do not know > what it is. > > > > > So if a client sends a session id, if the server > > supports it, he echoes it in the response and if > > not, ignores it (so if it is not echoed the client > > knows that the server doesn't support it). And if > > the server doesn't support it, then it also > > doesn't support result set ids (and signifies this > > by not echoing it). > > > > Will this work? > > No. > > Lets keep it simple and just treat things as they are. What > is a session? Especially in a web environment the context of > a request is not the same as the session context. When u user > goes back a few pages in his history what is his session > context? His current page or the last page he requested? > Sessions were nice when a user had a connection with a telnet > client and only the server was aware of the sequence of actions. > > Currrently we may recognize resultsets and we may recognize > users but I do not know what a session is. The only thing > that looks a liitle bit like the sessions from the old days > is the use of cookies in a browser session: cookies that are > stored as long as you do not stop your browser. But I see > that more as an alternative to time out the validity of a > user authentication. > > BUT: when a server wants to specify some kind of property > that it wants to have returned at a next request, lets call > it <sessionid> and let it be sibling to <resultsetname>. BUT: > for the client both sessionid and resultsetid and > "authorisation ticket" are different things. > > Question: when there is a "authorisation ticket" as > parameter, who still needs a sessionid and what for? > > Theo >