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.
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.
The working group should also discuss whether client_id and client_secret
should use the same character set restrictions as username and password or
whether they should be different for some reason. In the case of one
character, they need to be different: The client_id field already allows colon
(":") for reasons identified by Nat Sakimura, among others, whereas username
can't because of HTTP Basic restrictions.
Best wishes,
-- Mike
-----Original Message-----
From: Julian Reschke [mailto:[email protected]]
Sent: Friday, June 08, 2012 2:52 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [OAUTH-WG] Draft OAuth Core spec changes updating proposed ABNF
On 2012-06-08 09:56, Mike Jones wrote:
> The attached proposed edits to the Core spec update the ABNF to remove
> the character set restrictions that working group participants had
> objected to, and to define common syntax elements, where appropriate.
> After working group review, I believe that these changes are ready to
> be checked in for draft 27 after being merged with whatever other
> changes Eran has made.
> ...
As far as I can tell, you have chosen to restrict everything to US-ASCII. That
definitively makes the ABNF and the wire representation simpler, but it does
break I18N big time.
And please don't tell me that people do not use non-ASCII characters in
credentials (-> <https://bugzilla.mozilla.org/show_bug.cgi?id=41489>).
Focusing on username and password... If this relates to the use in Basic and
Digest, it's fine that it has their current limitations; but in that case the
ABNF shouldn't invent new productions and claim that they match 2617's when
they do not.
If this relates to uses of usernames and passwords outside Basic and Digest
(thus new uses), then I believe the proposed solution is not acceptable.
Best regards, Julian
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
