Re: [apps-discuss] AJAX is the new NAT

Marc Petit-Huguenin <petithug@acm.org> Wed, 23 March 2011 22:39 UTC

Return-Path: <petithug@acm.org>
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 63DE03A6407 for <apps-discuss@core3.amsl.com>; Wed, 23 Mar 2011 15:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.16
X-Spam-Level:
X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 7IFEYwUT-b3l for <apps-discuss@core3.amsl.com>; Wed, 23 Mar 2011 15:39:39 -0700 (PDT)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 31F1B3A63D2 for <apps-discuss@ietf.org>; Wed, 23 Mar 2011 15:39:38 -0700 (PDT)
Received: by server.implementers.org (Postfix, from userid 1001) id F186EDBCC046; Wed, 23 Mar 2011 22:41:12 +0000 (UTC)
Received: from [192.168.2.225] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id C1C03DBCC044; Wed, 23 Mar 2011 22:41:11 +0000 (UTC)
Message-ID: <4D8A7707.9000603@acm.org>
Date: Wed, 23 Mar 2011 15:41:11 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100718 Icedove/3.1
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
References: <4D87612E.3090900@dcrocker.net> <33EA7EF3-E148-492E-94EF-E95DC6BB7160@tzi.org> <4D8A6261.1090308@acm.org> <0BD4169B-AA7F-4265-86C9-F2627074B75C@neustar.biz>
In-Reply-To: <0BD4169B-AA7F-4265-86C9-F2627074B75C@neustar.biz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] AJAX is the new NAT
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: Wed, 23 Mar 2011 22:39:40 -0000

On 03/23/2011 02:48 PM, Peterson, Jon wrote:
>
> I don't think the IETF started working on NATs because we all woke up one
> morning and decided that NATs were a great benefit to the Internet after all.
> We started working on NATs because we recognized that market forces well out
> of our control had selected NATs as a part of the Internet, whether we liked
> it or not. When we do our work, we have a choice: do we want to make the
> Internet better, or make better an imaginary network that embodies what we
> ideally want the Internet to be?
>
> To the argument that javascript leads us back to the innovation-crippling
> "telecom model," and that building applications on top of the web is
> inherently antithetical to end-to-end principles, I can only say that
> numerous small developers seem to leverage the web ecosystem today for their
> business, and that although there are giants in the web field who collect the
> lion's share of the revenue, the same seems to be true in the routing vendor
> business, say. If we do our job in the IETF, and build tools that will
> support security, scalability and interoperability in the web space, I don't
> think this design space poses any greater danger to the end-to-end model than
> we see elsewhere in the IETF. If we neglect our responsibilities in this
> space, however, and then probably lower-layer components will adopt
> non-interoperable working parts, and we will drift closer to the forecasted
> "splinternet." The discussion in RTC-Web about the potential for
> interoperability between different web VoIP services throws this into painful
> relief.

This is the trapezoidal model - exactly the same model used by SIP, which makes 
you unable to call the videophone on my desk, even if they use the same exact 
codec, SIP and IP protocol.  I do not see how adding JavaScript in the mix can 
improve anything - excepted the bottom line of a few.

Besides the role of the IETF should be to increase the relevance of the end to 
end argument, not just merely verifying that a new design does not pose a danger 
to it.

>
>
> On Mar 23, 2011, at 2:13 PM, Marc Petit-Huguenin wrote:
>
>> On 03/23/2011 01:22 PM, Carsten Bormann wrote:
>>> So, AJAX appears to be the new NAT.
>>>
>>> (For those who weren't there in the 1990s: the IETF closed their eyes
>>> with respect to the emerging pervasiveness of NATs and continued
>>> designing protocols that ignored NATs and then didn't win. I was hoping
>>> we would never do that again.)
>>>
>>> (For those who weren't there in the 2000s: AJAX has indeed made the
>>> browser a useful application delivery platform.  Once a node can control
>>> the code on *both* communicating peers, it can do interesting things
>>> without having to standardize much, as shown in RFC 3320 and as
>>> demonstrated nicely in AJAX.  If you read German, there is even a
>>> somewhat dated book from 2005 still online at
>>> http://www.teialehrbuch.de/Kostenlose-Kurse/AJAX/ the initial chapters of
>>> which explain why this form of mobile code is winning.)
>>>
>>> Now for 2011:
>>>
>>> What we need to do is acknowledge that AJAX has happened.
>>>
>>> The Web hasn't been "hypertext" for a long time now.  With all the
>>> negative (and not so negative) effects, which were nicely tabulated by
>>> Mark Nottingham in this thread.
>>>
>>> What we also need to do is help steer the standards-based foundation so
>>> that it encourages each and every single developer to favor
>>> standards-based (or standards-like) APIs/protocols even in this brave new
>>> world.  The persistence of REST in the AJAX world has helped a lot;
>>> other, community-driven standards such as JSON have even been picked up
>>> by the IETF (even though RFC 4627 is labeled Informational). But, for
>>> example the rigid same-origin policy of the existing browser world makes
>>> standards-based APIs less useful though -- AJAX apps can only use their
>>> own servers' APIs, so there is less incentive to offer AJAX APIs for
>>> consumption by other apps/clients.
>>>
>>> The IETF needs to *help* the AJAX world, not close our eyes again. Help
>>> AJAX get better, get more secure.  Get more standards-based, more open.
>>
>> The greedy corporations who sold NATs to fix a problem that could have
>> been fixed the right way, but with less money in their pocket, ruined the
>> Internet for everybody.  The same thing is happening today with a bunch of
>> hyperactive people who still do not understand why it is wrong to copy the
>> user input directly in a database query and want their fabulous application
>> deployed in the next 5 minutes.  You do understand that we are going back
>> to the telecom model, intelligent network, dumb terminals, lots of money in
>> their pockets, not much in ours, right?  Why smart people like the IETF
>> want to be sure that in a close future they will never ever again been able
>> to invent a new application that does not go through the servers of a few
>> powerful corporations answering only to their shareholders is beyond me.
>>
>> Yes, the end to end argument is dying, but what are we doing about this
>> problem, is the right question.  Not how a chain saw is a better tool to
>> cut the branch we are perched on.
>>
>>
>> -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional
>> email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org
>> _______________________________________________ apps-discuss mailing list
>> apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
>


-- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org