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

Carlo Wood <> Fri, 01 April 2011 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC2DC3A684F for <>; Fri, 1 Apr 2011 07:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L9J8-0GA5GGg for <>; Fri, 1 Apr 2011 07:11:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 369773A6835 for <>; Fri, 1 Apr 2011 07:11:55 -0700 (PDT)
Received: from ([]) by (InterMail vM. 201-2260-120-106-20100312) with ESMTP id <> for <>; Fri, 1 Apr 2011 16:13:34 +0200
Received: from ([]) by with edge id SEDY1g01n0FlQed01EDZSU; Fri, 01 Apr 2011 16:13:34 +0200
Received: from carlo by with local (Exim 4.72) (envelope-from <>) id 1Q5f6S-0005OH-Eg for; Fri, 01 Apr 2011 16:13:32 +0200
Date: Fri, 1 Apr 2011 16:13:32 +0200
From: Carlo Wood <>
Message-ID: <20110401161332.37ca0f9e@hikaru.localdomain>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.20.1; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Cloudmark-Analysis: v=1.1 cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0 a=GIqV-yxGZKkA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=cH6R9-kdAAAA:8 a=BjFOTwK7AAAA:8 a=Uv2ZS0_JHLw8c0ostA4A:9 a=CjuIK1q_8ugA:10 a=bt0zGP92IBIA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Subject: Re: [vwrap] Statements of Consensus. Flexibity First.
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Apr 2011 14:12:02 -0000

On Wed, 30 Mar 2011 14:27:27 +0000
"Dickson, Mike (ISS Software)" <> wrote:

> We don't need to make a process that forces agreement under a set of
> terms.  That's not how the IETF works.  We need consensus and
> documents.

Nobody forces you to anything. I'm asking if there is consensus
about this point. Frankly, I'm disappointed that you disagree
already - at THIS level of abstraction. Perhaps it's caused by
a false sense of fear that you would be forced to accept things
into the protocol: you clearly want control. You want to decide
on a case by case basis if you like it or not.

But hell, that is NOT possible at this abstraction level.
Please rethink carefully what the proposal means: do you REALLY
want to reject the Ideal of an open protocol that doesn't deny
support for use-cases that YOU don't want?

>  As a contributor I'll choose to agree or disagree based
> on the topic.  And in some cases I'm not sure I'd choose flexibility
> over stability, etc.

I don't see the 'etc' here. And IF the minimal support that
an implementer would have to add who does NOT needed X would
lead to instability then surely you wouldn't be able to speak
of "No substantial extra demands are being made"!

If implementation is so difficult, even for implementers NOT
needing it, that it causes the danger of instability then you
have EVER possibility to go against it, even if now you agree
with the Principle of trying to be flexible.
> It seems to me we've sorted drifted to a point we're there are 2
> camps and a proposal was made for how to deal with it.  There are
> those that want to work on service level interop.  And others want to
> define the whole concept of virtual world interop. IMO we need to
> either agree that seperation exists and arrange the docs so it
> describes the 2 work streams or agree that we can't agree and
> disband.  The service level interop. is a subset of the other and
> given our track record I prefer to walk rather than run.

I am not really sure how this applies to making the choice if
you want to be flexible, or - put differently - want to cripple
the protocol to make certain applications of it impossible.

>  And I don't buy the "evil corporate interests" argument.

... unless this is the case. And you just want to win a battle
before it started.

>  Ideally if we do this right there *should* be some participation
> from business interests that are looking at the space.

A flexible protocol would be superset of what those businesses
need (see point 1: Protocol B can do everything that A could do).
So, if they would be interested when the protocol can only do A,
please explain why they won't be interested anymore when it
can do B?

> Mike (speaking as me and not for HP)

Carlo Wood <>