I expect that this extension will be in the future be used quite often
for sru clients, so lets keep the sru parameter name/value short, e.g
-x=ok.
The main reason for my expectation is that this extension allows
servers and users to communicate with each other without being
restricted by the limited capabilities of static clients. I anticipate
clients that can be adapted by the user to fit the users needs based on
what a server may have to offer.
Theo
>>> [log in to unmask] 03-01-2005 17:06 >>>
> I know that Rob has already addressed these points, but it really
> can't be said too many times. SRW/U implementations simply may not
do
> this. They're just not allowed. It's not an implementation-level
> decision, but a protocol-level one.
Hold on. There are good reasons (in some situations) for a server not
to
send unsolicited data, and good reasons (in some situations) to do so,
as
Rob and Bill respectively have pointed out. I noted when this
discussion
came up before that I would define an extension "permission to send
unsolicited data" and everyone seemed comfortable with this approach.
To this end I have defined this extension, listed at
http://www.loc.gov/z3950/agency/zing/srw/extra-data.html#infoURI
info:srw/extension/1/will-accept-any-extra-data
So if a client is prepared to accept unsolicited extra data it
includes
this extension in the request. If it doesn't include it, then the
rules
disallowing unrequested extra data prevail.
--Ray
|