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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 21 March 2011 16:29 UTC

Return-Path: <stpeter@stpeter.im>
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 E87CF28C0EA for <apps-discuss@core3.amsl.com>; Mon, 21 Mar 2011 09:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.626
X-Spam-Level:
X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 QsFePtzMi2wt for <apps-discuss@core3.amsl.com>; Mon, 21 Mar 2011 09:29:09 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BE4B23A687B for <apps-discuss@ietf.org>; Mon, 21 Mar 2011 09:29:09 -0700 (PDT)
Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 807EB40022; Mon, 21 Mar 2011 10:31:40 -0600 (MDT)
Message-ID: <4D877D30.9090502@stpeter.im>
Date: Mon, 21 Mar 2011 10:30:40 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <4D87612E.3090900@dcrocker.net> <AANLkTik_f-4E8eoWbY2SowzTUdk53L3oiLZwFgoFS20y@mail.gmail.com> <4D876B4C.5070706@dcrocker.net>
In-Reply-To: <4D876B4C.5070706@dcrocker.net>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms050608060705020101030704"
Cc: Scott Brim <scott.brim@gmail.com>, 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
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:29:11 -0000

On 3/21/11 9:14 AM, Dave CROCKER wrote:
> 
> On 3/21/2011 7:43 AM, Scott Brim wrote:
>>
>> On 3/21/11 8:31 AM, Dave CROCKER wrote:
>>
>>> Replacing TCP with HTTP does not eliminate the requirement for
>>> purpose-built
>>> application protocols, such as specialized mailbox access.
>>
>> It's not replacing TCP with HTTP.  It's adding another more abstract API.
> 
> Not just an API.
> 
> There is are a set of exchange conventions that must exist between the
> client and the server to achieve the specifics of the application
> service.  That the server downloads code to the client and thereby
> provides the software for both ends of the exchange does not change the
> fact that this is a tailored exchange.
> 
> In networking, structured data exchanges are typically called protocols...
> 
> 
>>> On the other hand, it does tend to encourage an explosion of competing,
>>> incompatible application protocols, making for rather remarkable
>>> burdens on
>>> servers and clients.
>>
>> Those 'clients' are installed by the services.  There is no need for
>> every mail-related service to use exactly the same interface, since
>> nothing needs to know in advance how the interaction will go.  A few
> 
> I was not trying to deny the operational "convenience" of this process,
> although note that the gmail offline example still requires the user to
> go through installation hassles.
> 
> My point is that all this spontaneous downloading of redundant and
> slightly different software carries some problems.  (cf, Dave Cridland's
> response.)
> 
> To me, one of the more serious problems is the failure to see that these
> implement a potential explosion of proprietary protocols.

This is what I see, too: each service will have its own API / protocol,
resulting in wonderful vendor lock-in for the service provider but a
distinct lack of interoperability across services. We've just moved the
problem elsewhere.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/