Matthew Dovey wrote:
> should be no need to have an explicit delete result set operation (which
> is what Ray seems to be edging towards).
No, I have no interest in introducing this.
> Also I feel that introducing session id as an optional parameter is
> going to get very messy and introduce interoperability issues.
I think a session id will be no more or less of an interoperability problem
than the reference id in Z39.50. And the only problem that it has caused is
to those who abuse it (i.e. don't use it as specified, very explicitly, in
the protocol). True, the reference id in Z39.50 has been nearly useless,
because the protocol never specified, and implementors could never agree,
what it was supposed to be used for. We're a much smaller group, and I think
we have a much more focused idea about why we want such a thing, and a
reason with more reality (as compared with the artificial justification for
it in Z39.50).
The sever would supply it in a response. The client, on receipt of a
response could ignore it if it doesn't understand/support it, or could
include it as appropriate in a subequent request. If it ignores it, there's
some loss of functionality but where's the potential interoperability
Similarly, the server would omit the session id if it doesn't support it.
The server receiving a request without a session id treats it as a new
session (and either assigns a new session id or doesn't). The client
wouldn't send a session id on an "initial" request (one with no history)
and if the server recieves a request with a session id it doesn't know
about, it's an error. How does this "get very messy" or create
I do feel strongly we should include it, because it appears we may lose
potential implementors without it.
I reject (a priori) arguments that what we're talking about doing is
re-iventing the useless Z39.50 reference id. Instead, we're making it