Re: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4)

Roger Crew <crew@cs.stanford.edu> Tue, 07 February 2012 20:50 UTC

Return-Path: <crew@cs.stanford.edu>
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 9DD7B11E8088 for <oauth@ietfa.amsl.com>; Tue, 7 Feb 2012 12:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 p+eYm89zedew for <oauth@ietfa.amsl.com>; Tue, 7 Feb 2012 12:50:44 -0800 (PST)
Received: from mail.fyigm.com (mail.fyigm.com [69.17.114.80]) by ietfa.amsl.com (Postfix) with ESMTP id 96E0E21F86F8 for <oauth@ietf.org>; Tue, 7 Feb 2012 12:50:42 -0800 (PST)
Received: from rfc by mail.fyigm.com with local (Exim 4.72) (envelope-from <crew@cs.stanford.edu>) id 1Rus23-0000N8-Tz; Tue, 07 Feb 2012 12:52:56 -0800
From: Roger Crew <crew@cs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20273.36647.811224.493136@hagen.valhalla>
Date: Tue, 07 Feb 2012 12:52:55 -0800
To: Eran Hammer <eran@hueniverse.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB964C0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <20160.24172.942808.563672@hagen.valhalla> <90C41DD21FB7C64BB94121FBBC2E723453AAB964C0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-Mailer: VM 8.1.0 under 23.2.1 (x86_64-pc-linux-gnu)
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] error codes in 4.1.2.1 and 4.2.2.1 and extension response types (8.4)
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: Tue, 07 Feb 2012 20:50:44 -0000

 > > (2) [in 4.2.2.1]  If the response_type is provided but unknown,
 > >     is that an 'invalid_request' (since this is clearly an
 > >     "unsupported parameter value") or is it an
 > >     'unsupported_response_type'?
 > > 
 > >     Seems to me it should be the latter.  If so, then...
 > >     ...
 > >     should the description for 'invalid_request' even be referring to
 > >     "unsupported" values at all?
 > >     ...
 > >     Section 5.2 has the same problem w.r.t. 'unsupported_grant_type'
 > 
 > Changed the definition of invalid_request to:
 > 
 >   The request is missing a required parameter, includes an invalid
 >   parameter value, or is otherwise malformed.

Just noticed in draft 23 that you changed 4.2.2.1 but didn't change 5.2,
which still refers to "unsupported" parameter values and thus similarly 
conflicts with the definition of 'unsupported_grant_type'.


-- 
Roger Crew
crew@cs.stanford.edu