Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
From: "Manger, James H" <[email-masked]>
To: Julian Reschke <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 8 Oct 2011 01:15:53 +1100
List-Id: OAUTH WG <oauth.ietf.org>

> Option 3 has a serious flaw in that it requires escaping the "\" in 
> "\uNNNN", because it is the escape character in quoted-string. I think 
> it's certain that people will be confused by that, and interop problems 
> will happen (unless you have a strong test suite).

No, the "\" in "\uNNNN" would not be escaped.
The intention with adopting json-string would be to *replace* quoted-string.

I suggested this was ok as json-string is backward compatible
with quoted-string. That is not strictly true.
While json-string decodes "\u00E8" to a single char "è",
quoted-string decodes it to the 5 chars "u00E8".

This clash, however, may only be theoretical.
It is totally pointless to escape "u" as "\u" in a
quoted-string. I can confidently say it will never
have been done legitimately. If it does occurs in the wild,
99% of cases will be because the sender forgot to escape
the slash; and 99% of the remaining 1% will be because
a malicious sender is trying to bypass a security check by
escaping a char that the software never anticipated would
be escaped.

Quoted-string allows 93 ASCII chars to be used as themselves,
and defines an escaping mechanism to add 2 more chars:
double-quote and backslash (the escape char itself).
An escape mechanism to support the last ASCII visible char
might have been useful in an ASCII world, but it is pointless
today if it doesn't allow the other 100,000 Unicode chars.

If we specify json-string for a field specified elsewhere as
quoted-string I suspect we will get lucky and solve our Unicode
issue without causing any actual problems. That is partly
because I don't think most/many OAuth HTTP clients use
frameworks that automatically decode quoted-string values
in their bowels. Do others who write HTTP clients have
experience to the contrary?

I prefer option 3 (of the 3), perhaps with a note in the
spec saying: "Specifying json-string is a wilful violation
of RFC 2617 that uses quoted-string. It is done to
add support for Unicode values while supporting all valid
quoted-string values that occur in practise."

--
James Manger