I am confused by the process here. The IESG review raised a LONG list of discuss items for the core specification. I was able to successfully address all but three remaining issues:
1. Lack of ABNF - I will do it myself this week since no one else bothered to offer their help. 2. Registry rules - waiting for this to be cleared; have addressed the issue but didn't hear back yet. 3. Comment on not allowing a fragment in redirection and endpoint URIs - waiting for text or item closed. Every other issue for this document has been closed. This WG cannot just go back after WG LC, IETF LC, and IESG review and make changes. This work is done, and any change made at this point must be for the sole purpose of addressing a discuss item. There are no discuss items for *this* document related to errors. They have all been raised in detail, addressed, and closed! As for this survey - While I am still very much opposed to adding the protected resource registry function to the core specification, this new issue clearly demonstrate that this is not simply a matter of adding another error location. The core spec currently provides full guidance and definition for error extensibility. Extending the registry's scope means the need for non-trivial new text that: * explains the process of adding new errors for endpoints not defined by this specification, * finds a common ground for value restrictions beyond what is already listed, * guide authors of future HTTP authentication schemes meant for use with OAuth (e.g. MAC) for their requirements for using the error registry, and * address the very likely scenario of the same error code carrying different meanings in different endpoints, or an extension that adds a location to a code already defined elsewhere - something very likely to happen if you cross the two very different domains (OAuth endpoints, Protected resource endpoints). This requires changing the entire structure of the registry to create separate records for each code/location pair. Any change to the core specification MUST address all these items. This is absolutely NOT a matter of simply adding another location or throwing some extra ABNF. Adding such new text will require another IETF LC and another IESG review - which are completely unjustified based on where the document is in its IESG review process. The point of IESG review is to close issues with minimal changes, not take it as an opportunity to sneak new functionality into the document. And it's not like this WG has not debated these items before, and made consensus calls on them. Not adding the protected resource location to the registry was the result of intense negotiation both on the list and by the design committee. What was the point of asking a few of us to spend hours on the phone debating these issues and reaching a conclusion if it's another popularity contest now. We had FULL consensus by the design committee NOT to add the bearer errors to the core specification, and this recommendation was fully supported by the WG and documented in the issues tracker. These WG surveys are an insult to proper process. EH > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Wednesday, May 09, 2012 3:07 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Encoding of Errors in the Base and in the Bearer Spec > > Hi all, > > another issue that came up in Sean's IESG review was about the encoding of > the error / error_description / error_uri in the base and in the bearer > specification. > > As mentioned in my earlier mail about the registry for the error codes there > are three error fields defined in the two specification and the error / > error_description / error_uri fields are allowed to appear in different parts > of > an HTTP message. > Depending on where they show up different encoding restrictions apply. > > For the core specification these error fields may appear in the > * body of the HTTP message (encoded in JSON) > * parameters to the query component of the redirection URI (using the > "application/x-www-form-urlencoded" format) > > For the bearer specification these error fields appear in the HTTP header. > Consequently, http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19 says > 'values for the "error" and "error_description" attributes MUST NOT include > characters outside the set %x20-21 / %x23-5B / %x5D-7E.' > > Now, here is the question. While these errors are essentially copied over > from one spec to the other the different encoding restrictions make them > different. Do we want different encodings of errors in the two documents? > > So, I see two options: > > 1) Leave the encoding as it is. This means the encoding of the error / > error_description / error_uri in the two specifications is different. > > 2) Harmonize the encoding between the two specifications by incorporating > the restrictions from the bearer specification into the base specification. > > Please indicate your preference by the end of next week (18th May 2012). > > Ciao > Hannes > > _______________________________________________ > 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
