Re: [OAUTH-WG] Proposed resolution for issue 26

[Julian Reschke <[e-mail]>]

On 2011-10-05 01:52, Mark Lentczner wrote:
> I think James has made the case that there is an issue clear.
>
> As for what to pick, I favor not restricting scopes in the core spec,
> and clearly specifying the way scopes will be presented in HTTP headers
> in the bearer spec.
>
> For the later, James supplies a nice list of the alternatives.
> Personally, I think the URI-escaping is least likely to trip developers
> up. One must be aware, though, that if there is only one scope string to
> provide, and it meets the token production, then the scope needn't be in
> quotes.
>
> I believe RFC 5987 is vast over-kill in this case. We have no need to
> enable multiple different encodings, nor multiple encodings with a
> single header. Further, I wonder how widespread support for it is in
> various HTTP frameworks.

To answer that: RFC 5987 requires recipients to support UTF-8 and 
ISO-8859-1: so *two* encoding schemes. RFC 5987bis which is currently 
under discussion restricts this further to UTF-8.

HTTP frameworks that support Content-Disposition properly should have 
support for it. I'm not saying that many do right now, but the number is 
growing.

Format-wise: the value field is the same as for URI encoding, except 
that it adds a prefix specifying the encoding (and the optional 
language). It's dead easy to parse as you can just split on single 
quotes, take the first as encoding name and the third as URI-encoded value.

Finally, "just" specifying URI encoding still requires that people are 
told which encoding to use before percent encoding. In RFC 5987 this is 
explicit on the wire. If you do just URI encoding there's always the 
risk that people don't "get" it and just use what seems simple and works 
for ASCII (for instance, String.getBytes() without encoding parameter).

Best regards, Julian