Dan, Great suggestion. I was also about to propose -32000.
I will update the draft if there are no objects. -vince On Thu, Jul 25, 2013 at 12:24 PM, Harasty, Daniel J <[email protected]>wrote: > 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]> 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]] *On Behalf > Of *Harasty, Daniel J > *Sent:* Thursday, July 25, 2013 8:35 PM > *To:* [email protected] > *Subject:* [paws] response to REGISTRATION_REQ**** > > **** > > Sanjeev mentioned:**** > > **** > > From: [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] > https://www.ietf.org/mailman/listinfo/paws**** > > > > **** > > ** ** > > -- > -vince **** > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
