Re: [OAUTH-WG] Possible alternative resolution to issue 26
"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 07 October 2011 14:12 UTC
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1D521F84CD for <oauth@ietfa.amsl.com>; Fri, 7 Oct 2011 07:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.113
X-Spam-Level:
X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-bZYuTyOPrW for <oauth@ietfa.amsl.com>; Fri, 7 Oct 2011 07:12:47 -0700 (PDT)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC1C21F8509 for <oauth@ietf.org>; Fri, 7 Oct 2011 07:12:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.68,502,1312120800"; d="scan'208";a="47955907"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 08 Oct 2011 01:15:55 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6491"; a="39461175"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 08 Oct 2011 01:15:55 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sat, 8 Oct 2011 01:15:55 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Julian Reschke <julian.reschke@gmx.de>, "oauth@ietf.org" <oauth@ietf.org>
Date: Sat, 08 Oct 2011 01:15:53 +1100
Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26
Thread-Index: AcyE1BA3fTFiTxlMRDayootCIcJijQAHqpnw
Message-ID: <255B9BB34FB7D647A506DC292726F6E112904F03C7@WSMSG3153V.srv.dir.telstra.com>
References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C22CA77@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E8EC720.8030909@gmx.de>
In-Reply-To: <4E8EC720.8030909@gmx.de>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2011 14:12:47 -0000
> 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
- [OAUTH-WG] Possible alternative resolution to iss… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Buhake Sindi
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Eran Hammer-Lahav
- Re: [OAUTH-WG] Possible alternative resolution to… Manger, James H
- Re: [OAUTH-WG] Possible alternative resolution to… Eran Hammer-Lahav
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Dick Hardt
- Re: [OAUTH-WG] Possible alternative resolution to… Dick Hardt
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Michael Thomas
- Re: [OAUTH-WG] Possible alternative resolution to… Phil Hunt
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Phil Hunt
- Re: [OAUTH-WG] Possible alternative resolution to… Marius Scurtescu
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Marius Scurtescu
- Re: [OAUTH-WG] Possible alternative resolution to… John Kemp
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Marius Scurtescu
- Re: [OAUTH-WG] Possible alternative resolution to… Thomson, Martin
- Re: [OAUTH-WG] Possible alternative resolution to… Barry Leiba
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Eran Hammer-Lahav
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Manger, James H
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Manger, James H
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke