I also prefer option # 1 for the same reasons as Gabor and Don. Nancy On Sep 5, 2013, at 9:38 PM, <[email protected]> wrote:
> As an individual (and not as chair), I also prefer option #1, for the exact > same reasons as Don. > And yes, we’ll need to conclude on this soon, so anyone with an opinion, > please speak up. > > - Gabor > > From: [email protected] [mailto:[email protected]] On Behalf Of ext > Harasty, Daniel J > Sent: Thursday, September 05, 2013 12:58 PM > To: [email protected] > Subject: Re: [paws] Spectrum_use_notify as pure notification > > I do prefer Option 2 – after all, I proposed it. > > However I admit there is no harm in keeping the regular JSON-RPC response > around, as per Draft 06 – even though it is semantically empty. > > If anyone else is strongly in favor of “Option 2”, please speak up, as I > believe Vince is going to make an editorial call on this one soon. > > Dan Harasty > > > From: [email protected] [mailto:[email protected]] On Behalf Of Don > Joslyn > Sent: Thursday, September 05, 2013 10:36 AM > To: Vincent Chen; Michael Head > Cc: [email protected] > Subject: Re: [paws] Spectrum_use_notify as pure notification > > I vote for option #1, keep it the way it is currently defined in Draft 06. > The main justification is the current notification message flow defined in > Draft 06 can be easily extended to include additional parameters in the reply > sent back to the radio. If we change it to a pure JSON notification, then we > lose this capability. > > Thanks, > Don > > From: [email protected] [mailto:[email protected]] On Behalf Of > Vincent Chen > Sent: Tuesday, September 3, 2013 12:33 PM > To: Michael Head > Cc: [email protected] > Subject: Re: [paws] Spectrum_use_notify as pure notification > > > I suppose it does not make sense to change the spec to using JSON-RPC > notification, then allow for deviation. > > So, could we see if there is a consensus for one of the following? > > Option 1: No change to Draft 06: notifySpectrumUse is a JSON-RPC request, > with a response that contains only the message type and version: > > { > "jsonrpc": "2.0", > "result": { > "type": "SPECTRUM_USE_RESP", > "version": "1.0" > }, > "id": "xxxxxxx" > } > > Option 2: Change notifySpectrumUse to be a pure JSON-RPC notification that > will not have a JSON-RPC response (i.e., empty HTTP response body). > > Thanks. > > -vince > > > On Sat, Aug 24, 2013 at 4:19 PM, Michael Head <[email protected]> wrote: > If spectrum_use_notify is a pure JSON-RPC notification, this could be a > problem for our implementation. > > We can't easily guarantee that the there would be no JSON-RPC response body > for this method, but I believe JSON-RPC requires this for notification calls. > > If clients would ignore any body included in the response, then it would be > fine for us, but I suppose the specification would need to make special note > of that deviation from the JSON-RPC spec. > > Thanks, > -- mike > > -- > ---------------------------------- > Michael R Head <[email protected]> > http://www.cs.binghamton.edu/~mike > +1-201-BLISTER > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > > > > > -- > -vince > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
