I have to admit I feel a bit lost about who is going to use this but
assuming the protocol will be used as a computer/computer protocol in
applications I would like to advocate session id's for a last time.

Matthew wrote:
>Also I feel that introducing session id as an optional parameter is
>going to get very messy and introduce interoperability issues.

My problem is the following. After strugling with a HTML/Z39.50 gate I now
run a retrieval engine that talks xml or html over http (no underlying
Z39.50 layers, for Z39.50 clients we run Z39.50 on top of the xml layer).
Queries are either "post" or "get" method forms. The server is context free
but uses a session id to keep track of previous queries. The session id is
also used to authenticate users and serves handle to user "rights". The
server is a popular target in broadcast searches.

Authentication is done by a separate server. The authentication process is
in fact much more expensive than the average query. Checking the session id
is dirt cheap. Queries without session id are accepted and result in a new
session id (or a refusal if no uid and password are present).

Our users (universities) buy the right for a number of simultanious
sessions. This is realised by limiting the number of "active" session ids. A
session ID is guaranteed not to time out whithin five minutes after the last
usage.

If we hide the session id in a setid it means that the user should always
include the setid otherwise we can not retrieve the session id. The end
effect is that the user session could be kicked. This will be great for
marketing but less honest towards our customers. An explicit session id
would solve this.

In actual fact I do not know how relevant all this is. I dream of well
behaved university "broadcast" queries. At the moment, due to "session free"
Z39.50 queries, the server sometimes looks more an authentication engine
than a retrieval engine. Maybe that is life :).

Matthew wrote:
>The current model we have of an essentially sessionless WebService but
>with the ability to maintain state via result set ids, I believe works.

Of course this works but it limits us to "short" sessions. It is a bit like
FTP using a browser (ever tried to access a busy ftp server with a limit on
the number of sessions over the web?). It is extremely boring when
authentication is expensive and involving external servers.

In the standard we could simply state that a server can return a
sid/authentication id. The client should return this in subsequent actions
instead of username/password.

[
by the way set id's (and sessions id's) need not be long, about 11 positions
for 64 bits using rad64 encoding. The 256 byte url limit is not hard. Wise
servers accept more. If we would also accept "post" methods next to "get" it
is irrelevant (this makes almost no difference in handling requests). The
main reason of having the set id is to let users help the computer to refer
to elements of the set cheaply. I see no reason to combine sets in a
computer/computer environment (but no reason to forbid them either).

I think by the way that most servers would not do boolean set combinations
over multiple session id's. This makes implementing them on top of existing
session id oriented servers quite complicated.
]

Theo wrote
> Question: when there is a "authorisation ticket" as
> parameter, who still needs a sessionid and what for?

Yes what is in a name. They could be precisely the same.


Rob Koopman