The text in -11 was from the initial extensibility draft and was removed when I revisited the issue and could not come up with any requirements for extending error codes. You made a claim that an error code registry aids interoperability but offered no use cases or requirements showing how this new registry solves an actual problem.
As most people who ever interacted with an IANA registry know, very few actually help interoperability. Most just frustrate developers for no good reason to the point where the registry is the least useful reference. If you notice the new extensibility language in -13, it makes the registry less strict in its requirements for vendor-specific parameters. IOW, it defines the bare minimum needed to help avoid parameter name collision. But the error code registry is only one issue. Your proposal goes further and defines two new locations for which you have provided no requirements and use cases to show how your solution solves a problem. We can add plenty of registries: an endpoint registry for future new endpoints like a device endpoint, a client authentication registry, a grant type registry for extension URI types, a registry for non-URI callback values, etc. The bottom line, a registry is meant to reduce the likelihood of namespace collisions where such a collision will *actually* cause interoperability problems. If you want to add an error code registry, you MUST provide at least one example of an error code you plan to introduce that will require registration or interoperability will fail. 'Aids interoperability' is not a justification if you don't actually show how your solution accomplishes it (and what problem is this solution trying to solve). EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Monday, February 28, 2011 1:34 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call I realize that we disagree. Unless you change your position, it seems that the working group will need to decide whether registering error codes aids interoperability. I believe that it does. (You also appeared to agree as well in draft 11, in which you included the text "[[ Add mechanism for extending error codes ]".) -- Mike From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Monday, February 28, 2011 1:27 PM To: Mike Jones Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call My last note on this was: --- OAuth 2.0 defines two endpoint, each with a set of error codes. These codes are not extensible and therefore do not require a registry. If you want to allow error code extensibility, you need to make the case for that with requirements and use cases. I have not seen any. My API uses the 'position' parameter for protected resources. Am I expected to register it? It has nothing to do with OAuth, but if I supported Bearer token would be used alongside the 'oauth_token' parameter. The 'oauth_token' parameter is an nasty hack to make it easy for developers to access protected resources without using the Authorization header (based on browser limitations from 4 years ago). Defining a registry for this parameter is just adding insult to injury. The bearer token draft can define whatever registries it want for those using *bearer* tokens. It has no say on anything else. Period. If you want to make changed to other drafts, you need to make a case and build consensus. By definition, your drafts cannot change any requirement in other drafts unless you update them (this is an IETF process rule). Can you provide use cases, requirements, and examples for each of your new proposals? --- Did I miss a reply? EHL From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Monday, February 28, 2011 1:25 PM To: Eran Hammer-Lahav; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call I did not ignore your feedback. I replied to it, pointing out why I believe your position is incorrect. From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Monday, February 28, 2011 1:14 PM To: Mike Jones; Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last call I am opposed to all the new registration changes and requirements which have any impact on draft-ietf-oauth-v2. This request seems a bit odd given my feedback (which you have, again, ignored). EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, February 28, 2011 12:51 PM To: Hannes Tschofenig; Blaine Cook Cc: oauth@ietf.org Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last call As editor, having received no comments on the normative content of draft-ietf-oauth-v2-bearer-03, and having made no breaking changes since draft -01, other than one change voted upon by the working group, I believe that draft-ietf-oauth-v2-bearer-03 is ready for working group last call. I'll note that this draft requires editorial updates to the IANA Considerations section framework specification to register its errors. This should happen in draft -14 at the same time that the security considerations are added. At that point, hopefully we can go to working group last call on the framework specification as well. -- Mike
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
