[vwrap] Statements of Consensus. Flexibity First.

Carlo Wood <carlo@alinoe.com> Wed, 30 March 2011 01:13 UTC

Return-Path: <carlo@alinoe.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 08F9F28C0EF for <vwrap@core3.amsl.com>; Tue, 29 Mar 2011 18:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 zWx9uSRCAaRZ for <vwrap@core3.amsl.com>; Tue, 29 Mar 2011 18:13:24 -0700 (PDT)
Received: from fep17.mx.upcmail.net (fep17.mx.upcmail.net [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 6FAAA28C0D7 for <vwrap@ietf.org>; Tue, 29 Mar 2011 18:13:23 -0700 (PDT)
Received: from edge05.upcmail.net ([192.168.13.212]) by viefep17-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110330011500.PUIN11401.viefep17-int.chello.at@edge05.upcmail.net> for <vwrap@ietf.org>; Wed, 30 Mar 2011 03:15:00 +0200
Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upcmail.net with edge id RDEy1g00f0FlQed05DEz93; Wed, 30 Mar 2011 03:15:00 +0200
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from <carlo@alinoe.com>) id 1Q4jzu-0002y6-7H for vwrap@ietf.org; Wed, 30 Mar 2011 03:14:58 +0200
Date: Wed, 30 Mar 2011 03:14:58 +0200
From: Carlo Wood <carlo@alinoe.com>
To: "<vwrap@ietf.org>" <vwrap@ietf.org>
Message-ID: <20110330011458.GB8908@alinoe.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Cloudmark-Analysis: v=1.1 cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0 a=XYJHFtupD_QA:10 a=T713mU-8qjYA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=aMMpENY4S25QXj7jSpoA:9 a=aXpdYrQcjlTMpObtOJVRXrdz08oA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Subject: [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 01:13:25 -0000

Perhaps we should also start a wiki page (it's nice
to have a stable url that one can refer to, which still
is editable; that give me at least a feeling of progress),
about statements that we reached consensus over.

Being an abstract thinker and analyst, I believe we
can tackle many of the current discussions at a much
higer abstraction level first, making it easier, or
even possible, to deal with the more detailed points
of discussion.

I'd like to start with one such statement and ask
for consensus on it (and if not, give your rationale
why not).


* Whenever a change X in the protocol is proposed
  (which might be an addition, a change of existing
  protocol or even deletion: any change, making
  the protocol (VWRAP) go from A --> B), then that
  change is accepted as part of VWRAP provided that:
  1) Protocol B can do everything that A could do.
  2) No substantial extra demands are being made on
     an implementation that only implements the
     functionality of A.


In other words: we choose for flexibility.

Under no circumstances we want the *protocol* itself
to be a limitation in what is possible, when that
extra flexibility/possibility doesn't cost much for
those not needing or using it.

Companies be warned: that DOES mean that you lose
control: sometimes it is "nice" if it's impossible
to do with a protocol what your company doesn't
want. However, if that is what you want-- I'd like
to hear good reasons for that at THIS abstraction
level, and not while discussion details, because then
it's too easy to go against some proposal for "different"
reasons (not really saying that what you really want
is that something is just not possible with the protocol,
in order to garantee that things will deviate from YOUR
goals and ideas).


I sincerely hope we can reach consensus on this and
ask everyone to give their 'yes' or 'reasons for their
no'.

-- 
Carlo Wood <carlo@alinoe.com>