Re: [OAUTH-WG] OAuth ABNF

Eran Hammer <eran@hueniverse.com> Tue, 24 April 2012 00:12 UTC

Return-Path: <eran@hueniverse.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 556D221F86F2 for <oauth@ietfa.amsl.com>; Mon, 23 Apr 2012 17:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level:
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 gGaEDumIyuoL for <oauth@ietfa.amsl.com>; Mon, 23 Apr 2012 17:12:22 -0700 (PDT)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id A0D2C21F86F0 for <oauth@ietf.org>; Mon, 23 Apr 2012 17:12:22 -0700 (PDT)
Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 1cCM1j0070CJzpC01cCMTz; Mon, 23 Apr 2012 17:12:21 -0700
Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.115]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 17:12:21 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Chuck Canning <Chuck.Canning@deem.com>, "oauth@ietf.org WG (oauth@ietf.org)" <oauth@ietf.org>
Thread-Topic: OAuth ABNF
Thread-Index: Ac0hlo/WWuxsG+HsR9eTWVbGALjxfAACUw7AAAO9RrA=
Date: Tue, 24 Apr 2012 00:12:20 +0000
Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFB712@P3PWEX2MB008.ex2.secureserver.net>
References: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFB23D@P3PWEX2MB008.ex2.secureserver.net> <09F445A2195DAF4FA60A3FC08DF8A67C3A09B3C5@sccorpmail03.mygazoo.com>
In-Reply-To: <09F445A2195DAF4FA60A3FC08DF8A67C3A09B3C5@sccorpmail03.mygazoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.74.213.174]
Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA2FFB712P3PWEX2MB008ex2se_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth ABNF
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, 24 Apr 2012 00:12:24 -0000

We can do both (provide it as defined and in one section). But someone needs to prepare all the ABNFs first.

EH

From: Chuck Canning [mailto:Chuck.Canning@deem.com]
Sent: Monday, April 23, 2012 3:28 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: OAuth ABNF

As someone trying to implement the spec, I find that I have to jump around the spec to find this information also. Personally, I think grouping the related options in the document might make it more clear instead of grouping it based on a concept and then the next style of flow. It might also help shine light on the holes in the spec or where things are ambiguous or not clearly defined. (ie. clearly defining all the options for a particular URI together instead of having to jump over multiple sections and mentally comparing each option).

From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org]<mailto:[mailto:oauth-bounces@ietf.org]> On Behalf Of Eran Hammer
Sent: Monday, April 23, 2012 2:20 PM
To: oauth@ietf.org<mailto:oauth@ietf.org> WG (oauth@ietf.org<mailto:oauth@ietf.org>)
Subject: [SPAM] [OAUTH-WG] OAuth ABNF
Importance: Low


During the IESG review of draft-ietf-oauth-v2, Sean Turner raised the following DISCUSS item (meaning, the specification is blocked until this is resolved):



> 0) General: I found the lack of ABNF somewhat disconcerting in that

> implementers would have to hunt through the spec to figure out all the

> values of a given field.  For example grant_type has different values based

> on the different kind of access_token requests - four to be more precise -

> but there's no ABNF for the field.  There are many examples of

> this.   It would greatly aid implementers if a) the ABNF for all fields

> were included in the draft and b) all the ABNF was collected in one place.  I

> had individual discusses for each field that had missing ABNF, but it was

> getting out of hand so I'm just going to do this one general discuss on this

> topic.

I don't have the time to prepare such text. Can someone volunteer to submit this text to the WG for review?

EH