'PROPER' REQUIRES USE CASES AND REQUIREMENTS! You have to show how the proposal does not satisfy you requirements. It fully satisfies all the requirements presented to the working group.
EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tony...@microsoft.com] > Sent: Thursday, March 31, 2011 11:40 AM > To: Mike Jones; Eran Hammer-Lahav; OAuth WG > Subject: RE: Error extensibility proposal > > I also object, an error registry the proper approach here. > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Mike Jones > Sent: Thursday, March 31, 2011 11:31 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Error extensibility proposal > > I object to this proposal on two grounds: > > First, changing some of the "error" return codes to HTTP numbers is an > unnecessary and unsolicited breaking change at a time that we should be > stabilizing the spec. > > Second, the OAuth Errors registry is simpler and follows IETF standard > practices. I know of no other specification where a parameters registry is > overloaded in this manner. Please incorporate the OAuth Errors registry into > the framework specification in lieu of this proposal. > > Thank you, > -- Mike > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, March 29, 2011 4:02 PM > To: OAuth WG > Subject: [OAUTH-WG] Error extensibility proposal > > *** Requirements > > The following proposal is based on two requirements: > > 1. Provide a way to return an OAuth error response for error situations other > then 400 and 401. For example, if the server is temporarily unavailable, it > will > return an HTTP 503 status. However, it is often desirable to still return a > response body using the same format as any other error. This makes client > development easier, having to always check for a single error code. > > 2. Allow extensions modifying the behavior of the authorization and token > endpoints via additional request/response parameters to define additional > error codes to go along with the new functionality. For example, the UX > extension defines the 'display' parameter. It could define a matching > 'unsupported_display' error response. > > No other use cases were identified for error extensibility. Note that this > proposal is strictly limited to error resulting from the authorization and > token > endpoints. No other endpoints are included (in particular, protected > resources are not covered by this proposal). > > *** Design goals > > The proposal was specifically designed to be minimalistic, tailored to the > specific use cases defined, and as effortless as possible. This avoids > defining > error codes identical to existing HTTP status codes, as well as bind new > errors > to specific extension parameters. Since the error is useless without > understanding the extension, this method guarantees that those developing > and implementing extensions will present it as a complete unit. > > *** Proposal > > - Non 400/401 responses > > If the HTTP response status code is 4xx (other than 400/401) or 5xx, the > 'error' parameter SHOULD be set to the HTTP status code. For example: > > HTTP/1.1 503 Service Unavailable > Content-Type: application/json > Cache-Control: no-store > > { > "error":"503" > } > > This will also enable passing HTTP status codes such as 503 via the > redirection > response which is currently not possible. It will allow the authorization > server > to indicate a 503 situation without defining another error code that has the > exact same meaning. > > - Extension errors > > Instead of defining an additional error registry, I propose we add a single > field > to the 'OAuth parameters registry' template: > > Additional error codes: > Additional error codes related to the parameter usage. Error codes > SHOULD begin with the parameter name > when possible (e.g. 'example_invalid' error code for use with the > 'example' parameter). > > Error collisions are unlikely because when a new extension is authored, the > registry is reviewed for potential conflicts. Since the errors are extension- > specific, collisions only matter if two extensions are to be used together. In > that case, the review process will identify any potential problems. And since > the errors are meaningless without understanding the extension, a registry > with a random list of errors is not very helpful. > > *** Feedback > > Please send any feedback, comments, support, and objections by 3/1 (so it > can be included or not in -14). > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
