Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON

Robert Sayre <sayrer@gmail.com> Sat, 01 May 2010 22:24 UTC

Return-Path: <sayrer@gmail.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 1E1E33A6920 for <oauth@core3.amsl.com>; Sat, 1 May 2010 15:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level:
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_20=-0.74, GB_I_LETTER=-2]
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 yUQ5adbwUMMi for <oauth@core3.amsl.com>; Sat, 1 May 2010 15:24:33 -0700 (PDT)
Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id DA06D3A682F for <oauth@ietf.org>; Sat, 1 May 2010 15:24:32 -0700 (PDT)
Received: by qyk11 with SMTP id 11so1733689qyk.13 for <oauth@ietf.org>; Sat, 01 May 2010 15:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=f5IyLitPcZd++NhjKYvmMaMZu88Q/v7IxPBQFrNjTZE=; b=DaCRPcyWTUuURuqqlCUlVvkkDIUGhR0ThgJiDpWLNEXh9y1Qwcsm2QQbDZYdkYSPbt uhI53q921yGNWNGxXuZum0LI/Kf5pCfOeDhXD2HuB4qEkYU7hLdC4fwJQgH2nVgsE6o0 04EdJQlcGOGIJiyHK//pdFxk5WzjgBMhmRsmY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v/D8x1fFjr4Zij7RQKFciIDQw4NvQtN+c+UPefAz2fRDwsR6xq6sdYMhiCJYUD1JK6 w0wn6dy5pQppwA6XPdQmK35UhcLTfc5aqpuBaRMWuRlz1SOePllYBwZ+GF7kNs1AtGti mVZbNXKLuELWRyfr4knv0HnfQ2UW9Va4nbBd8=
MIME-Version: 1.0
Received: by 10.229.96.80 with SMTP id g16mr1016264qcn.85.1272752655803; Sat, 01 May 2010 15:24:15 -0700 (PDT)
Received: by 10.229.99.142 with HTTP; Sat, 1 May 2010 15:24:15 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723439323D0533@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <9890332F-E759-4E63-96FE-DB3071194D84@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A379B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20100419134825.134951nuzvi35hk4@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <t2wc334d54e1004200924ja0e7786u9b349a1931098f2a@mail.gmail.com> <50802E3D-2578-409C-92BC-B5C47EBE6C21@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723439323D0533@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Sat, 01 May 2010 18:24:15 -0400
Message-ID: <h2g68fba5c51005011524s1f5ee50ftec570e346f83e698@mail.gmail.com>
From: Robert Sayre <sayrer@gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
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: Sat, 01 May 2010 22:24:34 -0000

On Fri, Apr 30, 2010 at 10:33 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> If we end up with JSON as the only *core* format, we can still extend the
> protocol in another spec to add a format request parameter with other
> serializations.

I think that's the right way to look at it.

The fact that JSON is always Unicode and the character encoding is
easily determined by examining the first few bytes should be enough to
make the group jump for it.[1] You can skip all the inaccurate
metadata in the HTTP headers for both requests and responses. And even
kind of hobbled embedded implementations can do ASCII only and we'll
pretend it's UTF-8. :)

But maybe none of this is a problem for existing implementations? The
spec seems strangely silent on internationalization.

- Rob

[1] noooooo: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#url-encoded-form-data

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."