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
>