Subject: Re: [paws] Spectrum_use_notify as pure notification

From: Vincent Chen <[email-masked]>
Date: Tue, 3 Sep 2013 09:32:35 -0700

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-masked]> 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-masked]>
> http://www.cs.binghamton.edu/~mike
> +1-201-BLISTER
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: Don Joslyn <[email-masked]>
Date: Thu, 5 Sep 2013 10:35:58 -0400

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-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Tuesday, September 3, 2013 12:33 PM
To: Michael Head
Cc: [email-masked]
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.

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": {

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>>
http://www.cs.binghamton.edu/~mike
+1-201-BLISTER

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Thu, 5 Sep 2013 19:58:19 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Don Joslyn
Sent: Thursday, September 05, 2013 10:36 AM
To: Vincent Chen; Michael Head
Cc: [email-masked]
Subject: Re: [paws] Spectrum_use_notify as pure notification

Thanks,
Don

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Tuesday, September 3, 2013 12:33 PM
To: Michael Head
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Spectrum_use_notify as pure notification

{
  "jsonrpc": "2.0",
  "result": {

Thanks.

-vince

Thanks,
-- mike

--
-vince

---

From: <[email-masked]>
Date: Fri, 6 Sep 2013 01:38:10 +0000

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-masked] [mailto:[email-masked]] On Behalf Of ext Harasty, Daniel J
Sent: Thursday, September 05, 2013 12:58 PM
To: [email-masked]
Subject: Re: [paws] Spectrum_use_notify as pure notification

Dan Harasty

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Don Joslyn

Thanks,
Don

{
  "jsonrpc": "2.0",
  "result": {

Thanks.

-vince

Thanks,
-- mike

--
-vince

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 5 Sep 2013 21:47:29 -0400

I also prefer option # 1 for the same reasons as Gabor and Don.

Nancy
On Sep 5, 2013, at 9:38 PM, <[email-masked]> wrote:

> And yes, we’ll need to conclude on this soon, so anyone with an opinion, please speak up.
>  
> -          Gabor
>  
> 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: Ray Bellis <[email-masked]>
Date: Fri, 6 Sep 2013 09:06:37 +0000

> I also prefer option # 1 for the same reasons as Gabor and Don.

+1

Ray

---

From: Michael Head <[email-masked]>
Date: Fri, 6 Sep 2013 08:01:06 -0700

Following up, I prefer option #1.

Since all the other requests and responses are extensible, it seems awkward
to strictly limit the response for just this one call.

-- mike