On 2012-06-10 20:50, Mike Jones wrote:
Thanks for your reply, Julian.
Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", and they're
required to be used with Basic, I believe that that confirms that username and password must either
be ASCII or ISO-8859-1, and given that several people have written that ISO-8859-1 is a
"non-starter", that effectively confirms the current syntax in -27 that username and
password must be ASCII. Do you agree or am I missing a nuance here?
I don't understand OAuth enough to know whether a constraint of Basic
and Digest should affect OAuth in general.
Also, we actually might be able to *fix* these schemes, in which case it
would be unfortunate if OAuth adopted the constraint in a way that makes
it hard to update.
I believe the right thing to do is not to have a special ABNF; but
instead to just note that when these protocol elements need to be used
with Basic or Digest, the respective constraints of these schemes apply.
Julian, there was one aspect of the open issue that you didn't reply to: Do you have an
opinion on whether client_id and client_secret should be restricted to the same
characters as username and password? This seems logical to me, as they are objects of
the same kind as username and password, but I also sympathize with your sentiment that
"we shouldn't extend this problem to anything new we define". On the other
hand, given that client_id and client_secret are for machine (and not for human)
consumption, I don't see any more need for internationalization of these fields than
there was for scope (which the working group decided to limit to ASCII).
I'll leave that to the WG :-)
Best regards, Julian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
