Re: [OAUTH-WG] Possible alternative resolution to issue 26

Hi everyone,

As for encoding, my understanding is that the scope parameter were scope
fields provided by the service provider and that scope should match the
service provider scope. Fair enough, we could argue that non-UTF-8
characters can't be sent over HTTP response headers, so a better solution, I
would suggest is illustrated in section 4.2, Error Handling, of RFC 5987.

My solution: add an encoding as a value of the scope and error-desc,
followed by a colon (:) and then the percentage-encoded message.

So, the message, is first encoded to the encoding specified, and then
percentage-encoded:

Example:

error-descr="UTF-8: <percentage-encoded of an UTF-8 message>"

The client would then:

   1. Percentage decode the string and get the string based on the encoding.

Problem is though, the length of the string value.

Any thoughts?

On 29 September 2011 20:52, Mike Jones <Michael.Jones@microsoft.com> wrote:

>  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
>
>

-- 
The Elite Gentleman