[ogpx] content negotiation for LLSD messages with HTTP transport binding

Meadhbh Hamrick <ohmeadhbh@gmail.com> Mon, 29 March 2010 16:30 UTC

Return-Path: <ohmeadhbh@gmail.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF3A3A6992 for <ogpx@core3.amsl.com>; Mon, 29 Mar 2010 09:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.118
X-Spam-Level: *
X-Spam-Status: No, score=1.118 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 2mzy+MORmSbI for <ogpx@core3.amsl.com>; Mon, 29 Mar 2010 09:30:00 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 027493A6AB3 for <ogpx@ietf.org>; Mon, 29 Mar 2010 09:29:58 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 9so304774qwb.31 for <ogpx@ietf.org>; Mon, 29 Mar 2010 09:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=DLwEey8toaeU9eTYERXrN50yz97XG2J3u0jnwOiRUcg=; b=q/FfX+Az4D+O88wf8cUjabu+y4jGlwYsG2vw6jhWnpaiCJ7q1gldqjKMtB9eGyS1XT exCTwbXG/YUn9kDfSqAqFC3tFW2EoMqbKl4TakVVt07sOHJl31p63PfkeZGAQdqnvWYg bXiGC/mkQx1+T9eF20S8n/r5t6HeNSOBu27KU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=utQ/ZCVzsvpqb2mJuis0A681JspY2iKBL/OplWsTMjEIFb4x8WtKkrUptK3kJ8us7j nmmYjC+jTis2yy21T8AFMXg3/Ct3pEJWvzpkL8Zhg0p6iaCanrFn6fipMgqdN7Cukq1W fDWFIN7zduMggxgQyxUN11bBQdqv8otTXrecc=
MIME-Version: 1.0
Received: by 10.229.20.209 with HTTP; Mon, 29 Mar 2010 09:30:03 -0700 (PDT)
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Mon, 29 Mar 2010 09:30:03 -0700
Received: by 10.229.213.140 with SMTP id gw12mr2451010qcb.96.1269880223455; Mon, 29 Mar 2010 09:30:23 -0700 (PDT)
Message-ID: <b325928b1003290930n4d710d7cp6926bf5d0ddb47d5@mail.gmail.com>
To: ogpx <ogpx@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [ogpx] content negotiation for LLSD messages with HTTP transport binding
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2010 16:30:02 -0000

so that last message reminds me.

last year there was a little bit of consternation about content
negotiation for LLSD. it was hypothesized that there might be a
service or client that did not produce (or consume) all of the defined
serializations (XML, JSON, Binary). so two questions were asked:

a. how does a client signal it's serialization preference?
b. how does a server signal that it can't conform to the client's
serialization preference?

fortunately, we have some guidance from the HTTP specs.

1. a client uses the Content-Type: header to specify which
serialization it is using.
2. a client uses the Accept: header to specify which serializations it
can receive in response.
  2.1. note that clients can list multiple serializations with an Accept: header
  2.2. if an Accept: header is not present in the request, the default
of */* is assumed.
3. if the server is not capable of generating a response using the
serialization specified in the request's Accept: header,
  3.1. the sever responds with a 406 Not Acceptable response.
4. if the server IS capable of generating a response using the
serialization specified in the request's Accept: header,
  4.1. the response is generated and the Content-Type: header is used
to specify the serialization used.

i think that pixel and i agreed this is what we were going to do
moving forward. (pix? do you remember if we used 406 or 415?)

so anyway, this is what i'm going to code up.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com