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

Mike Dickson <mike.dickson@hp.com> Fri, 01 April 2011 20:54 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 361B228C0EB for <vwrap@core3.amsl.com>; Fri, 1 Apr 2011 13:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.446
X-Spam-Level:
X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 a34WZaMW0rs4 for <vwrap@core3.amsl.com>; Fri, 1 Apr 2011 13:54:18 -0700 (PDT)
Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id 707C128C0D6 for <vwrap@ietf.org>; Fri, 1 Apr 2011 13:54:18 -0700 (PDT)
X-Authority-Analysis: v=1.1 cv=2pE2Kh9Ye2ywHyyFZnC5ZQ1FvuPrdOtuPO5uN4ysVDU= c=1 sm=0 a=SNAFxGGoWQUA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=cH6R9-kdAAAA:8 a=vhuo4gWzlUaIGBAV9zwA:9 a=7sXO9EnkgJg84L9W-HgA:7 a=QEXdDO2ut3YA:10 a=bt0zGP92IBIA: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:46051] helo=[192.168.0.101]) by cdptpa-oedge03.mail.rr.com (envelope-from <mike.dickson@hp.com>) (ecelerity 2.2.3.46 r()) with ESMTP id 7B/62-05159-EDB369D4; Fri, 01 Apr 2011 20:55:58 +0000
From: Mike Dickson <mike.dickson@hp.com>
To: Carlo Wood <carlo@alinoe.com>
In-Reply-To: <20110401162715.4fd05aa5@hikaru.localdomain>
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> <20110401162715.4fd05aa5@hikaru.localdomain>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 01 Apr 2011 16:55:53 -0400
Message-ID: <1301691353.2746.11.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: Fri, 01 Apr 2011 20:54:19 -0000

On Fri, 2011-04-01 at 14:27 +0000, Carlo Wood wrote:
> On Wed, 30 Mar 2011 12:20:34 -0400
> Mike Dickson <mike.dickson@hp.com> wrote:
> 
> > 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).
> 
> You really misunderstood the intention (so maybe there is still hope).
> 

I think perhaps I did misunderstand. It's just that I don't feel that
discussion at a purely semantic level makes sense in cases like this.  

For instance if you said you wanted to build flexibility into protocols
used between service endpoint A and service endpoint B and proposed:

- That stateful communications would negotiate capabilities from a set
of required and optional capabilities.
- That an implementer was free to NAK those optional capabilities they
didn't wish to implement.
- For stateless communication, that if a service is unable to fulfill a
request they can fail it in a way that the caller understands the
service isn't implemented.

All of these statements being focused on flexibly evolving the set of
protocols in order to maximize benefit to the implementers.

That is a concrete example directly related to the work we're doing.
And something I could agree to.  But saying we value flexibility as a
principle doesn't help me when it comes to protocol design.

So in general I think we agree, yes.  Assuming this example made sense.

Mike