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?
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).
Julian, what do you think? Working group, what do you think?
Thanks,
-- Mike
-----Original Message-----
From: Julian Reschke [mailto:[email protected]]
Sent: Sunday, June 10, 2012 11:39 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: Discussion needed on username and password ABNF definitions
On 2012-06-08 20:09, Mike Jones wrote:
> Hi Julian,
>
> The current draft restricts username and password to ASCII was because RFC
> 2616 says this about the TEXT fields used by HTTP Basic in RFC 2617:
> "Words of *TEXT MAY contain characters from character sets other than
> ISO-8859-1 [22] only when encoded according to the rules of
> RFC 2047 [14]."
>
> Given that RFC 2047 MIME encodings aren't possible in this context, that you
> wrote that "If you define new protocol elements, either restrict them to
> US-ASCII, or find a way to encode all of Unicode", and you and Peter St.
> Andre wrote that using ISO-8859-1 is a non-starter, that seemed to leave
> ASCII as the only available choice.
The other choice was "find a way to encode all of Unicode". The way to do this
usually is to use UTF-8. That doesn't work with Basic and Digest, but we
shouldn't extend this problem to anything new we define.
> If you have an alternative proposal for encoding all of Unicode for username
> and password, I'd appreciate if you could propose specific text changes to
> -27 to accomplish them. I'd be fine with doing that, but didn't know how to
> satisfy all the constraints above for Unicode characters. Draft -27 is now
> available at http://tools.ietf.org/html/draft-ietf-oauth-v2-27.
> ...
I haven't looked at the core OAuth spec. The right answer depends on where you
use these protocol elements.
Changing this into a question to the WG: is it acceptable to restrict all of
these protocol elements to US-ASCII?
Best regards, Julian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
