Re: [ogpx] Notes from my parts of the VWRAP session

Dzonatas Sol <dzonatas@gmail.com> Wed, 24 March 2010 18:13 UTC

Return-Path: <dzonatas@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 699C73A6D87 for <ogpx@core3.amsl.com>; Wed, 24 Mar 2010 11:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[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 5nihUs5SZ3wn for <ogpx@core3.amsl.com>; Wed, 24 Mar 2010 11:13:47 -0700 (PDT)
Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 820A73A6D85 for <ogpx@ietf.org>; Wed, 24 Mar 2010 11:13:46 -0700 (PDT)
Received: by bwz3 with SMTP id 3so6693029bwz.29 for <ogpx@ietf.org>; Wed, 24 Mar 2010 11:14:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=o/ZH5ndEp/LdJhM+rOMLEWEoE4Zc0Uhv/SVvbFrQo6I=; b=xj9ZtYSzPhrU/enNB0zc1mi717B8rWe+stbYzVLEFonRivRpMQPdpIsMI6sYtrAIl/ l0xmAXgMoTOhj/tyQVZoVxHB0U+bIDqx5H3B6sJc30ZrL5lMLl45Ipv1UMqez3KF6qF7 FiNHAMN4/LNqLdA30q8Lu32Zgj1K//PcUBWq8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=JbaLy4ffvRH194aHtW6K0tGktHtW6LJmGmgvbIuXFCKQVrJIh6Ei50NAL6k8St/38K /eOUXDyVpyltq5BeLjOUYeyUX/pahYaeK6+Oj99ZGSjf9vtj01OwtC2PtvTeK8eHLvhc m6aG8QgqyUvP9FXSFybMtVmILf5EBUZcH3GQM=
Received: by 10.204.34.206 with SMTP id m14mr230413bkd.14.1269454442912; Wed, 24 Mar 2010 11:14:02 -0700 (PDT)
Received: from [192.168.0.50] (adsl-69-105-203-42.dsl.scrm01.pacbell.net [69.105.203.42]) by mx.google.com with ESMTPS id 14sm218000bwz.6.2010.03.24.11.13.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Mar 2010 11:14:01 -0700 (PDT)
Message-ID: <4BAA59BB.90300@gmail.com>
Date: Wed, 24 Mar 2010 11:28:11 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
MIME-Version: 1.0
To: Mark Lentczner <markl@lindenlab.com>, ogpx@ietf.org
References: <180093C2-AC6E-435B-8AD5-A58B81CCD9FB@lindenlab.com>
In-Reply-To: <180093C2-AC6E-435B-8AD5-A58B81CCD9FB@lindenlab.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [ogpx] Notes from my parts of the VWRAP session
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: Wed, 24 Mar 2010 18:13:49 -0000

Mark Lentczner wrote:
> **9) No one had concerns or issues with the addition of query 
> arguments to LLIDL. However, within Linden's internal LLIDL user 
> community there has been requests for also adding path arguments. 
> While the VWRAP design currently doesn't use either of these 
> facilities, experience has shown that backends would like to make use 
> of both. Implementors prefer to use one type and validation system 
> consistently throughout if possible, and so it seems reasonable to add 
> them here. I'm looking for experience and input on these issues before 
> proceeding with further design.

Just to clarify from IETF session chat to make sure we are on the same page:

This is an acceptable standard query: /Resource/Path/<uuid>

This is not standard, but an acceptable customization: 
/Resource/Path/<uuid>?encode=text&format=json

We shouldn't expect the customization to be supported across the board 
on all implementations. Instead, from feedback and various reads, we 
should make use of the Content-Type: field where possible instead of 
path arguments.

For example: Content-Type: text/json

Or: Content-Type: application/xml+llsd

Other operation arguments are probably best found in the body of the 
query rather than the header.

Please clarify further is this what was not intended.