Date:         Tue, 4 Jan 2005 09:22:03 +0100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Theo van Veen <[log in to unmask]>
Subject:      Betr.: Unsolicited response data (Re: British Library Test SRU
              Service)
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline

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