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

Mike Dickson <mike.dickson@hp.com> Wed, 30 March 2011 16:18 UTC

Return-Path: <mike.dickson@hp.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 C30253A6A48 for <vwrap@core3.amsl.com>; Wed, 30 Mar 2011 09:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.139
X-Spam-Level:
X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 exQKbe3rYjfg for <vwrap@core3.amsl.com>; Wed, 30 Mar 2011 09:18:58 -0700 (PDT)
Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id CE5363A6A4C for <vwrap@ietf.org>; Wed, 30 Mar 2011 09:18:57 -0700 (PDT)
X-Authority-Analysis: v=1.1 cv=ToWar1fa9ljTHbeJIRNQycBnYxCRNi5M/11QAwRcJ6A= c=1 sm=0 a=SNAFxGGoWQUA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=hZ_-gT8fNLuY8eIOWXcA:9 a=LtoFQAL4v433bhy62VdVkpGYLwcA:4 a=QEXdDO2ut3YA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:117
X-Cloudmark-Score: 0
X-Originating-IP: 174.100.47.252
Received: from [174.100.47.252] ([174.100.47.252:41319] helo=[192.168.0.101]) by cdptpa-oedge04.mail.rr.com (envelope-from <mike.dickson@hp.com>) (ecelerity 2.2.3.46 r()) with ESMTP id 29/E1-29678-458539D4; Wed, 30 Mar 2011 16:20:36 +0000
From: Mike Dickson <mike.dickson@hp.com>
To: Kopilo Hallard <kopilo.hallard@gmail.com>
In-Reply-To: <4D93620C.3000505@gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 30 Mar 2011 12:20:34 -0400
Message-ID: <1301502034.12359.19.camel@mdickson-hplinux>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14)
Content-Transfer-Encoding: 7bit
Cc: "vwrap@ietf.org" <vwrap@ietf.org>
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 16:18:58 -0000

On Wed, 2011-03-30 at 17:02 +0000, Kopilo Hallard wrote:
> On 31-03-2011 1-10, Mike Dickson wrote:
> > On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote:
> >> Mike, if you don't need the flexibility available in a protocol,
> >> simply don't use the flexible features that you don't want.  But
> >> denying those who require a flexible and extensible protocol with a
> >> degree of future-proofing to it is, I believe, not in line with the
> >> goals expressed here from the start of this process.
> > That's not actually consistent with what I thought Carlo wrote.  There's
> > only one set of specs and I didn't see a commitment to backwards
> > compatibility, only that flexibility to evolve features would take
> > precedence over other factors.  And honestly all of this is moot.  I'm
> > not personally going to agree to any overriding principle other than to
> > participate in the process and try and reach consensus in the documents
> > produced. This whole discussion is a proverbial "red herring".  We don't
> > need to agree on how to produce consensus we need to agree on what goes
> > into the documents.
> Huh, Morgaine was writing about interoperability in regards to future 
> flexibility not backwards compatibility...

Yes, and I'm saying I'm not going to agree that flexibility is *the*
most important guiding principle over other factors like compatibility.
That was the original assertion (that we should agree that flexibility
is most important).   I'm going to agree or disagree to things that go
into documents based on their individual merit and not an overriding
principle. I don't see any benefit in trying to get agreement that
flexibility is most important.

Here's a for instance...  I happen to like LLSD not because its elegant
and wonderful but because there are actually viewers I can use that
implement it.  I bet we can sort out a protocol mechanism that could
support other encoding formats between services but I don't want to
throw out LLSD because its not forward thinking or "most flexible".  I'm
guessing we can make the best decision about issues like that when
discussing specific examples of service level interoperability.  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).

Mike