[OAUTH-WG] HTTP responses

Werner Strydom <werners@bloudraak.com> Tue, 27 March 2012 06:41 UTC

Return-Path: <werners@bloudraak.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 4DE0F21F8771 for <oauth@ietfa.amsl.com>; Mon, 26 Mar 2012 23:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 i4AP4iNZDhyY for <oauth@ietfa.amsl.com>; Mon, 26 Mar 2012 23:41:47 -0700 (PDT)
Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4569C21F8772 for <oauth@ietf.org>; Mon, 26 Mar 2012 23:41:46 -0700 (PDT)
Received: from bloudraak.com ([66.209.67.179]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKT3FhKhP3l5QIgUJcWvyXMHyHxDPDLACZ@postini.com; Mon, 26 Mar 2012 23:41:47 PDT
Received: from [172.16.1.102] (c-98-207-173-190.hsd1.ca.comcast.net [98.207.173.190]) by bloudraak.com (Postfix) with ESMTPSA id 324E0251498; Mon, 26 Mar 2012 23:41:46 -0700 (PDT)
From: Werner Strydom <werners@bloudraak.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Mar 2012 23:41:38 -0700
To: oauth@ietf.org
Message-Id: <D283E4FA-2F01-4E3A-9B2A-64AC89DAF7B8@bloudraak.com>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [OAUTH-WG] HTTP responses
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, 27 Mar 2012 06:41:48 -0000

Sections 4.1.4, 4.3.3, 5.1 and 5.2 requires that entity bodies in HTTP responses be in "application/json".  Is my understanding correct? If so, this is awkward for services that rely solely on XML formats for communication. 

Can the standard explicitly accommodate implementors that want to return other (agreed upon) formats based on the HTTP Accept header? For example, is a consumer requests a token from an Authorization Server with an accept Accept header of "text/xml" then the response will be formatted as XML. The schema describing that document can be standardized, if needed. If it is "application/json" the response will be formatted accordingly. In the case of unsupported formats, the authorization server should return HTTP status code 406 to be consistent with the way HTTP works.

Thanks,
Werner