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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 21 March 2011 17:31 UTC

Return-Path: <hannes.tschofenig@gmx.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 8856228C0F6 for <apps-discuss@core3.amsl.com>; Mon, 21 Mar 2011 10:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 bmnVz8j1H4Id for <apps-discuss@core3.amsl.com>; Mon, 21 Mar 2011 10:31:45 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 11D0C28C0F2 for <apps-discuss@ietf.org>; Mon, 21 Mar 2011 10:31:44 -0700 (PDT)
Received: (qmail invoked by alias); 21 Mar 2011 17:33:16 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp018) with SMTP; 21 Mar 2011 18:33:16 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/7OL93a5r7TB3WkZuNEYg3jP9Bhq7CwWkYRJCB3u jqp8PDqqUGCXCZ
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <4D8785D2.5070306@dcrocker.net>
Date: Mon, 21 Mar 2011 19:33:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4DB77E0-3041-44D5-B232-6420ACF02978@gmx.net>
References: <4D87612E.3090900@dcrocker.net> <560B27DE-B188-45D6-AC91-51A643FD8520@gmx.net> <4D8785D2.5070306@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1082)
X-Y-GMX-Trusted: 0
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
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 17:31:47 -0000

Hi Dave, 

On Mar 21, 2011, at 7:07 PM, Dave CROCKER wrote:

> 
> 
> On 3/21/2011 9:58 AM, Hannes Tschofenig wrote:
>>> One is that it mandates full-time connectivity.
>> 
>> No; it does not mandate full-time connectivity. It only mandates connectivity
>> between the client and the server.
> 
> ??? That's the connectivity I am referring to.
> 
There are lots of other things you could refer to. 

Btw, you also need client-to-server connectivity to fetch your mails...

> 
>> For example, look at your Web-based email
> 
> I don't use web-based mail.  I realize that that mode is extremely popular and that it is a useful mode, but I find it problematic, for a number of the reasons we've been discussing on this thread.
> 
> One of the issues this highlights is the need to be very careful not to tout the benefits of something as universal when, in fact, it has restricted utility.
> 

For service providers it matters what most users like. It seems that more and more people are experiencing the Internet via Web browser. 


> 
>> account (like Gmail). The client-to-server interaction indeed requires
>> connectivity. However, it does not require full end-to-end community to work.
> 
> I do not understand what distinction you are drawing.
> 
> 

There are different communication paradigms. The discussion that is currently ongoing in the RAI area is focused on real-time communication between two endpoints (browsers). 
So, the level of required connectivity is different. 

There both parties always need to be online. If they aren't nothing works. This is not a constraint given the application space folks are looking at. 



>>> The other is that protocols that it says are no longer needed are in fact
>>> still needed in some form, albeit as a layer above HTTP, rather than TCP.
>> 
>> We are not saying that the protocols are not needed at all anymore. However,
>> the need for standardization shifts.
> 
> Actually, that really is what the announcement implies.
> 
> 

The importance of the entire plenary is about innovation and how the choice of architecture impacts the speed of innovation. 


>>> 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.
>> 
>> Not really. It allows people to innovate at full speed. There is no need to
>> go through a 5 year standardization effort for a protocol extension when you
>> can make it available to others easily (without even letting the user to
>> download and instal a new application).
> 
> No one said that standardization-prior-to-use was a preferred model.  I suspect you are confusing architectural issues with alternatives for developing and standardizing interoperable protocols.
We describe a model that is deployed today (the Web model with HTTP/HTML + JavaScript) that allows shifting the interoperability need away from the client. 
The talk will further argue that following this model will let you innovate faster and everything that does not follow this model will have a hard time to compete. If you look around in the IETF applications and RAI area then you will notice that we are seen this hard time today. 


Regarding "No one said that standardization-prior-to-use was a preferred model.": This is what the W3C did with some of their work on HTML5. The experience of Google on Gmail with offline storage was folded into the HTML5 related work. 

Ciao
Hannes

> 
> d/
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net