Subject: [OAUTH-WG] Proposed OAuth Core -28

From: Mike Jones <[email-masked]>
Date: Tue, 19 Jun 2012 00:03:37 +0000

In cooperation with the chairs and Eran, I've produced the attached proposed OAuth Core -28 version.  It updates the ABNF in the manner discussed by the working group, allowing username and password to be Unicode and restricting client_id and client_secret to ASCII.  It specifies the use of the application/x-www-form-urlencoded content-type encoding method to encode the client_id when used as the password for HTTP Basic.  A few minor grammar errors encountered were also corrected.  Normative changes are in sections 2.3.1, A.1, A.2, A.15, and A.16.  Unless I hear objections, I'll use the publication tool to post this as -28 at close of business tomorrow, with Eran being the one to give approval in the tool for publication.

                                                                Cheers,
                                                                -- Mike

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jun 2012 08:17:40 +0200

On 2012-06-19 02:03, Mike Jones wrote:
> In cooperation with the chairs and Eran, I’ve produced the attached
> proposed OAuth Core -28 version.  It updates the ABNF in the manner
> discussed by the working group, allowing username and password to be
> Unicode and restricting client_id and client_secret to ASCII.  It
> specifies the use of the application/x-www-form-urlencoded content-type
> encoding method to encode the client_id when used as the password for
> HTTP Basic.  A few minor grammar errors encountered were also
> corrected.  Normative changes are in sections 2.3.1, A.1, A.2, A.15, and
> A.16.  Unless I hear objections, I’ll use the publication tool to post
> this as -28 at close of business tomorrow, with Eran being the one to
> give approval in the tool for publication.

I note that the ABNF is still unchanged with respect to the confusion 
about octets vs characters.

You can't silently mix both. If the ABNF defines character sequences, 
you should say that upfront, and then need to specify how to map to 
octet sequences on the wire.

If it's a mix, you need to mark the special cases.

Again, an example for a spec doing this here: 
<http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>

Best regards, Julian