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

[Marc Petit-Huguenin <[e-mail]>]

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: [e-mail] Professional
>> email: [e-mail] Blog: http://blog.marc.petit-huguenin.org
>> _______________________________________________ apps-discuss mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/apps-discuss
>


-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org