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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
