On 25 Jul 2013, at 21:06, "Harasty, Daniel J" <[email protected]<mailto:[email protected]>> wrote:
The JSONRPC spec defines a “notification” as a type of request that needs no response; in fact a response is not even allowed. Since the PAWS SPECTRUM_USE_NOTIFY is “this kind of message” semantically (note that SPECTRUM_USE_RESP is empty), I propose we: • State that the SPECTRUM_USE_NOTIFY uses the JSONRPC “Notification” Request object (see: http://www.jsonrpc.org/specification#notification), and • That we eliminate the SPECTRUM_USE_RESP from the PAWS spec. This is consistent with Vince’s characterization that SPECTRUM_USE_NOTIFY is an “async notify, fire-and-forget, from the perspective of the device”. The UK pilot spec requires that the WSDB tell the device to stop transmitting if the channel usage parameters are inconsistent with those that the WSDB issued, i.e. it is not merely "informational". I note however that there appears to be no such specific requirement in the ETSI draft. In my (non PAWS) implementation I was expecting to return an immediate error in these circumstances, rather than wait for the device's next 15 minute poll. Ray
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
