Hi Marius, > -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Thursday, March 31, 2011 6:07 PM
> Many error codes (if not most) are not parameter specific. Like what? After a long debate, not a single use case was presented for a new error code that is not: 1. overlapping with an existing HTTP code (4xx, 5xx) 2. directly relates to an extension parameter Present new use cases and I'll reconsider. This proposal is 100% fit for the given requirements. > Will this lead to the registration of fake parameter names just to be used as > error prefixes? No. If there is an actual need to define a new error code that is not related to at least one extension, I agree that we need a different solution (we can always use the ability to update the RFC). But I have not seen any such need. In fact, I argue that such additional generic error codes are bad for interoperability. If every client implements the same set of error codes defined in v2, we know that they will all interop well when it comes to an error condition. If the error is the result of an extension, the client must understand that extension to understand any additional error code. Nothing but extension parameter can change the behavior of this protocol. We don't have other extension points that can produce such a change. No change - no new error conditions. Another example of error code extensibility is the need to express more specific error conditions related to extension grant types. It might be necessary to express why a grant type was rejected, beyond just 'invalid_grand'. However, *replacing* 'invalid_grant' with a more specific error code would be bad for interoperability because it will break existing libraries designed to be extensible but do not offer a fully extensible error code handler (just not likely). The right solution would be to define an additional, grant-type-specific response parameter that will provide sub-meaning to the 'invalid_grant' code. In this case, no new error codes are even registered, just an extension response parameter. > If we are going down this route, why don't we require extensions to register > just a prefix? What route? Registering a prefix is a good idea if we expect a flood of extension parameters. I'm not. <rant> The bottom line is that this proposal is purposely not creating an open-ended registry that will end up being as counter-productive as the OAuth 1.0 error codes wiki page. It is design to put the least amount of process and hurdle in the way of developer extending the protocol. I am happy to suggest alternatives or even adopt Mike Jones' proposal for an error registry if only someone can present a *single* use case that defines a new requirement not covered by this proposal. Give me just *one* example where this is incomplete. But short of that, discussing the shortcoming of a proposal without clear requirements is a total waste of time. Extensibility is where most protocol fuck up (pardon my language). It is where crap enters the protocol, pollutes the flow, and breaks interop. We can define experimental features - that's fine because if they fail they just don't get adopted. But unchecked extensibility is how you end up with WS-*, and SOAP, and a never ending list of crap that offers no shred of interop because it was extended beyond recognition. </rant> EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
