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

Morgaine <> Fri, 01 April 2011 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79AFE3A687F for <>; Fri, 1 Apr 2011 07:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.873
X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RGdlyYCSEPow for <>; Fri, 1 Apr 2011 07:59:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB6B43A6875 for <>; Fri, 1 Apr 2011 07:59:32 -0700 (PDT)
Received: by qwg5 with SMTP id 5so2582024qwg.31 for <>; Fri, 01 Apr 2011 08:01:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v3L8yEyRN80Tglc6dMSBcfS/mJS9eUsgTIolcCzenbU=; b=LsIfgCv1lxS7UDavGVStslFUaCau0lk6vwUqiUcSe2etXA/8a2U31rlcUIF40frpSs KdQsbqo0JREDgwl7Y1UwG2R5nyp/VAx931eg2ciKFv4F2uoEgkkOfTrW2Eged8wje1/4 UOeQJUJxCkIp36IlZ+FiMpe30Cn9wDob9/E/M=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nqZi/9U61hLeU66nn84hgAVY7NN/NVL1QP1Suly3W2h/0fZxv1IIot3RRXSaKp1ICS fLnhntsj3XeHgaDI6ptDEPO5CqHN7acxQUPpEt+Ac3UHnLS0wmTQ7gur+IZC9A2nSbAA gigY0VrG/KvDQF6l7PMWwo20sFug+F6y+5uQg=
MIME-Version: 1.0
Received: by with SMTP id ez10mr3550562qab.372.1301670072661; Fri, 01 Apr 2011 08:01:12 -0700 (PDT)
Received: by with HTTP; Fri, 1 Apr 2011 08:01:12 -0700 (PDT)
In-Reply-To: <20110401161332.37ca0f9e@hikaru.localdomain>
References: <> <> <> <20110401161332.37ca0f9e@hikaru.localdomain>
Date: Fri, 1 Apr 2011 16:01:12 +0100
Message-ID: <>
From: Morgaine <>
Content-Type: multipart/alternative; boundary=20cf300faf754bb718049fdcae0d
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:59:37 -0000

I agree 100% with every point made by Carlo in this post.

Please note that I have extended Carlo's 2-clause proposal from his earlier
email, because in his original formulation, flexibility in the protocol is
easily vetoed by backward-looking detractors or vested interests.

My formulation is here -- .  I am
sure it can be improved still further.

My goal is that (i) new areas of flexibility should be justified by use
cases and supported by engineering solutions, and (ii) not subject to veto
by those who are not interested in those use cases.  That's how you make
technical progress.



On Fri, Apr 1, 2011 at 3:13 PM, Carlo Wood <> wrote:

> 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 <>
> _______________________________________________
> vwrap mailing list