Date:         Wed, 19 Jun 2002 09:57:22 -0400
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         "LeVan,Ralph" <[log in to unmask]>
Subject:      Re: Betr.: SessionID Summary
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

Having the server determine when to return a sessionID is fine by me.  If
the client isn't interested in sessions, then it can ignore that
information.  Pica can issue a sessionID after authentication and control
the number of users that way or they can provide a separate service to get
the sessionID.  Once we've specified one way to get a sessionID
(automatically from the server) and explained how it is used in subsequent
requests, then other ways to get sessionIDs become someone elses problem.

I agree that sessionIDs and resultSetNames are independent.  The use of
sessionIDs is not mandatory.  The use of resultSetNames is.

Ralph



> -----Original Message-----
> From: Theo van Veen [mailto:[log in to unmask]]
> Sent: Wednesday, June 19, 2002 4:09 AM
> To: [log in to unmask]
> Subject: Betr.: SessionID Summary
>
>
> Instead of bidding (I suppose it is requesting for it) for a
> sessionid, I prefer the server just sends it when it requires
> one. When the client requested it, it will either get one or
> not, and when it did not request one, the server will
> probably send it unsollicited, so what is the benefit of
> requesting it?
> The way the client gets it first sessionid will depend on the
> servers requierements: it may require authentication first or
> it will just provide one (just for its onw benefit). In case
> of authentication (but possibly also in the other case) the
> sessionid will have an encrypted content that is inderstood
> by both the server and the mechanisme that provided it, but
> not by the client. The client will only echo it back to the
> server without any interpretation.
>
> In response to Ray. I prefer sessionid's and resultsetid's to
> be independent of each other, but the server is of course
> free to make the sessionid part of the resultsetid.
>
> Theo
>
>
> >>> [log in to unmask] 18-06-02 17:29 >>>
> Here's where I think we are:
>
> Sessions have been deemed valuable.  I dislike the security
> arguments, but
> am persuaded by Pica's requirement to throttle the number of
> active users.
> Pica's proposal was for a ticket from another service to be
> used.  I don't
> like that, because the use of the ticket will be mandatory
> (at least at
> Pica) and will need to be documented as part of SRW for SRW
> clients to be
> able to talk to Pica.  That causes me to want the session
> mechanism to be
> built into SRW.  Since Pica intends to be an SRU implementor
> (speak up Rob
> or Janifer if I've mispoken!) then the session mechanism
> can't reside in
> SOAP headers.  It must either be in the SRW/SRU message or in cookies.
> Personally, I like the cookie solution, but doubt that we can
> require their
> use at all the places where sessions are needed.  So, the
> client bids for a
> sessionID in a request and gets one (probably with a TTL
> (Time To Live)
> value like resultSetID's).  The sessionID will be used in subsequent
> responses.  (It would be polite if the server ignored the bid
> if it was
> accompanied by a sessionID.  I envision web forms with the
> bid as a static
> hidden field that comes in on all requests, as the client
> might not know if
> this was the first request or not.)
>
> Is this close?
>
> Ralph
>