The question is do we support unpaired response/request messages. A 1.2
version client may send a request for an operation which is unsupported
for a 1.2 server but unknown for a 1.1 server. So clients have to deal
with unpaired response/request messages anyway.
Another example could be that a searchRetrieveRequest with the
"scanOnFail" flag set responds with a scanResponse when a search fails.
The alternative would be to use extraResponseData for the results.
Theo
>>> [log in to unmask] 1-3-04 12:50:10 >>>
> I agree that our server does it wrong and we will change it. On the
> other hand I would support to allow unpaired response/request
messages
> because I think that it allows much more flexible with respect to
future
> extensions.
> In case you receive a "specialTheoRequest" (which is not supported)
> what would be the appropriate response? And what would be the
> alternative response on a searchRetrieveRequest with the
"scanOnFail"
> flag set?
To reiterate what was discussed last time:
If you receive an unknown operation in SRW, you return a SOAP fault.
If you receive an unknown operation in SRU, you return an explain
response with a diagnostic, or if the operation parameter is omitted.
If you recieve an unsupported extension, then you must return the type
of
response that is paired with the request. You may return a
diagnostic,
but there is no requirement to do so, as extensions can be silently
ignored.
If you recieve an unsupported operation, you should return the right
type
of response with a diagnostic. Just a boilerplate "I don't do that"
answer will suffice.
Rob
--
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I
