Two observations:
- I doubt anyone is going to implement RFC 5987 in most OAuth 2.0 libraries, mostly because it offers little value and, - No one really needs scope values other than limited ASCII or URIs There should not be any interoperability issues with the error_description value as long as it is valid for HTTP transport because it is for debugging only. If a provider returns some other character set than plain ASCII in there, it is safe to assume the developer will figure it out. The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs. Crossing the boundaries of v2 into the bearer spec is the first place where this flexibility has been tested. Scope are machine-readable strings and URIs already provide a way to include internationalization. OAuth parameters are all in English and it is reasonable to expect most providers to craft their scope values within those undeclared boundaries. I am not expressing a strong opinion because I don't think this is a real issue. Internationalization matters when it comes to end-user interaction, not developers. But the most consistent choice based on the past 2 years of use cases and examples is to simply limit the scope character-set in v2 and avoid all this. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, September 30, 2011 8:20 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 Thus far, I've received no responses preferring 1 or 2 or preferring A or B. Could people please weigh in so that the working group has data to base a decision on to close this issue? Thanks, -- Mike From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> On Behalf Of Mike Jones Sent: Thursday, September 29, 2011 11:53 AM To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII characters in scope strings than had previously been in evidence. If we decide to define a standard representation for doing so, using RFC 5987<http://tools.ietf.org/html/rfc5987> (Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the clear choice. I'd be interested in knowing how many working group members are in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying UTF-8 encoding of the error_description value, requesting the use of RFC 5987 encoding instead. I'd also be interested in knowing how many working group members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description parameter. (As editor, I would make the observation that if we choose RFC 5987 encoding for either of these parameters, it would be logical to do so for the other one as well.) In the interest of finishing the specification in a way that meets everyone's needs, -- Mike
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
