Re: [vwrap] Statements of Consensus. Flexibity First.

Dzonatas Sol <dzonatas@gmail.com> Wed, 30 March 2011 17:09 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5CE3A6B9F for <vwrap@core3.amsl.com>; Wed, 30 Mar 2011 10:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.488
X-Spam-Level:
X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 KRoAOxjuck14 for <vwrap@core3.amsl.com>; Wed, 30 Mar 2011 10:09:31 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3547C3A6BA5 for <vwrap@ietf.org>; Wed, 30 Mar 2011 10:09:31 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1675893iwn.31 for <vwrap@ietf.org>; Wed, 30 Mar 2011 10:11:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KABvBYVWrMG7MLmGo9ILzJQcSr0JmtCnHG8sQvfLfeE=; b=VMqH97IoB74GuwJPlUbdytjZbV1ZEt/Pl68d5iTLhQkTrQE1jUhVBnJta5x+DEzw/i qgneaxVMRqZ7TJhKvSOWAGHQtXrfGqizKE5wpVIR7vzuNxqGH3GjPt5XjlfR3oBIV1Xn 5Ac3lMtejwvPl4xUR110f93fmzcJv41uCRFHE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dsGRHjf104c7JAKovXYakE8SwqURI02d64hedcmBMFObtyUV2rKJCL/91Ync+h6Uvo gH2RNTT3qL6/KfjddzHNGntO/45S6p8Ba+A/jTgaCzL2huVWAYyviGxcRuLGAxTich1v ISNityU6niim467JaBRMpksKnfN3l+m0z1mzg=
Received: by 10.231.193.233 with SMTP id dv41mr1512700ibb.186.1301505069798; Wed, 30 Mar 2011 10:11:09 -0700 (PDT)
Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gy41sm146146ibb.56.2011.03.30.10.11.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 10:11:08 -0700 (PDT)
Message-ID: <4D936430.4090401@gmail.com>
Date: Wed, 30 Mar 2011 10:11:12 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)
MIME-Version: 1.0
To: "vwrap@ietf.org" <vwrap@ietf.org>
References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <AANLkTimaA3qcKOUUjQzvq86R1UMvamTc4yJh4NBMp_Gq@mail.gmail.com> <1301499645.12359.10.camel@mdickson-hplinux> <4D93620C.3000505@gmail.com> <1301502034.12359.19.camel@mdickson-hplinux>
In-Reply-To: <1301502034.12359.19.camel@mdickson-hplinux>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [vwrap] Statements of Consensus. Flexibity First.
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 17:09:33 -0000

Mike Dickson wrote:
> [...] So
> agreeing in advance that we should focus on "flexibility" doesn't help.
> It simply derails the important discussion about what we're talking
> about; wether service level interoperability is what we need to be
> focused on or something more (or both as 2 work streams).

This pretty much concludes we need solid definition of "service level 
interoperability" due to the fact that it is being used flexibly at the 
moment to whatever best interest of said-defined parties. I know 
everyone hates to hear it that way, yet let's not future push away by 
such newer terminology.

Documents exist that define partitions to region/agent protocols, so why 
can't we start there? Are they too drafty?

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant