On 2011-10-15 14:16, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Hi Mike,
this is not specific enough. A string could be defined as
"
A string is a sequence of zero or more Unicode characters [UNICODE].
"
(as in RFC 4627), or as
"
8-bit binary data without a NUL (hex 00) termination
"
(as in RADIUS, RFC 2865).
In any case, we have to consider the constraints from the usage of
"application/x-www-form-urlencoded". In our specific case this means
that we have to get from the scope string to an octet sequence, which is
allowed by application/x-www-form-urlencoded.
Julian had pointed to this issue already (see mail from October 7th).
If you want any string (with the exception of SP, which is the
delimiter) then you have to choose an encoding that is able to represent
Unicode in ASCII. There are a few choices and according to Julian the
following options exist:
a) RFC 5987
b) URI encoding to UTF-8 encoding
(which is essentially like RFC 5987 but to omit the language part of the
triple)
Actually, omitting both the charset and the language part, and
hardwiring the encoding to UTF-8.
c) JSON (with the problem that the "\" notation in the quoted-string)
If you want to go along this route then I would suggest to go for (a)
and to include a couple of examples (see Section 3.2.2 of RFC 5987 for
examples). This is clearly better than inventing a new mechanism
ourselves. The language tag is optional and RFC 5987 only requires
parser support for UTF-8 and ISO-8859-1.
...and for RFC5987bis we are discussing to restrict this to UTF-8 only...
Best regards, Julian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
