On 2012-06-12 00:16, Mike Jones wrote:
Reviewing the feedback from Julian, John, and James, I'm coming to the
conclusion that client_id and client_secret, being for machines and not humans,
should be ASCII, whereas username and password should be Unicode, since they
are for humans. Per John's feedback, client_id can not contain a colon and be
compatible with HTTP Basic.
I'm not sure that restricting the character repertoire just because one
way to send requires this is the right approach. My preference would be
not to put this into the ABNF, and just to point out that certain
characters will not work over certain transports, and to just advise to
avoid them.
Therefore, I'd like to propose these updated ABNF definitions:
VSCHAR = %20-7E
NOCOLONVSCHAR = %x20-39 / %x3B-7E
UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
client-id = *NOCOLONVSCHAR
client_secret = *VSCHAR
username = *UNICODENOCTRLCHAR
password = *UNICODENOCTRLCHAR
In this case you should add an introductory statement pointing out that
the ABNF defines the grammar in terms of Unicode code points, not octets
(as it is the case most of the time).
It turns out that non-ASCII characters are OK for username and password because
the Core spec only passes them in the form body - not using HTTP Basic - and
UTF-8 encoding is specified.
I'll send a separate mail about that, the current text in the spec is
way too unspecific.
-- Mike
P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character
other than ( %x0-1F / %x7F )>", please send it to me!
As noted before, here's an example:
<http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
Best regards, Julian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
