Vince, On your "point 1", I thought I had some good examples in mind. But, now that you ask, I can't yet make the case that my proposed PAWS "REGISTRATION_ERROR" is any better than other existing PAWS error codes, or a generic "server error".
While the Devices certainly must deal with the possible HTTP 5xx error, I suggest the server should attempt to send a JSONRPC "SERVER ERROR" (-32000). See: http://www.jsonrpc.org/specification#error_object. I'd like to recommend that the PAWS spec reference these "standard JSONRPC error codes", and add a statement to the effect of this: When an error condition exists, a Database SHOULD attempt to use the most specific applicable PAWS error. When an accurate one is not available, it SHOULD fallback to standard JSONRPC error codes as defined in JSONRPC specifications. As a last result, the Database MAY send a suitable HTTP 5xx response. Dan From: Vincent Chen [mailto:[email protected]] Sent: Thursday, July 25, 2013 12:00 PM To: Sajeev Manikkoth Cc: Harasty, Daniel J; [email protected] Subject: Re: [paws] response to REGISTRATION_REQ Dan, Sajeev, I was assuming that general "server errors" would be handled at the HTTP layer with 5xx codes. 1. For REGISTRATION_REQ, what error conditions should we be capturing? - Some internal error, but can try again later? 2. SPECTRUM_USE_NOTIFY. What would the device do differently if it did get an error? I was assuming that this is a async notify, fire-and-forget, from the perspective of the device -vince On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth <[email protected]<mailto:[email protected]>> wrote: Hi Daniel, First of all thank you very much for streamlining my comments, and splitting it into separate email topics. May be I need to take care of it next time.. Yes, the semantic you suggest here also can be the solution. My point was, an authorized master's request also can fail, because of load at database, or due to request semantic error. As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a generic response accepted/denied. Best Regards, Sajeev From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Harasty, Daniel J Sent: Thursday, July 25, 2013 8:35 PM To: [email protected]<mailto:[email protected]> Subject: [paws] response to REGISTRATION_REQ Sanjeev mentioned: From: [email protected]<mailto:[email protected]> Sent: Thursday, July 25, 2013 10:31 AM [...] 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database? [...] As for possible responses to REGISTRATION_REQ, I have been planning to suggest this: I think we need a new generic error code "REGISTRATION_FAILED". Perhaps a value -203, or the next available -200-block code. This should be used by the Database in response to a REGISTRATION_REQ if no other more specific code is applicable. (For example: if a registration failed due to a missing field in REGISTRATION_REQ, the Database should still send the REQUIRED error; if a REGISTRATION_REQ failed due to the Device being unauthorized, the Database should still send the UNAUTHORIZED error.) Sanjeev: does that address your need sentiment for "a denied registration"? Dan (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.) _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
