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
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.
>>> [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
> 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
send unsolicited data, and good reasons (in some situations) to do so,
Rob and Bill respectively have pointed out. I noted when this
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
So if a client is prepared to accept unsolicited extra data it
this extension in the request. If it doesn't include it, then the
disallowing unrequested extra data prevail.