Re: [apps-discuss] IETF technical plenary: the end of application protocols

Dave CROCKER <dhc@dcrocker.net> Mon, 21 March 2011 16:54 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEEF28C0EB for <apps-discuss@core3.amsl.com>; Mon, 21 Mar 2011 09:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.592
X-Spam-Level:
X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 M8EBCi5Lw9Td for <apps-discuss@core3.amsl.com>; Mon, 21 Mar 2011 09:54:10 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 4FCB73A687B for <apps-discuss@ietf.org>; Mon, 21 Mar 2011 09:54:10 -0700 (PDT)
Received: from [192.168.1.4] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p2LGtZli024160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2011 09:55:41 -0700
Message-ID: <4D878303.60908@dcrocker.net>
Date: Mon, 21 Mar 2011 09:55:31 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Scott Brim <scott.brim@gmail.com>
References: <4D87612E.3090900@dcrocker.net> <AANLkTik_f-4E8eoWbY2SowzTUdk53L3oiLZwFgoFS20y@mail.gmail.com> <4D876B4C.5070706@dcrocker.net> <4D877D30.9090502@stpeter.im> <4D877EDF.1090500@dcrocker.net> <AANLkTik6TEyXih9by+DLCqn+y6zAEPSP1pX0_kOb5j_8@mail.gmail.com>
In-Reply-To: <AANLkTik6TEyXih9by+DLCqn+y6zAEPSP1pX0_kOb5j_8@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 21 Mar 2011 09:55:41 -0700 (PDT)
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2011 16:54:11 -0000

On 3/21/2011 9:40 AM, Scott Brim wrote:
> On Mon, Mar 21, 2011 at 12:37, Dave CROCKER<dhc@dcrocker.net>  wrote:
>> I think Claudio raises another fundamental point, namely the loss of
>> interoperability.  The proposed model is a pure silo, with no apparent
>> ability to have variations or incremental capabilities that build on the
>> base, except by the single vendor providing the proprietary protocol.
>
> Could you give a specific example?


My email client accesses 6 different accounts.  The point of commonality is my 
client.  Typical silo solutions are for that silo only.

As being touted, that would mean 6 different downloaded, proprietary access 
clients, with my having to switch from one to another.  Besides being a pain, 
this means that they cannot share data, such as getting a message in on one 
account and forwarding it through another.

To the extent that you (quite reasonably) then project adaption of some of these 
to support additional, external accounts, what we done is merely to reinvent the 
general-purpose email client, except that I have to be careful to invoke the 
correct one every time...

d/

ps. The rather bizare problem with many different and non-interoperable IM 
protocols is another example of this.  Although some independent clients have 
gotten pretty good at providing an integrative experience, it is not possible to 
do group IMs except within a proprietary context requiring everyone to have an 
account with the same provider.  If then.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net