Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 26 January 2011 17:47 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6B93A68D7 for <oauth@core3.amsl.com>; Wed, 26 Jan 2011 09:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level:
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Kt7xJh43Xmq for <oauth@core3.amsl.com>; Wed, 26 Jan 2011 09:47:46 -0800 (PST)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D02D63A686A for <oauth@ietf.org>; Wed, 26 Jan 2011 09:47:45 -0800 (PST)
Received: (qmail 16341 invoked from network); 26 Jan 2011 17:49:20 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 17:49:20 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 26 Jan 2011 10:49:15 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Wed, 26 Jan 2011 10:48:56 -0700
Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
Thread-Index: Acu9fw2TAoi7PCNRQJGvOTGSqyQnmgAAB9hw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6262E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimzOErQhT_gjdQrcawVgfsnr_2RVtTOYRoP-fcR@mail.gmail.com> <1296051184.9984.5.camel@pulse> <FFDFD7371D517847AD71FBB08F9A31563848E7CD74@SP2-EX07VS06.ds.corp.yahoo.com> <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org>
In-Reply-To: <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 26 Jan 2011 17:47:46 -0000

This is not aimed at anyone in particular.

Replying +1 is not justification for a major breaking change. This was raised in the past and consensus was that this is not a major concern. Over the past 10 months not a single actual issue was raised about conflicts in legacy platforms. If you have an *actual* issue with a platform, please provide the full details, including why known mechanisms such as Apache rewrite rules can't solve the it.

We're must be done discussing hypotheticals and theorizing about how this protocol will get adopted by those not represented here. That was fine a year ago, but at this point, whoever is in this group gets to make the decision based on our collective deployment experience. I honestly can't be bothered to care about deployment issues in some undeclared legacy platforms no one here is struggling with.

I've been doing this work continuously for over three and a half years and have learned that trying to optimize for the 'adoptions by others not present' is a complete waste of time. Suggesting that adoption will be significantly affected because of lack of parameter prefix or the inclusion of half-baked client assertion mechanism is just silly.
 
EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Skylar Woodward
> Sent: Wednesday, January 26, 2011 9:33 AM
> To: William Mills
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> +1
> 
> More feedback on the token specs (and v12) is in my queue for tonight, but
> this has also been a concern of mine and this seems to be a more elegant
> protection against conflicts than adding a "version" parameter.
> 
> On Jan 26, 2011, at 6:14 PM, William Mills wrote:
> 
> >>> Broken record: using a prefix for all registered parameters is much
> >>> cleaner (as opposed to requiring that all no-registered parameters
> >>> use a prefix).
> >>
> >> And once again, a strong +1 to this, even though I know it's far too
> >> late to make such a breaking change to the spec. I really think this
> >> was a bad decision and is going to come back and bite us in the
> >> future.
> >>
> >> -- Justin
> >
> > Yep.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth