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

[Hannes Tschofenig <[e-mail]>]

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