Re: [OAUTH-WG] Possible alternative resolution to issue 26
Mike Jones <Michael.Jones@microsoft.com> Fri, 30 September 2011 15:17 UTC
Return-Path: <Michael.Jones@microsoft.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 515E421F8AC9 for <oauth@ietfa.amsl.com>; Fri, 30 Sep 2011 08:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.506
X-Spam-Level:
X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 XmDQOrlJwyci for <oauth@ietfa.amsl.com>; Fri, 30 Sep 2011 08:17:13 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 6826121F8A55 for <oauth@ietf.org>; Fri, 30 Sep 2011 08:17:13 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 30 Sep 2011 08:20:07 -0700
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Fri, 30 Sep 2011 08:20:07 -0700
From: Mike Jones <Michael.Jones@microsoft.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Possible alternative resolution to issue 26
Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gAq0NMw
Date: Fri, 30 Sep 2011 15:20:06 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739435C21FB70@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C21FB70TK5EX14MBXC284r_"
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, 30 Sep 2011 15:17:15 -0000
Thus far, I've received no responses preferring 1 or 2 or preferring A or B. Could people please weigh in so that the working group has data to base a decision on to close this issue? Thanks, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Thursday, September 29, 2011 11:53 AM To: oauth@ietf.org Subject: [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII characters in scope strings than had previously been in evidence. If we decide to define a standard representation for doing so, using RFC 5987<http://tools.ietf.org/html/rfc5987> (Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the clear choice. I'd be interested in knowing how many working group members are in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying UTF-8 encoding of the error_description value, requesting the use of RFC 5987 encoding instead. I'd also be interested in knowing how many working group members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description parameter. (As editor, I would make the observation that if we choose RFC 5987 encoding for either of these parameters, it would be logical to do so for the other one as well.) In the interest of finishing the specification in a way that meets everyone's needs, -- Mike
- [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