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

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Mar 2011 07:31:10 -0700

Folks,

I just saw the announcement for the Technical Plenary presentation.

As described, the session suggests a failure to recognize at least two 
architectural issues.

One is that it mandates full-time connectivity.  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.

Replacing TCP with HTTP does not eliminate the requirement for purpose-built
application protocols, such as specialized mailbox access.

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.

The summary also neglects to mention rather significant security concerns in all 
this real-time application downloading...

d/

> The Future of Applications
>
>
> Advancements in the design of web browsers have introduced fundamental
> changes to the architecture of application protocols. The widespread
> availability and growing sophistication of JavaScript interpreters in
> browsers enables web servers to push to browsers all of the application
> logic required to implement a client-server protocol. Consequently, many
> client-server applications that once required an installed client on a host
> computer now can rely simply on a modern browser to act as a client for the
> purposes of a particular application. For example, where once email clients
> required a custom application to access an inbox, increasingly a web browser
> can serve this purpose as well as the purpose-built applications of the
> past. Similarly, HTTP with the assistance of JavaScript can subsume the
> functions performed by the protocols like POP3 and IMAP. The need for
> Internet standards beyond HTTP to implement an email inbox application
> consequently diminishes - why author standards and worry about
> interoperability of clients and servers when the server can simply push to
> the client all the code it needs to be interoperable?
>
> Many client-server applications on the Internet could potential migrate to
> this post-standardization environment. In this environment, there is of
> course still a role for the IETF to play: existing working groups like HyBi
> and OAuth are examples of areas where standards work is still required to
> support this application development paradigm. Collectively, we need to
> identify areas where the standardization is unlikely to be relevant in the
> future, and focus our efforts on those areas where our application designs
> will remain impactful. The goals of this session are to explore future areas
> of IETF work surrounding this evolution.
>
> Speakers: Jonathan Rosenberg (Skype) Harald Alvestrand (Google) Henry S.
> Thompson (W3C)

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave Cridland <[email-masked]>
Date: Mon, 21 Mar 2011 14:45:04 +0000

On Mon Mar 21 14:31:10 2011, Dave CROCKER wrote:
> As described, the session suggests a failure to recognize at least  
> two architectural issues.

More than that, actually.

> as a layer above HTTP, rather than TCP.

Right - repeated redesign doesn't lend itself well to optimal  
protocol.

> application protocols, such as specialized mailbox access.

No, and crucially, it hugely increases the cost of lightweight  
clients. I can code an IMAP library, say, in a few hundred lines of  
code in pretty well any language, whereas in order to support the new  
world order, I'd have to begin by ensuring I had Javascript available  
on the device. The baseline stack needed to read email, therefore,  
would exponentially increase.

Secondly, the bandwidth overhead of HTTP is very significant. While  
this would undoubtedly be lowered  by the efforts of HyBi (admittedly  
this results in double-AES, but still) it still involves downloading  
a client afresh each time, as well as at least the majority of data,  
in a world where connectivity is still metered by the byte in many  
cases.

I do, of course, recognise that there are significant benefits to a  
HTTP/Javascript world, but the notion that we are somehow  
"post-standardization" suggests that we are also "post-desktop"; that  
all we ever need nowadays is a web browser. I've not heard that one  
since the Netscape browser-as-platform days, and it's a loony now as  
it was then.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Scott Brim <[email-masked]>
Date: Mon, 21 Mar 2011 10:43:40 -0400

> As described, the session suggests a failure to recognize at least two

Dave, here's my understanding ...

> One is that it mandates full-time connectivity.

No.  Look, for example, at 'offline gmail', in which browser-based
scripts cache files locally while doing their normal job of
interacting with a cloud-based service.  For starting offline, there
is a little local app that essentially says "fire up a browser and run
this script in it".

> The other is that protocols

On one hand you have application programs with socket interfaces
speaking to TCP and controlling everything TCP does.  On the other you
have application modules loaded by a browser and speaking to the
browser (not necessarily HTTP).

> application protocols, such as specialized mailbox access.

It's not replacing TCP with HTTP.  It's adding another more abstract API.

> incompatible application protocols, making for rather remarkable burdens on

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
basics need to be agreed, e.g. HTTP, HTML, PHP, Javascript.  But how
those scripts actually speak to the service does not need to be
standardized.

> The summary also neglects to mention rather significant security concerns in
> all this real-time application downloading...

Please say more.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Mar 2011 08:14:20 -0700

> is a little local app that essentially says "fire up a browser and run

Exactly.  That's just another installed app:

    <http://mail.google.com/support/bin/answer.py?hl=en&answer=97535>

> browser (not necessarily HTTP).

Well, I do note the somewhat different terminology you use to distinguish the 
two, but I'm not clear how that relates to my point:  There is still a special 
protocol for the tailored application.

> 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...

> 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.

> those scripts actually speak to the service does not need to be

As the other Dave C notes, that is a heck of a lot of infrastructure overhead.

>> all this real-time application downloading...

There is a popular name for software that is injected into a user's machine 
without the user necessarily knowing about it or approving of it explicitly...

To get computer sciency:  mobile agent models have long been understood to pose 
a serious security risk.

But don't get me wrong.  I think mobile agent technology is the bee's knees. 
I've been a fan at least since working on an early example (Telescript at 
General Magic) and encouraging development of SafeTCL...  However, I think it is 
problematic to view this space simplistically.

d/
-- 

   Dave Crocker

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 21 Mar 2011 16:15:17 +0100 (CET)

It seems to me more a "provocative" talk, than a fully consisten one... 
but of course it also accepts as "granted" thet given HTTP goes throug 
firewalls, and NATs etc, it is the way to solve the problem that the 
"transport" has in IPv4.

Defintly a wrong concept...

> incompatible application protocols, making for rather remarkable burdens on

I agree... just an example? "calendars"... we do have protocols for it... 
but a large number of those implemented "inside HTTP" just do not 
interoperate among them and with standard clients. Another example? 
audio/video communication in collaborative/group communications.

> all this real-time application downloading...

sure!

and I will be there to pose lot's of questions about this security aspect 
of the proposed solutions. :-)

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Bhumip Khasnabish <[email-masked]>
Date: Mon, 21 Mar 2011 11:40:23 -0400

Virtualization of the desktop infrastructure with properly defined interface
protocols and APIs may help solve the problems.  We probably need to explore
these more in the APP area.  Thanks.

Bhumip ([email-masked])
**
On Mon, Mar 21, 2011 at 11:15 AM, Claudio Allocchio <
[email-masked]> wrote:

>
> It seems to me more a "provocative" talk, than a fully consisten one... but
> of course it also accepts as "granted" thet given HTTP goes throug
>> The summary also neglects to mention rather significant security concerns
>> in all this real-time application downloading...
>>
>
> sure!
>

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Mar 2011 08:45:59 -0700

On 3/21/2011 8:15 AM, Claudio Allocchio wrote:
> and I will be there to pose lot's of questions about this security aspect of the
> proposed solutions. :-)

There is a difference between controlling the dais versus begging for time at 
the audience microphone.

My concern, based on the offered description, is that the presentation will be 
an exercise in unbounded boosterism.

Engineering is an exercise in discerning and selecting among tradeoffs.  This 
requires diligent efforts to acknowledge, understand and deal with downsides and 
well as upsides.

d/
--

   Dave Crocker

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 21 Mar 2011 17:09:43 +0100 (CET)

> My concern, based on the offered description, is that the presentation will 
> be an exercise in unbounded boosterism.

that's why I called it a "sort of provocative talk". If the intention was 
not this, e.g. to raise a discussion, then somebody did the wrong choice.

> requires diligent efforts to acknowledge, understand and deal with downsides 
> and well as upsides.

I fully agree. Another bullet point not in the description: "mobile 
internet effects of the proposed solution". Carriers will be happy with 
all these one-time downloads, while users will be very unhappy while 
watching the "please wait" icon on their mobile device.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Mar 2011 10:30:40 -0600

On 3/21/11 9:14 AM, Dave CROCKER wrote:
>> On 3/21/11 8:31 AM, Dave CROCKER wrote:
>>
> 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.
> 
> 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.)
> 

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/

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Mar 2011 09:31:59 -0700

On Mon, Mar 21, 2011 at 9:09 AM, Claudio Allocchio
> I fully agree. Another bullet point not in the description: "mobile internet
> effects of the proposed solution". Carriers will be happy with all these
> one-time downloads, while users will be very unhappy while watching the
> "please wait" icon on their mobile device.
>

I fully agree that "mobile Internet effects" would be a useful thing
to add to the discussion, but I think you should talk to an operator
before presuming that they would be happy with " all these one-time
downloads".  If the consumption reduces the availability of resources
in the radio access network such that fewer subscribers can be
serviced in a cell sector, you are likely to get the opposite result.
They either have unhappy customers who generate support costs and
churn, build out costs to increase the number of cells, or artificial
limitation of revenue opportunities.  None are fun.

To put this more generally, waste is the enemy of the
resource-constrained device or system.  And wireless spectrum is
pretty commonly acknowledged as a constrained resource.

regards,

Ted Hardie

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Mar 2011 09:37:51 -0700

> distinct lack of interoperability across services. We've just moved the

I think Claudio raises another fundamental point, namely the loss of 
interoperability.  The proposed model is a pure silo, with no apparent ability 
to have variations or incremental capabilities that build on the base, except by 
the single vendor providing the proprietary protocol.

The point that Claudio and Ted make about possible inefficiencies due to 
repeated download is also worth noting.'

d/

-- 

   Dave Crocker

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 21 Mar 2011 17:43:40 +0100 (CET)

On Mon, 21 Mar 2011, Ted Hardie wrote:

> downloads".

yes, ... I was just thinking of the "billing aspect of volume based 
contracts" of course.

   If the consumption reduces the availability of resources
> limitation of revenue opportunities.  None are fun.

And in some areas we already see the effects: 3G is no longer what it used 
to be, and users rush to WiFi hot-spots, non only for billing reasons.

> pretty commonly acknowledged as a constrained resource.

+1

---

From: Scott Brim <[email-masked]>
Date: Mon, 21 Mar 2011 12:40:01 -0400

> distinct lack of interoperability across services. We've just moved the

What interoperability do you need?  This isn't peer to peer, it's
client/server.  All of the servers have de facto converged on the same
client capabilities (http, html etc).  It's already standardized.

Granted there are new scripting languages all the time, and some
browsers like new transport protocols, but those don't lead to
interoperability problems.  They lead to implementor problems, having
to do different versions of software for different environments.  Is
that what you're pointing to?  Would you say that iPhone and Android
should have the same app environments?

---

From: Scott Brim <[email-masked]>
Date: Mon, 21 Mar 2011 12:40:49 -0400

On Mon, Mar 21, 2011 at 12:37, Dave CROCKER <[email-masked]> wrote:
> interoperability.  The proposed model is a pure silo, with no apparent
> ability to have variations or incremental capabilities that build on the
> base, except by the single vendor providing the proprietary protocol.

Could you give a specific example?

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 21 Mar 2011 12:52:13 -0400

Hi Scott,

> client capabilities (http, html etc).  It's already standardized.

What if I have multiple service providers yet I want to present an 
aggregated view of all the data? e.g. the very common case of having 
multiple email accounts on different providers and wanting a "unified" 
inbox. With the "proprietary" approach of silo-ed web services, that 
becomes hard. Either I have to have a local app that understands each of 
the "proprietary" protocols and does the aggregation locally, or I have to 
rely on an intermediary to aggregate the data (which probably requires 
handing over credentials or doing some complicated crypto).

-- 
Cyrus Daboo

---

From: Bhumip Khasnabish <[email-masked]>
Date: Mon, 21 Mar 2011 12:52:28 -0400

>distinct lack of interoperability across services. We've just moved the
Yes, actually each service, service provider, developer-group, etc. and so
on start using own protocol/API .. the problem actually gets worse .. and
the silos get bigger and bigger (not necessarily better).

Bhumip

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Mar 2011 09:55:31 -0700

On 3/21/2011 9:40 AM, Scott Brim wrote:
> On Mon, Mar 21, 2011 at 12:37, Dave CROCKER<[email-masked]>  wrote:

My email client accesses 6 different accounts.  The point of commonality is my 
client.  Typical silo solutions are for that silo only.

As being touted, that would mean 6 different downloaded, proprietary access 
clients, with my having to switch from one to another.  Besides being a pain, 
this means that they cannot share data, such as getting a message in on one 
account and forwarding it through another.

To the extent that you (quite reasonably) then project adaption of some of these 
to support additional, external accounts, what we done is merely to reinvent the 
general-purpose email client, except that I have to be careful to invoke the 
correct one every time...

d/

ps. The rather bizare problem with many different and non-interoperable IM 
protocols is another example of this.  Although some independent clients have 
gotten pretty good at providing an integrative experience, it is not possible to 
do group IMs except within a proprietary context requiring everyone to have an 
account with the same provider.  If then.

-- 

   Dave Crocker

---

From: Graham Klyne <[email-masked]>
Date: Mon, 21 Mar 2011 16:55:31 +0000

Ah, I wish I could be there!

I think it's not so black-and-white.  The problems mentioned are real enough, 
but there are other considerations too:

- for some applications, designing to run on HTTP can increase the effective use 
of bandwidth by making it easier to build applications around more 
coarse-grained exchanges.  More bang per round-trip.  (Of course this *can* be 
done over bare TCP, but HTTP handles much of the common grunt work).

- for some applications, a focus on a RESTful style of interface pushes the 
emphasis away from multiple protocols towards a common protocol with more 
complex object representations.  Yes, this moves the application domain problems 
somewhere else, but that somewhere else is less dependent on a detailed 
bilateral agreement about the nature of exchanges.

- for some applications, using Javascript in the browser can dramatically reduce 
the complexity of a distributed client-server application, and the attendant 
network exchanges, by allowing client state to be managed locally and reducing 
the amount of state that the server needs to be aware of.

HTTP is much, much more than a simple request/response protocol.  It underpins 
the most successful, most scalable distributed application the world has seen, 
and *for some applications* that fit well into its particular model of 
interaction, I think it can offer improved efficiency and reduced siloing of 
applications.

Of course, your application may vary.

#g
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2011 18:58:54 +0200

Hi Dave, 

you may want to take a look at the more complete writeup, which we submitted as an Internet draft: 
http://tools.ietf.org/html/draft-tschofenig-post-standardization-00

On your questions below: 

On Mar 21, 2011, at 4:31 PM, Dave CROCKER wrote:

> As described, the session suggests a failure to recognize at least two architectural issues.
> 

No; it does not mandate full-time connectivity. 
It only mandates connectivity between the client and the server. 
For example, look at your Web-based email account (like Gmail). The client-to-server interaction indeed requires connectivity. 
However, it does not require full end-to-end community to work. The real-time communication work that is being discussed in the RAI area does require end-to-end community because this is the entire purpose of the whole exercise. 

> 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. 

> incompatible application protocols, making for rather remarkable burdens on

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). 

> 
> The summary also neglects to mention rather significant security concerns in all this real-time application downloading...

The short summary on the announcement page cannot cover every issue. We did, however, touch on this aspect in the draft. 

Thanks for paying attention to the IAB plenary topic. 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2011 19:03:46 +0200

The most important aspect to look at is where interoperability is truly needed. 
The speakers at the plenary will argue that you do not need interoperability everywhere.

Do not get me wrong - interoperability is great but it comes at a cost. 

If you look at the Web application space then you would quickly ask yourself "Where would the Web be if everything has to be standardized?"

On Mar 21, 2011, at 6:52 PM, Bhumip Khasnabish wrote:

> Yes, actually each service, service provider, developer-group, etc. and so on start using own protocol/API .. the problem actually gets worse .. and the silos get bigger and bigger (not necessarily better). 
>  
> Bhumip

---

From: Scott Brim <[email-masked]>
Date: Mon, 21 Mar 2011 13:01:38 -0400

On Mon, Mar 21, 2011 at 12:52, Cyrus Daboo <[email-masked]> wrote:
> inbox. With the "proprietary" approach of silo-ed web services, that becomes
> hard. Either I have to have a local app that understands each of the
> "proprietary" protocols and does the aggregation locally, or I have to rely
> on an intermediary to aggregate the data (which probably requires handing
> over credentials or doing some complicated crypto).

First, as I understand it, the aggregator is the browser.  Don't think
of each of these as "mail".  They are more "browser-based
interactions" that might include mail.  Consider the google "mail"
front page, which can optionally have 17 other things (calendar,
online friends, grocery manager via Google API, etc.).  So if your
browser has the tools to connect to each of these services -- which it
does -- then it becomes a problem of how to show multiple "pages" in
an interesting way.

Second, if you want to totally integrate, e.g. have a common inbox for
mail, then yes you need 'mail' APIs for each of them, as opposed to
'service' APIs that I believe we're talking about.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Mar 2011 10:07:30 -0700

On 3/21/2011 9:58 AM, Hannes Tschofenig wrote:
> 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.

>  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.

> 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.

>> 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.

>> 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.

d/
-- 

   Dave Crocker

---

From: Scott Brim <[email-masked]>
Date: Mon, 21 Mar 2011 13:09:02 -0400

On Mon, Mar 21, 2011 at 12:55, Dave CROCKER <[email-masked]> wrote:
> My email client accesses 6 different accounts.  The point of commonality is
> my client.  Typical silo solutions are for that silo only.

See response to Cyrus.

> clients, with my having to switch from one to another.  Besides being a
> pain, this means that they cannot share data, such as getting a message in
> on one account and forwarding it through another.

I can give you an existence proof of that working today but I'm
getting hesitant to name specific services.

Let's get away from using email as an example.  Even within the mail
world, none of the web-based mail services are just mail, although
they offer a just mail API (IMAP, POP).

> Although some independent clients
> have gotten pretty good at providing an integrative experience, it is not
> possible to do group IMs except within a proprietary context requiring
> everyone to have an account with the same provider.

OK, a good example.  The difference between this and mail is that
there is no back end connectivity.  With mail you can use any
(including proprietary) interface to your service, and it will get it
to other services.  Since there are standards in the _back_ end, there
don't have to be standard user interfaces in the _front_ end.  I think
this is finally a point worth bringing up.

---

From: Scott Brim <[email-masked]>
Date: Mon, 21 Mar 2011 13:12:40 -0400

> ??? That's the connectivity I am referring to.

This morning I was using one of these web-based mail services in
offline mode.  It caught up when I reconnected.

> 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.

You should try out some browser-based, cloud-based tools so you have
more experience in this area. :-)

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2011 19:33:15 +0200

Hi Dave, 

> ??? 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...

> 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. 

> 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. 

> 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. 

> 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

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 21 Mar 2011 18:46:34 +0100 (CET)

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

because they do not know what the Internet is suppoused to be: 
"communicating with the others", e.g. receive information, but also 
GENERATE information.

At least in the "research and education" sections of the Internet we still 
stick to the paradigm that users generate information and content, and 
they invent their own services, while we (the "carrier") do not tell them 
what they can "download", or again we (the "carrier") just give users 
simmetrical connectivity. And when we ask for innovation proposals, the 
most innovative ones we get are not "via Web Browsers". An example: a 
real-time audio-video protocol which enable musicians to perform a live 
concert even when they're a thousand miles apart from each other.

but this will lead quite far away from what we started to discuss...

:-)

---

From: Scott Brim <[email-masked]>
Date: Mon, 21 Mar 2011 13:51:01 -0400

> 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.

I suspect this is the gist.  It used to be that we required standard
protocols at the endpoint.  As Dave's mention of IM clients shows,
that's necessary if there is no coordination among services.  But if
there is coordination among services, such that using any one service
allows you to reach anyone on any service, then you don't need
standardized UIs.

---

From: Scott Brim <[email-masked]>
Date: Mon, 21 Mar 2011 13:53:31 -0400

On Mon, Mar 21, 2011 at 13:46, Claudio Allocchio
<[email-masked]> wrote:
> "communicating with the others", e.g. receive information, but also GENERATE
> information.

yes we must absolutely insist that the Internet be fundamentally peer
to peer.  But on top of that, 98% of exchanges between what look like
peers at the IP layer is client-server at higher layers.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2011 20:01:13 +0200

Hi Claudio, 

I am not sure I understand your argument. 

I am using the term "service provider" in a quite relaxed way. 

For example, I (Hannes) want to reach out to others to share my remarks about IETF what would I do? 
I would (and I did) I installed a Wordpress blog. If I want to add chat capabilities, I add Strophe (a JavaScript based XMPP implementation). 
If I want to outsource my identity management (to make it simpler for others to comment on my blog) then I add OAuth and OpenID. 

I can (as a service provider) add a lot of functionality without demanding you to download a new application (every time I make add more functionality to my site).
You could even play nice little games via my site; everything runs in JavaScript. 

I hope I made it clear what I mean by "service provider". 

Ciao
Hannes

On Mar 21, 2011, at 7:46 PM, Claudio Allocchio wrote:

> because they do not know what the Internet is suppoused to be: "communicating with the others", e.g. receive information, but also GENERATE information.
> 
> At least in the "research and education" sections of the Internet we still stick to the paradigm that users generate information and content, and they invent their own services, while we (the "carrier") do not tell them what they can "download", or again we (the "carrier") just give users simmetrical connectivity. And when we ask for innovation proposals, the most innovative ones we get are not "via Web Browsers". An example: a real-time audio-video protocol which enable musicians to perform a live concert even when they're a thousand miles apart from each other.
>

---

From: Dave Cridland <[email-masked]>
Date: Mon, 21 Mar 2011 18:05:01 +0000

On Mon Mar 21 17:51:01 2011, Scott Brim wrote:
> > 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.
> 

With XMPP, an XMPP server will talk with other XMPP servers - this  
means that HTTP cannot be used. (And if anyone suggests S2S/BOSH I  
will throw up).

But XMPP clients also talk with other clients, in sometimes  
client-specific ways over variable services.

Thus to no small degree the XMPP experience is governed by the  
client, rather than the server, and the overall experience is most  
certainly a product of both.

This is also similar with mail - you may think of email as just a  
blob of functionality, but I can assure you that there are both good  
and bad email clients, and good and bad email services.

By restricting client/server to be just browser-based, you eliminate  
the ability of users to select a user interface of their choice  
orthogonal to the service, and you also create a down-pressure on  
functionality via standardized protocols - hence Google Mail's IMAP  
support is very much a lowest common denominator - it is sufficient,  
instead of offering the richer support it might.

This is not to say that a web-based interface is not a good thing,  
and a useful thing, too - there are plenty such interfaces for both  
email and XMPP. In fact, in XMPP there are many more because we  
devised standards for how browser-based clients could connect to  
servers (see BOSH, for example).

Dave.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2011 20:07:44 +0200

On Mar 21, 2011, at 7:53 PM, Scott Brim wrote:

> to peer.

Whatever the peers in this exchange are. 

If peer means Web browser then you will probably like the RTCWeb BOF.

>  But on top of that, 98% of exchanges between what look like

Purely a matter of definition. 

Ciao
Hannes

---

From: Dave Cridland <[email-masked]>
Date: Mon, 21 Mar 2011 18:12:18 +0000

On Mon Mar 21 18:01:13 2011, Hannes Tschofenig wrote:
> I would (and I did) I installed a Wordpress blog. If I want to add  
> chat capabilities, I add Strophe (a JavaScript based XMPP  
> implementation).

Thanks for proving my point as I wrote it - Strophe.js is in itself  
only possible because we (that is, the XMPP community) went to some  
effort to standardize a method for browser-hosted XMPP clients to  
interoperably connect to XMPP servers. It's almost a perfect  
counter-example to your argument.

If you want chat *without* having an XMPP server in your browser,  
you're forced into reinventing IM for your purposes - which is indeed  
possible. You need not do this yourself, of course, just as you  
needn't write your own XMPP server, but unlike the latter case,  
you're very tightly coupled to the solution.

Dave.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Mar 2011 20:16:19 +0200

On Mar 21, 2011, at 8:05 PM, Dave Cridland wrote:

> With XMPP, an XMPP server will talk with other XMPP servers - this means that HTTP cannot be used. (And if anyone suggests S2S/BOSH I will throw up).

I was focusing more on the client-to-server interaction; I don't think the need for interoperability on the server-to-server side vanishes. 

The model I have in my mind is this one:
(modified from http://tools.ietf.org/html/draft-rosenberg-rtcweb-framework-00)

                +-----------+             +-----------+
                |   Web     | Server-to-  |   Web     |
                |           | Server      |           |
                |           |-------------|           |
                |  Server   |             |  Server   |
                |           |             |           |
                +-----------+             +-----------+
                     /                           \
                    /                             \   Proprietary over
                   /                               \  HTTP/Websockets
                  /                                 \
                 /  Proprietary over                 \
                /   HTTP/Websockets                   \
               /                                       \
         +-----------+                           +-----------+
         |JS/HTML/CSS|                           |JS/HTML/CSS|
         +-----------+                           +-----------+
         +-----------+                           +-----------+
         |           |                           |           |
         |           |                           |           |
         |  Browser  | ------------------------- |  Browser  |
         |           |   Media (if needed)       |           |
         |           |                           |           |
         +-----------+                           +-----------+

The browser to server side does not need to be standardized. Everyone is, however, free to use what standardized protocol they want. 
There is no shortage of standardized protocols for that interface. 

If you want cross-service provider communication then the interoperability need is on the server-to-server side. 

Given that you are heavily involved in the XMPP space you are very much familiar with this model. 

Ciao
Hannes

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Mar 2011 11:27:00 -0700

On Mon, Mar 21, 2011 at 9:58 AM, Hannes Tschofenig

> 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 (with…

So, there is an old saying: "Success has many fathers, but failure is
an orphan".  While I strongly agree that establishing where
interoperability is needed should make for an interesting plenary
discussion and is something every WG should consider, I think we have
to be pretty careful in reading any paternity tests for the pace of
innovation.

There are several mutually reinforcing network effects here.  The web
provided the opportunity for many people to become publishers as well
as consumers of network resources.  That created a pool of developers
and the opportunity for those who wanted to build tools for that pool
of developers.  That created a further explosion in interest in
creating content and new innovations in the kind of content that could
be created entirely within the web context (at one of my early
employers, we created interactive content using web forms and Sun RPC,
and the transition in technologies took a few years).

While all of this content was moving onto the web, firewall and NAT
technologies were getting widely deployed.  One of the biggest risks
was unvetted web-based content, but it could not be sequestered
without enormous outcry, so those ports were left open.  This pushed
other kinds of traffic onto those ports, even when there was no user
produced or consumable information involved.  That increased the set
of developers who understood network programming, but only from a
web-centric view point.  That, in turn, created a new body of content
and protocols built on those tools.

Network effects are very powerful, as we all know.  The availability
of one set of tools in the web environment (downloadable javascript)
has clearly had an important part in that.  But let's not confuse its
role with the overall effect.  It's particularly important that we not
ascribe to those tools the overall pace of innovation.  Developer
community size, security models, and network topology restrictions
have been as or more important.

Any of the Daves in this conversation could create an innovative
protocol to solve a problem without touching the web.  It might take a
good bit longer to deploy than one that did, but it's a set of other
constraints (treatment of downloaded standalone applications vs.
downloaded web applications, NATs, Firewalls, developer interest) that
would slow its pace.

That's important in part because new network effects are always
possible.  If we ascribe their results to one particular set of tools
we may miss the generative possibilities of other tools.

regards,

Ted Hardie

---

From: Dave Cridland <[email-masked]>
Date: Mon, 21 Mar 2011 18:34:57 +0000

> much familiar with this model.

Nope, your model is entirely alien to me; your assumptions therefore  
fail.

In the XMPP world, clients talk to each other and are mediated and  
aided by servers. This model is far closer to the model of hosts and  
routers, and there's much similarity - XMPP has a tendency toward  
pushing functionality out to the clients and avoiding involving the  
servers unless it's unavoidable.

Yet XMPP *also* has very fast innovation, which I attribute to its  
close-knit culture and approachable specifications. And beer.

So I think I agree with Ted Hardie, on another level - I think  
analysing why innovation can be quick and slow is interesting, but  
presenting a "final solution" for client/server interop seems a  
little hasty.

Dave.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 21 Mar 2011 22:48:20 -0500

> I just saw the announcement for the Technical Plenary presentation.
I sent this to the IAB a few weeks ago. We haven't had much conversation 
(they responded, but the firehose of stuff before the IETF meeting kept 
me from replying until recently), but I thought you all would be amused.

-------- Original Message --------
Message-ID: <[email-masked]>
Date: Tue, 8 Mar 2011 16:53:21 -0600
From: Pete Resnick <[email-masked]>
To: <[email-masked]>
Subject: IAB Technical Session
CC: "'The IESG'" <[email-masked]>

[Feel free to forward this as you see fit.]

Dear IAB,

You will probably find it unsurprising that I find the abstract of the 
technical session at the IAB plenary to be completely unadulterated 
rubbish. It is by no means the "advancement in the design of web 
browsers" nor the "widespread availability and growing sophistication of 
JavaScript interpreters in browsers" that has changed the architecture 
of applications. Quite the contrary, it is the forcing of a particular 
application paradigm, that of requiring all applications to be 
client-server based with all intelligence based in the server, that has 
in turn forced Javascript sophistication to increase to accommodate 
complex application logic inside the browser. (Indeed, it is this force 
that has led to HyBi, the abomination whereby browser-based 
applications, instead of being able to simply open a TCP connection, are 
forced to go through an HTTP tunnel to the web server in order to get 
any kind of network connectivity.) Protocols like POP and IMAP are not 
being subsumed into these systems. Rather, the semantics of these 
protocols are being dumbed down, eliminating functionality, in order to 
allow them to fit into the new constrained environment.

There are two obvious drivers of this evolution: First and foremost is 
the continuing lack of end-to-end connectivity in the network. This is 
due to the presence of NATs and assorted firewall nonsense that makes 
non-tunneled applications harder and harder to deploy. But the second 
driving force is the more insidious one: economics. The economics of the 
Internet are currently being driven by big players consolidating the 
network, pushing as much as they can into servers so that they can 
control both the data and the user experience for applications on the 
Internet. This of course is not in the interest of end users, except 
insofar as the "big players" are end users with large economic 
interests. The more centralized the data becomes, the more dependent 
users are on the "big players", the less innovation in applications can 
take place, and the less stable the Internet is as a whole.

This is not a state of affairs in which we need to "identify areas where 
the standardization is unlikely to be relevant in the future, and focus 
our efforts on those areas where our application designs will remain 
impactful." Rather, we need to do what we can with tools we are 
currently developing (the deployment of IPv6, the use of MPTCP and other 
protocols which allow us to route around the damage to the end-to-end 
model) to combat this model and have the Internet remain a distributed 
end-to-end network.

Back to La Mancha. I've been noticing these windmills....

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 21 Mar 2011 21:37:21 -0700

On 3/21/2011 8:48 PM, Pete Resnick wrote:
> I sent this to the IAB a few weeks ago. We haven't had much conversation (they
> responded, but the firehose of stuff before the IETF meeting kept me from
> replying until recently), but I thought you all would be amused.

The degree of disconnect about architecture and protocol issues makes this a bit 
challenging to view with humor.  (It's tempting to counter that that's not 
really true since it is so easy to make fun of the situation, but that's not 
what you meant and it's not what I'd find productive...)

The larger issue I see is that the views being put forward for the talk well 
might be reasonable, with sufficient qualifiers and very careful language, but 
no qualifiers are being offered.  Instead the language asserts universals, and 
these most certainly are not correct.

There could be a rather interesting discussion about these issues, given a 
reasonable mix of people and a reasonable format for exploration and debate. 
The current format is cast more for selling a specific view than for 
understanding pros and cons and tradeoffs.

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Mon, 21 Mar 2011 23:35:44 -0700

>Back to La Mancha. I've been noticing these windmills....

Adapted from draft-iab-ip-model-evolution:

   'Since the Internet Protocol was first published as [IEN028] in 1978,
    IP has provided a network-layer connectivity service to upper-layer
    protocols and applications.  The basic IP service model was
    documented in the original IEN's (and subsequently in the RFC's that
    obsolete them).  However, since the mantra [is] "Everything Over [HTTP]'

It is easier not to "worry about about interoperability of clients 
and servers when the server", thanks to the magic of fog computing, 
"can simply push to the client all the code it needs to be interoperable".

Instead of talking about finding a role in this "post-standardization 
environment" [sic], the IETF might as well shut down the Applications 
Area and create a Web Area.

Regards,
-sm

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Mar 2011 08:53:28 +0200

Hi Dave, 

the abstract cannot obviously cover all aspects of the talk, as you know. 

Jonathan & Harald, who are among the speakers, have good knowledge about the IETF. They have made significant contributions and they had run into a few of the issues we are discussing on this list.

In our writeup http://tools.ietf.org/html/draft-tschofenig-post-standardization-00 we have not only described the positive effects of the trend we are believing to see but expressed also some concerns. There are also cases where the current Web model is not able to compete with native applications. We talk about those as well in the document.  

In any case, we thought that this topic is relevant enough for the IETF community to have a dialog and to hear whether you have a view about the topic as well. As this discussion shows, you obviously do. 

The time could not have been better given the RTCWeb BOF that is also going to happen in Prague. 

Ciao
Hannes

On Mar 22, 2011, at 6:37 AM, Dave CROCKER wrote:

> The degree of disconnect about architecture and protocol issues makes this a bit challenging to view with humor.  (It's tempting to counter that that's not really true since it is so easy to make fun of the situation, but that's not what you meant and it's not what I'd find productive...)
> 
> The larger issue I see is that the views being put forward for the talk well might be reasonable, with sufficient qualifiers and very careful language, but no qualifiers are being offered.  Instead the language asserts universals, and these most certainly are not correct.
> 
> There could be a rather interesting discussion about these issues, given a reasonable mix of people and a reasonable format for exploration and debate. The current format is cast more for selling a specific view than for understanding pros and cons and tradeoffs.
> 
> d/
> -- 
> 
>  Dave Crocker

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 22 Mar 2011 09:24:10 +0200

> Area and create a Web Area.

Two points:

A) A few groups with relevance to the Web have recently been created in
the applications area. 
Examples: OAuth, Websec, hybi

B) You phrase it in a bad way that we talk about this topic. What is
wrong with looking at trends in the industry that some of us are seeing
happening? You can make fun about the way we wrote the document and my
English writing skills.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 22 Mar 2011 07:49:22 +0000

Pete,

Notwithstanding my earlier comments in support of Web/HTTP for some 
applications, I have some sympathy for the sentiments you express here.   It 
does sometimes feel to me that there a technology "capture" taking place by some 
of the big web players (cf. HTML5), and also there's the whole net neutrality 
debate seems to be heating up (again?).

But at heart the web *should* be about decentralization, breaking the 
dependencies on single servers and services, enabling developers to develop 
innovative new applications based on web data.  The web architecture principles 
build on the end-to-end Internet philosophy, and explicitly try to avoid adding 
new control points.  I would say that "big players ... pushing as much as they 
can into servers so that they can control both the data and the user experience" 
is something the web makes possible in some cases by virtue of its lack of 
central coordination.

There are many developers in the web community who are creating innovative 
applications that fit in and around the offerings of the big players.  For just 
one example that happens to spring to mind, see 
http://weblog.clarkparsia.com/2010/05/26/another-reason-semantic-web-kicks-ass/.

The Web is harmed as much by the lack of end-to-end connectivity as any other 
application.  And, yes, I think that HyBi has degenerated into a rather 
unproductive bun-fight, possibly by trying to do too much rather than figuring a 
minimum set of requirements that could unlock a range of new capabilities 
*within* the established web framework.  And yes, the Web isn't right for every 
application (email being a case in point).  But I claim that there are very many 
applications that *can* sit comfortably within the web framework if the design 
is approached in a conforming way.  (And that a lot of design choices in 
application design may be quite arbitrary, and constraining some of those 
choices doesn't greatly limit the range of useful applications that can be created.)

So, while I agree with your exhortation to restore end-to-end connectivity to 
the Internet, I don't think that the Web itself is truly the great bete noir in 
this (other than, by virtue of its widespread use, exacerbating and accelerating 
the depletion of endpoint addresses).

Don't throw out the baby with the bathwater!

#g
--

FWIW, I can think of two simple (to describe) capabilities that would help to 
make the web more widely usable as a application platform:

(a) a *simple* mechanism for pushing asynchronous notifications to a web 
application (browser-based or otherwise).  I had early hopes for HyBi, but have 
somewhat given up.

(b) a well-founded security model to permit controlled relaxation of the 
same-origin restrictions on web applications in browsers.  Many of the current 
proposals I'm aware of seem to lack a coherent security analysis (though, when I 
last looked, HTML5 may be an exception in this regard).  I think this could make 
it easier to separate data storage from applications, opening the way to give 
users back control of their data.

---

From: SM <[email-masked]>
Date: Tue, 22 Mar 2011 01:47:52 -0700

Hi Hannes,
>happening? You can make fun about the way we wrote the document and my

I'll respond to your last point first.  I don't see anything wrong 
with your English writing skills.  I did not even think of that.  If 
I did, I would definitely not make fun about it.  I commented on the 
paragraphs about "The Future of Applications" at 
https://datatracker.ietf.org/meeting/agenda/  When I see terms like 
"post-standardization environment", "forward-looking statements" come 
to mind.  Such terms are also used by people with excellent English 
writing skills.  I read "post-standardization environment" in terms 
of an organization trying to find something to do when its mission is 
obsoleted by events.

I am aware of the work being carried out in OAuth, Websec and Hybi.

There is nothing wrong with discussing about the trends in the 
industry.  The arguments that are being made are, in my opinion, 
similar to those made in RFC 3903.

Regards,
-sm

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 22 Mar 2011 09:49:53 +0100 (CET)

On Mon, 21 Mar 2011, Pete Resnick wrote:

> (they responded, but the firehose of stuff before the IETF meeting kept me 
> from replying until recently), but I thought you all would be amused.

Pete...

+1000 !

:-)

(and I'm happy to be managing an R&D "carrier" which still thinks exactly 
what you wrote).

> technical session at the IAB plenary to be completely unadulterated rubbish. 
> It is by no means the "advancement in the design of web browsers" nor the 
> "widespread availability and growing sophistication of JavaScript 
> interpreters in browsers" that has changed the architecture of applications. 
> Quite the contrary, it is the forcing of a particular application paradigm, 
> that of requiring all applications to be client-server based with all 
> intelligence based in the server, that has in turn forced Javascript 
> sophistication to increase to accommodate complex application logic inside 
> the browser. (Indeed, it is this force that has led to HyBi, the abomination 
> whereby browser-based applications, instead of being able to simply open a 
> TCP connection, are forced to go through an HTTP tunnel to the web server in 
> order to get any kind of network connectivity.) Protocols like POP and IMAP 
> are not being subsumed into these systems. Rather, the semantics of these 
> protocols are being dumbed down, eliminating functionality, in order to allow 
> them to fit into the new constrained environment.
>
> There are two obvious drivers of this evolution: First and foremost is the 
> continuing lack of end-to-end connectivity in the network. This is due to the 
> presence of NATs and assorted firewall nonsense that makes non-tunneled 
> applications harder and harder to deploy. But the second driving force is the 
> more insidious one: economics. The economics of the Internet are currently 
> being driven by big players consolidating the network, pushing as much as 
> they can into servers so that they can control both the data and the user 
> experience for applications on the Internet. This of course is not in the 
> interest of end users, except insofar as the "big players" are end users with 
> large economic interests. The more centralized the data becomes, the more 
> dependent users are on the "big players", the less innovation in applications 
> can take place, and the less stable the Internet is as a whole.
>
> This is not a state of affairs in which we need to "identify areas where the 
> standardization is unlikely to be relevant in the future, and focus our 
> efforts on those areas where our application designs will remain impactful." 
> Rather, we need to do what we can with tools we are currently developing (the 
> deployment of IPv6, the use of MPTCP and other protocols which allow us to 
> route around the damage to the end-to-end model) to combat this model and 
> have the Internet remain a distributed end-to-end network.
>

---

From: Dave Cridland <[email-masked]>
Date: Tue, 22 Mar 2011 09:01:15 +0000

On Tue Mar 22 07:49:22 2011, Graham Klyne wrote:
> FWIW, I can think of two simple (to describe) capabilities that  
> would help to make the web more widely usable as a application  
> platform:
> 
> (a) a *simple* mechanism for pushing asynchronous notifications to  
> a web application (browser-based or otherwise).  I had early hopes  
> for HyBi, but have somewhat given up.
> 
> 
As have many.

Another option would be to use XMPP directly in the browser - not  
some hacked down variant communicating only with the webserver's  
approved domain, but full XMPP. This has different properties  
entirely from WebSockets, but those properties give rise to some  
interesting concepts.

> (b) a well-founded security model to permit controlled relaxation  
> of the same-origin restrictions on web applications in browsers.   
> Many of the current proposals I'm aware of seem to lack a coherent  
> security analysis (though, when I last looked, HTML5 may be an  
> exception in this regard).  I think this could make it easier to  
> separate data storage from applications, opening the way to give  

Right - and full XMPP would also allow this, and single-identity, and  
your own [choice of] server/provider. In fact, it'd even allow a  
decoupling between the application and its UI, which'd make many of  
us happier.

Oddly, I'd have thought this would be embraced both by the "big  
players" and end-users with concerns about them.

I would love to see a world where the Web does what it's good at -  
that is, delivering static content, including application code and UI  
content - and protocols such as XMPP do what they're good at - that  
is, providing dynamic data between known federated entities.

Sadly, I suspect that there is sufficient inertia involved that  
maintaining the emerging status quo of HTTP for everything will prove  
impossible to break.

Dave.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Mar 2011 11:12:16 +0200

On Mar 22, 2011, at 10:47 AM, SM wrote:

> I read "post-standardization environment" in terms of an organization trying to find something to do when its mission is obsoleted by events.

We had to find some term to describe this paradigm and concept.  

When you look through the broader standardization landscape then you for sure will notice that there are architectural differences in where groups see the need for standards and interoperability and what degree of interoperability is necessary. For example, compare a 3GPP IMS architecture, the IETF SIP architecture, and the RTCWeb-based architecture. I hope you recognize differences - differences that go beyond the protocol level. 

I assume that you do not just randomly standardize something and wait for someone else to pick it up (although researchers like to explore the entire solution space and that's fine as well).

While it is difficult to provide suggestions regarding the approach a protocol designer should take there are various side-effects of any decision you make. When we interviewed folks in the Web community (from inside the IETF as well as outside) it was not so clear where the limits for the Web (HTML/JavaScript) model are. In any case they are changing rapidly. We hope to get more feedback from those who have been exposed to some of the mentioned Web technologies. Are you this Web person?

Ciao
Hannes

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Mar 2011 20:46:04 +1100

Since everyone is putting their .02 in...

I'm very glad that we have this plenary topic, precisely because it's getting this kind of response. I've been concerned about the evolution of the browser for some time, for a variety of reasons (some already stated by others):

  - General loss of high-level semantics in favour of low-level functionality (consider: HTTP and WebSockets) because browser vendors want to reduce QA exposure and "get out of the way"

  - Protocols are defined by libraries, not as standards. Thus it's easy to innovate, but hard to build on others' work (e.g., as a middlebox). 

  - Corresponding loss of unintended reuse

  - From what I've seen, most libraries tend to ignore aspects of security, internationalisation, dealing with latency, dealing with disconnectedness, and so forth. This leaves users with awkward choices.

  - Comparative weight of a "full" Web stack including JavaScript, HTML5, CSS and more to implement a functional application (I'd encourage people to read the HTML5 specification if they haven't already). 

  - Lock-in of data

  - Movement from declarative markup to imperative APIs for all Web functionality 

... and so on. What's important for IETF folk to understand is that this *is* happening, and it's going to be very big. The list above is negative, but there are positives too; what I think we should focus on is minimising the negative impacts of this platform, and maximising the positive (to shamelessly borrow from Bill Clinton last week at ICANN).

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Scott Brim <[email-masked]>
Date: Tue, 22 Mar 2011 09:41:05 -0400

Pete: Yes, amusing.  I want to digress on one thing you said ...

On Mon, Mar 21, 2011 at 23:48, Pete Resnick <[email-masked]> wrote:
> continuing lack of end-to-end connectivity in the network. This is due to
> the presence of NATs and assorted firewall nonsense that makes non-tunneled
> applications harder and harder to deploy. But the second driving force is
> the more insidious one: economics. The economics of the Internet are
> currently being driven by big players consolidating the network, pushing as
> much as they can into servers so that they can control both the data and the
> user experience for applications on the Internet. This of course is not in
> the interest of end users, except insofar as the "big players" are end users
> with large economic interests. The more centralized the data becomes, the
> more dependent users are on the "big players", the less innovation in
> applications can take place, and the less stable the Internet is as a whole.

I think the causality is turned around several times in these sentences.

First, NATs did not force people into client-server mode.  If people
had had a strong desire for end-to-end transparency, we would have
more of it.  NATs started appearing and they didn't cut off anything
people saw as vital.  Some apps (e.g. FTP and Skype) adapted.  It is
now hard to preserve peer-to-peer, and get away from client-server,
partly because of NATs but mainly because the vast majority of people
find client-server to be convenient.  They like services.  If there
was more demand for transparency you would see more of it.

Second, yes economics, and yes the big boys are pushing to control
more, but that doesn't mean it is not in the interest of end users.
They like services.

So yes, architecturally we must fight to preserve peer-to-peer, but we
are not doing so because zillions of end users want us to; we are
doing so because we know better than they do what's good for them (and
the Internet).

Finally I don't see how having data centralized, or data flows between
fewer src/dst pairs, lowers stability of the Internet.

Scott

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 22 Mar 2011 16:10:24 -0400

+1 to this -- especially the points about the views being put forward 
being reasonable, but not all-encompassing.

Leslie.

Dave CROCKER wrote:
> The degree of disconnect about architecture and protocol issues makes 
> this a bit challenging to view with humor.  (It's tempting to counter 
> that that's not really true since it is so easy to make fun of the 
> situation, but that's not what you meant and it's not what I'd find 
> productive...)
> 
> The larger issue I see is that the views being put forward for the talk 
> well might be reasonable, with sufficient qualifiers and very careful 
> language, but no qualifiers are being offered.  Instead the language 
> asserts universals, and these most certainly are not correct.
> 
> There could be a rather interesting discussion about these issues, given 
> a reasonable mix of people and a reasonable format for exploration and 
> debate. The current format is cast more for selling a specific view than 
> for understanding pros and cons and tradeoffs.
> 
> d/

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 22 Mar 2011 16:10:36 -0400

So, this is the IETF-port-80 tech plenary?  Can't wait for hosts2-ns in 
Quebec City ;-)

IMO, the approach outlined in the plenary plan makes (and, ultimately, 
would entrench) an unwarranted distinction between clients and servers 
as devices on the Internet.  Clients do IMAP to get mail, but SMTP is an 
Application protocol for inter-server mail transfer.  The Internet has 
actually flourished _because_ any client could be a server.  In that 
vein -- not all transaction models are supported in HTTP, so overlaying 
all applications could be expensive and ineffective.

So, while I don't doubt there will be more of this type of HTTP-embedded 
application work,  IMO it should not be conflated with the totality of 
Internet application/infrastructure standardization.

In general, the IETF has done application _transport_ protocols (HTTP, 
and XMPP for that matter), and infrastructure (naming -- URLs, URNs 
etc).    This is particularly evident in the split of HTML off to the 
W3C - which made sense, because the expertise required was different, 
the focus much more on the end-user requirements than the network 
realities.  (And, HTTP remains at the IETF because its revisions benefit 
from the IETF's much broader understanding and expertise of transport 
issues is the most important aspect to bring to bear on it).  So, making 
this a call to action around the IETF's application standardization 
activity seems a little incomplete.

If this rises to the level of the IAB's attention, I'd like to think the 
IAB would manage to have that broader perspective -- not necessarily of 
application protocols or their structure, but the fact that the Internet 
of the future is going to be a very diverse place (still) and is not 
just about clients and servers as we commonly conceive them (notebooks, 
desktops, etc).

In November, I had the opportunity to participate in some discussions 
about the shape of the future Internet, in terms of devices:  i.e., 
handhelds and other untethered devices.  The current and ongoing 
constraints of those devices make for an interesting landscape for the 
Internet of the future.  Ted alluded to some of them in his remarks in 
this thread.  I wrote up some of my perspective on the landscape, in 
terms of untethered devices and the implications of/for RFCs 1122/1123, 
here:  http://isoc.org/wp/ietfjournal/?p=2185#more-2185  .  I think 
those documents represent pretty sound "first principles", and concluded 
with:

"Diversity and openness remain critical in Internet deployment, in order 
to continue to foster innovation. 1122/23 stress the importance of 
recognizing that individual networks would be set up and operated 
according to local design choices. The open Internetwork application 
framework is what has permitted the creation of novel applications 
without requiring permission from network operators or device 
manufacturers for deployment. The World Wide Web was one such idea that 
took hold like wildfire. Time and again, users and usage of Internet 
have laid the groundwork for the Internet’s evolution, not some master 
control. It’s important to retain the ability to support that kind of 
innovation and open experience, as provided for in the hosts 
requirements in 1122/23. In that light, the notion of an open standard 
“split node” model, with individual users establishing and controlling 
preferences for policies, would allow more growth and innovation than, 
for instance, “one size fits all” policy assumptions implemented as 
network operator private controls.

In the end, then, it’s clear the future Internet will support many users 
and uses based on untethered devices, and thus feature hosts that exceed 
the expectations of 1122/23. But the framework in those documents is 
sound: provide a set of requirements for interoperation at the transport 
and application levels, and unfettered innovation will follow. Time will 
tell whether the requirements of hosts are updated to accommodate the 
practical realities of power and bandwidth constraints understood with 
untethered devices, or whether the “host” will become some tethered 
server supporting multiple roaming devices, for example. The only wrong 
choice is no choice at all."

which seems applicable here.

Leslie.

--

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Mar 2011 08:13:06 +1100

Just to this point --

On 23/03/2011, at 7:10 AM, Leslie Daigle wrote:

>  In that vein -- not all transaction models are supported in HTTP, so overlaying all applications could be expensive and ineffective.

it's important to understand that the folks pushing browser-as-a-platform see WebSockets (from our very own HYBI WG) the answer to this.

Regards,

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Mar 2011 15:19:15 -0700

I note that all of the messages on this thread have gone to apps-discuss only, not to [email-masked]. I propose that if those with strong feelings about the topic description want to see it addressed sooner rather than later, talking to the IAB at the same time as the Apps Area might be more effective.

--Paul Hoffman

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 22 Mar 2011 23:45:45 +0100 (CET)

On Tue, 22 Mar 2011, Paul Hoffman wrote:

> I note that all of the messages on this thread have gone to apps-discuss 
> only, not to [email-masked]. I propose that if those with strong feelings 
> about the topic description want to see it addressed sooner rather than 
> later, talking to the IAB at the same time as the Apps Area might be 
> more effective.

True... but I would suggest a full digest of what has been said until now 
to be packed up for the IAB; they all give a view (or another less 
"spamming" version to convey the information to IAB, for example).

thanks for pointing this, Paul!

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Mar 2011 17:46:02 -0500

> application protocols, such as specialized mailbox access.

HTTP _and_ JavaScript is what the announcement asserts.  This is
another way of saying that applications are now downloaded as
necessary.  Anything identifiable as an application protocol becomes
an ephemeral incident.

I don't quite buy it.  Even in the age of AJAX people speak of APIs,
where the APIs are all based on HTTP and some document representation
(XML, XHTML, JSON, ...).  APIs are -roughly, if not exactly- another
name for "protocol" in this context.

Perhaps we could speak of a large-scale replacement of many apps with
a mixture of apps that define application protocols/APIs, apps that
define neither, and apps that define protocols/APIs for some parts and
none for others, plus a thin-client model.  That is what I think is
happening.  Whether a protocol or an API are defined will generally
depend on how much developers can rely on browsers and JavaScript.
Browser-based UIs are nice, but not enough, which leads at least some
applications to grow stable protocols or APIs.

No, TCP is not now just a layer with which to slowdown HTTP.  There
will continue to be non-HTTP-based applications for a long time to
come.

> incompatible application protocols, making for rather remarkable burdens on

Certainly if all users were happy to live with browser-based apps
only, where the application is always delivered by their corresponding
service providers, then yes, we'd have an explosion of unstable and/or
undocumented (and therefore non-interoperable) protocols.

In practice there's a limit to how browser-bound users can be.  Mobile
devices in particular are probably a big driver of stable HTTP-based
protocols/APIs, since it's oh so much lighter weight to speak HTTP
without having to have a browser, a DOM, and a JavaScript engine.  But
there's also a lot of demand from users for third party apps, and
pressure from 3rd party developers for the same, and it may well be
that this will be enough in many cases for the provider to agree to
provide stable interfaces, even if later on mobile devices were to
gain so much power and functionality that browser-based UIs could
reasonably rule the day.  Besides, even if 90% of the time
browser-based UIs sufficed, there will always be some cases where they
don't (mash-ups, automation, convenience, aesthetics,  ...).

Only by ignoring the needs of users do we get to have a pure
thin-client model of the world filled with unstable/undocumented
protocols.  Moreover, there is some degree to which we should be
concerned that we're being encouraged (not necessarily by those giving
the presentation in question) to accept such a model primarily because
this is in the [apparent] self-interest of service providers.

In other words: we probably need interoperable protocols/APIs now more
than ever.  They may simply take a different form than the non-HTTP
apps' of yesteryear, but that's it.

Nico
--

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 22 Mar 2011 19:12:22 -0400

I am glad to see the plenary has already inspired some good discussion before it has even taken place. I only worry that the more dissent is vented in this thread, the more the actually plenary will be a let-down, but...

The purpose of this plenary is to raise awareness in the broader community of new areas for IETF work and for coordination with the W3C. Some of that work has already been chartered, some will be discussed in BoF form in Prague, and some has yet to be nailed down into engineering problems. The most immediate trigger for the plenary is the RTC-Web BoF, and the choice of panelists reflects that focus, but the IETF has plenty of other interactions in efforts like HyBi and the broader emergence of application designs building on top of javascript and HTML5.  I believe there is value in identifying the commonalities in these trends in applications development and asking where the IETF can help to make them better. Websockets will exist, in one form of another, the question is whether they will have the benefit of IETF review, of our understanding of transports, of NATs, of security, of all the things that make sockets hard. By addressing itself to these emerging application architectures, the IETF can find new areas of relevance and potentially attract new participants and ideas to our community.

The purpose of this plenary is not to say that this web architecture should be the exclusive focus of the Apps Area, nor to delineate some specific set of work that should be replaced by something else. That's why, in our plan for this, we didn't adopt a point/counterpoint format - I don't really think web applications and standalone applications are mutually exclusive, both will certainly exist in their own areas of applicability. As Hannes has mentioned already, a few IAB members put out a draft on this subject which is probably a better place to look for architectural thinking about this plenary than the blurb in the agenda. Note well, however, that document is not a consensus statement of the IAB. What the panelists will say is up to them, and should not be understood as a position of the IAB either. The IAB interest here is simply to shine a spotlight where we think attention is warranted - if anything, this thread has shown the interest of the community in this subject. We do hope that the plenary will help people to see this new work as a space where the IETF can make a meaningful contribution and not, say, as "an abomination." 

If, in light of all this, people feel that emergency course-correction is required in order for this plenary to be useful to the community, don't hesitate to raise any specific ideas with me or the IAB as a whole, and we'll see what we can do in our remaining couple days here.

Jon Peterson
NeuStar, Inc.

---

From: SM <[email-masked]>
Date: Tue, 22 Mar 2011 16:22:22 -0700

Hi Hannes,
>We had to find some term to describe this paradigm and concept.

Ok.

>When you look through the broader standardization landscape then you 
>for sure will notice that there are architectural differences in 
>where groups see the need for standards and interoperability and 
>what degree of interoperability is necessary. For example, compare a 
>3GPP IMS architecture, the IETF SIP architecture, and the 
>RTCWeb-based architecture. I hope you recognize differences - 
>differences that go beyond the protocol level.

One key point here is the "degree of interoperability".  That might 
sum up the various positions we have seen in this discussion.

>While it is difficult to provide suggestions regarding the approach 
>a protocol designer should take there are various side-effects of 
>any decision you make. When we interviewed folks in the Web 
>community (from inside the IETF as well as outside) it was not so 
>clear where the limits for the Web (HTML/JavaScript) model are. In 
>any case they are changing rapidly. We hope to get more feedback 
>from those who have been exposed to some of the mentioned Web 
>technologies. Are you this Web person?

I prefer not to answer yes to being a Web person. :-)

I agree that the limits are changing rapidly.  Mark commented on the 
evolution of the browser and lock-in of data [1].  As we move from 
protocol to service, the code is the least of our concerns.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02396.html

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 23 Mar 2011 14:58:49 +0100

Somewhat relevant and cautionary, for this thread:

    Internet or Splinternet?

    <http://www.stormdriver.com/blog/internet-or-splinternet/>

d/
-- 

   Dave Crocker

---

From: Nico Williams <[email-masked]>
Date: Wed, 23 Mar 2011 13:34:29 -0500

On Tue, Mar 22, 2011 at 6:12 PM, Peterson, Jon <[email-masked]> wrote:
>  We do hope that the plenary will help people to see this new work as a space where the IETF can make a meaningful contribution and not, say, as "an abomination."
>

"Emergency course-correction"?  No, no such thing is needed.  The
authors' dream(?) of protocol-less-ness may be over-the-top
simplification, but they should be allowed to share their viewpoint.

I believe that the driver for protocols or "APIs" is not the IETF, not
the Internet community, but the community of users and third party
developers that grows around successful services, as well as
competition.  Service providers may wish to retain full control over
their protocols -whether out of a desire to be unconstrained in their
evolution or for other reasons does not matter- but I believe that is
wishful thinking.  It is market forces, not the IETF, that will force
a fair measure of protocol/API stability/standardization (de facto or
de jure); market forces are likely to be overwhelming in the long run.
 Of course, it's always possible that some providers will succeed in
creating popular, non-interoperable services, and since they are
certainly free to try for that, therefore some will try.

Cheers,

Nico
--

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Mar 2011 21:22:02 +0100

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.

Gruesse, Carsten

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 23 Mar 2011 14:13:05 -0700

> Help AJAX get better, get more secure.  Get more standards-based, more

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: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Mar 2011 14:33:46 -0700

> So, AJAX appears to be the new NAT.

So, that's a very good sound bite, but not a very accurate analysis.
There are two pieces that have been pointed out it a variety of ways
which you seem to miss:

 Once a node can
> demonstrated nicely in AJAX.

The first is that AJAX is a client-server model which ensure that only
one of the two nodes can control the code on *both* communicating
peers.  That has a set of impacts that has been alluded to already in
this discussion, and it tends to concentrate power and development
effort.  You could say that enables innovation, as it creates a pool
of libraries and methods that can be re-used by others.  You could say
it stifles it, because that concentration ignores other fertile
ground.

It's that second point that is really at issue for the web as a
platform for application delivery.  Those issues don't relate as
strongly to the downloadable code issue as the base protocol having
been built for synchronous transfer of relatively small, cachable,
discrete objects; it's changed, of course, but the ability to do
reasonable things on that basis has its limits.

The RTCWeb effort that will be discussed in the upcoming BoF has been
trotted out as an example of the beauty of this approach.  In fact,
it's a great example of the tension.  Some aspects of the real-time
communication it means to enable can be mediated by web servers fairly
easily (the rendezvous and, to some extent, the negotiation).  Other
aspects, like the audio and video streams passed among peers, still
make much more sense delivered as RTP or using RTP-like flows.   (NB:
my personal opinion; the eventual WG will have to draw the lines
itself).

In other words, there is a class of client-server protocols for which
downloadable code is a good tool.  There are other protocol
requirements that are, bluntly, ill-met by that.  We want innovation
to proceed in both classes of problem. Which means enabling the first
class *while acknowledging its limits*.

Just my two cents, of course.

Ted Hardie

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 23 Mar 2011 17:48:50 -0400

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.

Jon Peterson
NeuStar, Inc.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 23 Mar 2011 15:41:11 -0700

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.

>>> designing protocols that ignored NATs and then didn't win. I was hoping
>>> we would never do that again.)
>>>
>>> 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
>>> 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 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: [email-masked] Professional
>> email: [email-masked] Blog: http://blog.marc.petit-huguenin.org
>> _______________________________________________ apps-discuss mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Mar 2011 21:09:48 -0600

> more, but that doesn't mean it is not in the interest of end users.

Scott, I think there is a great deal of truth in what you say. The big
services have become big in large measure because most people seem to
prefer identifiable services. Perhaps it's the herd instinct or the
human inability to hold too many things in mind at once or the
simplicity of signing up for something and letting someone else handle
the details. Whatever the reason, most people don't want to run their
own services -- it's much easier to visit a website, and tell people
that you're "on", a popular email or IM or blogging or microblogging or
voice or video service than it is to install and maintain postfix or
Prosody or WordPress or laconica or Asterisk or Yate on the server side
plus Thunderbird or Pidgin or Jitsi (etc.) on the client side (let alone
the whole stack of OS and DNS and databases and registered domains and
certificates and all the rest).

So yes, services are easy and popular with end users. As a result, the
companies that offer those services often become large and even dominant
on the 'net. At that point some of the dynamics that Pete mentioned come
into play, but I don't think they are the root cause.

Peter

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 23 Mar 2011 23:45:32 -0400

I hope we can have a real discussion in Prague, without too much
grandstanding.

See you all too soon.

Scott

On Wed, Mar 23, 2011 at 23:09, Peter Saint-Andre <[email-masked]> wrote:

> the

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Mar 2011 14:05:09 +0200

On Mar 22, 2011, at 11:01 AM, Dave Cridland wrote:

> I would love to see a world where the Web does what it's good at - that is, delivering static content, including application code and UI content - and protocols such as XMPP do what they're good at - that is, providing dynamic data between known federated entities.

How likely do you think is this going to happen?

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Mar 2011 14:35:55 +0000

On Thu Mar 24 12:05:09 2011, Hannes Tschofenig wrote:
> > I would love to see a world where the Web does what it's good at  
> - that is, delivering static content, including application code  
> and UI content - and protocols such as XMPP do what they're good at  
> - that is, providing dynamic data between known federated entities.
> 

Sadly, probably very unlikely. Who's going to provide the kind of  
leadership we'd need to have a coherent architecture for the  
internet, instead of one that emerges driven by a few service  
providers?

Dave.

---

From: Scott Brim <[email-masked]>
Date: Thu, 24 Mar 2011 10:43:01 -0400

On Thu, Mar 24, 2011 at 10:35, Dave Cridland <[email-masked]> wrote:
>> > I would love to see a world where the Web does what it's good at - that
>> > is, delivering static content, including application code and UI content -
>> > and protocols such as XMPP do what they're good at - that is, providing
>> > dynamic data between known federated entities.
>>
> Sadly, probably very unlikely. Who's going to provide the kind of leadership
> we'd need to have a coherent architecture for the internet, instead of one
> that emerges driven by a few service providers?
>
> Dave.

I believe it was in Munich, oh so many years ago, that Dave Clark said
"architect the inevitable".  Yes we preserve the model of peer-to-peer
symmetric communications.  We know it and other principles are
fundamental necessities for future adaptability.  At the same time we
engineer all sorts of stuff that is just subsets, that does not follow
our fundamental principles completely, because it meets users' needs
right now.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 24 Mar 2011 14:52:39 +0000

On 3/24/11 3:45 AM, Scott Brim wrote:
> On Wed, Mar 23, 2011 at 23:09, Peter Saint-Andre <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

I think this is revisionist history. Let's separate out a couple of things:

1. Most people came to the Internet via the web. They never had much 
exposure to, let alone use for, other facilities provided. So they think 
about things through a web lens. NATs coming in didn't *have* to force 
people into client-server mode; it simply kept them there and kept them 
from seeing the other possibilities.

2. Don't confuse market forces for what people actually desire. People 
don't know what they want or desire until they understand what is 
available. If we only look to what people find desirable or what they 
view as vital *now*, nothing new is ever created. Did people desire 
forms of communication other than what AT&T provided to them with POTS? 
And really, I challenge you to come up with some evidence that people 
find client-server to be convenient. I hear people complain about their 
web-app experiences all of the time. Do people actually want 
client-server, or do they simply not understand what they could have?

3. We have been spending literally years coming up with ways to work 
through server-based services (and through NATs) to provide people with 
peer-to-peer services. Indeed, several of the technologies that seem to 
be driving this discussion (WebSockets, RTCWEB, HYBI) are in response to 
a stated need for Javascript applications to talk peer-to-peer, 
bypassing the client-server model you say people desire. That seems to 
go against the position that people aren't interested in peer-to-peer 
applications. If so, we're just talking about delivery model and 
underlying protocols, not people's desires.

4. Finally, be careful about layer violations. Whatever people want, it 
is likely above layer 7. Even if we could establish that people like the 
idea of using a server-based model for their interactions (of which I am 
not convinced), that doesn't mean that the underlying network ought to 
reflect that architecture. In fact, it's probably a really bad idea. 
People liked (still like) the idea of point-to-point connections for 
their telephones. That doesn't mean that we should devote ourselves to 
moving away from packet switching. When we bump into circuit switching, 
we tunnel through it or route around it. Similar principles ought to 
apply here.

>     the details.

I think Peter is on to something. It is I think more about the herd 
instinct, if not a more hierarchical instinct. We don't seem to like 
anarchy. We like someone "in charge" to take care of things. However:

>     Whatever the reason, most people don't want to run their

People do seem fully capable to grasp "Here is my phone number, you can 
reach me here" and do at least that particular kind of peer-to-peer 
communication. There is no reason that IM or email or blogging *have* to 
be a service; it's a remnant of being pre-disposed to client-server 
models (including, BTW, DNS).

>     into play, but I don't think they are the root cause.

Chicken/egg. There's great incentive for those large entities to 
maintain the model that is making them money. I'm not convinced it's 
user wishes that keep things the way they are, anymore than I think it's 
user wishes that keep certain things on television. You can get people 
to watch all sorts of nonsense TV, but that doesn't (in and of itself) 
mean that they actually aspire to watch it.

> I hope we can have a real discussion in Prague, without too much 

It's going to be difficult. I can say for myself that I've been pushing 
for a deeper discussion (and getting it in many places), but the "death 
of application protocols predicted" tone of the abstract was a bit of 
grandstanding itself, IMO. Not too conducive to rational conversation.

pr

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Mar 2011 15:36:17 +0000

> our fundamental principles completely, because it meets users' needs

There is an immense distinction between pragmatically bending rules  
in the short term whilst clearly maintaining a single overriding  
architectural vision to aspire to, and throwing away years of  
architectural choices because a handful of very large near-monopolies  
would find it more convenient if they had total control over every  
aspect of the user's experience.

On the subject of the thriving ecosystem of third-party apps clinging  
on for dear life to these rumbling giants hoping to compete by  
pretending that an "API" under the sole control of a single entity  
is, somehow, equivalent to a viable open standard - as Hannes et al  
are trying to persuade us - there is some interesting reading which  
was kindly produced a couple of weeks ago:

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c82cd59c7a87216a?pli=1

Anyone present who doesn't choke at the "Twitter is a network" line  
should really wonder what they're doing here.

Dave.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 24 Mar 2011 16:47:38 +0100

On 3/24/2011 3:52 PM, Pete Resnick wrote:
> 1. Most people came to the Internet via the web. They never had much exposure
> to, let alone use for, other facilities provided. So they think about things
> through a web lens. NATs coming in didn't *have* to force people into
> client-server mode; it simply kept them there and kept them from seeing the
> other possibilities.

I'll suggest that NAT's are irrelevant to the choice of client/server vs. 
peer-to-peer.  I used to assume that peer-to-peer meant "direct" exchange 
between peers but it was pointed out to me that it merely refers to either being 
able to initiate an exchange.  Witness instant messaging.

That IM and such services are /mediated/ means that below the /logically/ direct 
exchange there is a relaying service.  This is the same as pretending that TCP 
is "direct" in spite of having the layer below mediate.

The appeal of client/server is simplicity.  Distributed architecture are more 
difficult to design, build, debug and operate.

Vendors prefer stovepipe solutions because it improves the vendor's control and 
it makes their life simpler.  Venders do not typically engage in open and 
distributed systems because they like them.  They engage in them due to market 
forces.

DEC, IBM and Microsoft gave up their proprietary network protocols only when it 
was clear they had no choice.  At that, vendors still try to add proprietary 
tweaks with the (sometimes valid) claimes of improved functionality, but also 
with the awareness that it buys them back some user lock-in.

> 2. Don't confuse market forces for what people actually desire. People don't
> know what they want or desire until they understand what is available. If we

+1

> 4. Finally, be careful about layer violations. Whatever people want, it is
> likely above layer 7.

Or, rather, within it.  Layer 7 is increasingly looking as if it might have 7 
sub-layers...

>>     own services -- it's much easier to visit a website, and tell people
...
> People do seem fully capable to grasp "Here is my phone number, you can reach me
> here" and do at least that particular kind of peer-to-peer communication. There
> is no reason that IM or email or blogging *have* to be a service; it's a remnant
> of being pre-disposed to client-server models (including, BTW, DNS).

This is almost certainly not correct.  There are operational details required 
for these things to be useful.  Someone has to do that work.  It takes effort 
and skill.

An indicator of market maturation is that end users can, do and even must 
offload much of that effort and skill to others called experts and/or providers.

The critical questions are

      1) Do they have a reasonable choice of who they can offload to?
         (competition)

      2) Can the user switch to a new service easily?
         (vs. lock-in)

      3) Is there reasonable interoperability among the providers?
         (interconnect)

      4) Is there reasonable interoperability among the users.
         (reachability and data exchange.)

> Chicken/egg. There's great incentive for those large entities to maintain the
> model that is making them money. I'm not convinced it's user wishes that keep
> things the way they are,

+1

>> I hope we can have a real discussion in Prague, without too much grandstanding.
>
> It's going to be difficult. I can say for myself that I've been pushing for a
> deeper discussion (and getting it in many places), but the "death of application
> protocols predicted" tone of the abstract was a bit of grandstanding itself,
> IMO. Not too conducive to rational conversation.

+1

It is also discouraging to see narrow concerns being, instead, interpreted as 
broad rejections.

d/
-- 

   Dave Crocker

---

From: "Lyndon Nerenberg (VE6BBM/VE7TFX)" <[email-masked]>
Date: Thu, 24 Mar 2011 08:14:55 -0800

> should really wonder what they're doing here.

I don't know ... it seems to me the context meant 'social network'.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Mar 2011 16:23:03 +0000

> I don't know ... it seems to me the context meant 'social network'.
Perhaps I'm getting over-jaded.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Mar 2011 10:49:54 -0600

On 3/24/11 8:52 AM, Pete Resnick wrote:
> anarchy. 

Speak for yourself. ;-)

> We like someone "in charge" to take care of things. 

Up to a point. Humans are complicated creatures. We like hierarchy and
centralization up to a point. When we feel that those "above" us are
getting uppity and corrupt and abusive, we just might turn to something
less hierarchical and centralized. Given recent events in certain
countries, where those high up in the societal stack decided to simply
turn off Internet access for the rebellious rabble, I rather think we
might see increasing demand for technologies that route around
centralized service providers (and even things like DNS) as damage.

Peter

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Mar 2011 15:26:41 -0500

On Thu, Mar 24, 2011 at 9:52 AM, Pete Resnick <[email-masked]> wrote:
> communication. There is no reason that IM or email or blogging *have* to be
> a service; it's a remnant of being pre-disposed to client-server models
> (including, BTW, DNS).

"Here's my phone number, call me" is not really peer-to-peer.  "Here's
my address, drop by" is.  The former relies on quite a bit of
infrastructure (all the more so when the devices are mobile), but the
latter could work even without roads, streets, etcetera (though
addresses might have to be in the form of coordinates, but don't
forget that GPS is also infrastructure).  However, the phone system's
infrastructure is an afterthought to the user, as you demonstrate :)
The same is true of the Internet, but its engineers are aware of the
infrastructure, giving us a different viewpoint than the user's.

Looked at that way, what's so strange about NAT and SIP and XMPP?
Infrastructure mediated peer-to-peer...  seems perfectly natural to
me.  Is infrastructure really avoidable?  Without infrastructure we're
almost necessarily limited to peer-to-peer communications over a small
area: the range of voice, of available travel technologies, of our
peer-to-peer electromagnetic spectrum (further limited by device power
capacity).  Or is it the type of infrastructure that bothers some
people?  DNS is OK but "servers" are not??

I see complaints about the end of the end-to-end model implied by thin
clients.  But I don't think that's a forgone conclusion.  End-to-end
_security_ is the key at any rate (or maybe that's just me looking at
things from a security point of view, or maybe I've been conditioned
by HTTP to accept that the "network" does weird things, or...).

> It's going to be difficult. I can say for myself that I've been pushing for
> a deeper discussion (and getting it in many places), but the "death of
> application protocols predicted" tone of the abstract was a bit of

The Internet is as organic as it's not.  I see this as yet another
step in organic development.  Some guidance may be needed to find and
avert pitfalls before hitting them (again or for the first time), but
that's as far as we can go.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Mar 2011 07:41:17 +0100

Dave Cridland wrote:

>> (a) a *simple* mechanism for pushing asynchronous notifications to  a 
>> web application (browser-based or otherwise).  I had early hopes  for 
>> HyBi, but have somewhat given up.
>
> As have many.

While I understand community frustration about HYBI WG discussions, I 
think people really need to look now at the latest protocol spec. The 
document has been improved substantially and I think it is actually 
implementable at this point in time.

> entirely from WebSockets, but those properties give rise to some  

I would also like XMPP to be used directly by browsers, but if this 
doesn't happen, I think something close enough to the current HYBI 
protocol is going to be good enough.

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 25 Mar 2011 09:56:51 +0100

On 3/25/11 7:41 AM, Alexey Melnikov wrote:
>>> >>  (a) a*simple*  mechanism for pushing asynchronous notifications to  a
while I agree that as all the things in this world,
the WebSocket protocol could have been designed differently
and I understand that has been challenging and some time also 
frustrating for people to follow the intensive
and long mail discussion,
I do think (but I am biased here) in HyBi we (at IETF) have done, and we 
are still doing, an incredible effort to merge
different cultures or at least make them to work together in a 
productive way

the last version 06 has improved a lot: ( 
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 )
and there are already a lot of implementations of 06 draft (from both 
sides browsers and web severs)
and more are under development and will be announced soon.
We will try to give an overview of the situation at the upcoming HyBi 
session

of course there are still open issues that need to be discussed,
and need to reach consensus ...  but are few and almost all of them are 
to improve (simplify) something

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Graham Klyne <[email-masked]>
Date: Fri, 25 Mar 2011 10:21:49 +0000

> implementable at this point in time.

A fair point ... I really should go back and look again.

But, for context, my idea of *simple* here is a notification model that *could* 
be implemented today for browsers using Javascript-over-HTTP, and subsequently 
migrated to a more robust, native implementation in browsers.

(FWIW, I did a little development around this idea a few years ago: 
http://code.google.com/p/webbrick-events/, esp 
http://code.google.com/p/webbrick-events/wiki/EventModel.  My implementation 
uses a form of HTTP long-polling, but it was always my hope to more this to a 
more widely supported substrate.)

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Fri, 25 Mar 2011 10:10:23 +0000

> http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c82cd59c7a87216a?pli=1 

I assume you refer to:

"Twitter is a network, and its network effects are driven by users seeing and
contributing to the network’s conversations."

> should really wonder what they're doing here.

There are many valid uses for the term "network":

- The Internet is a communication network
- The Web is a network of documents (and more...)
- Life is driven by biochemical signalling networks
- Biological ecosystems are resource distribution networks
- Railways are transport networks
- Communities of people form social networks
- etc.

And the great insight (surprise?) is that many of these networks share 
properties on common when viewed in a sufficiently abstract light.  Cf. [1], 
[2], etc.

And I people who are doing practical work that spans these fields; e.g. related 
to http://webscience.org/webscience.html to name just one example.

So within this, I think there is a valid position that Twitter is *a* network. 
Just not a network that forms a basis for almost all kinds of computer 
communication.

If we are to be relevant to a wider community of users, I don't think it helps 
to assert ownership of the term "network".  So while I personally disagree with 
Twitter's position stated in the message cited, it's not with their claim that 
"Twitter is a network".

Let's not confuse apple and oranges.

#g
--

[1] "Linked", Albert-Laszlo barabasi
[2] "At home in the Universe", Stuart Kaufman

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 26 Mar 2011 08:27:09 +0100

On Mar 24, 2011, at 4:35 PM, Dave Cridland wrote:

> Sadly, probably very unlikely. Who's going to provide the kind of leadership we'd need to have a coherent architecture for the internet, instead of one that emerges driven by a few service providers?

I guess you are touching a much larger issue that has very little todo with the Web as such. You are essentially asking me (or the IAB) to get rid of the big players in the market place. Ideally, you want to have lots of small or medium size players but no one that dominates (like Facebook does for social networks or Twitter does for microblogging). 

Changing technical specifications will not help you to get to such a desired state. 

Ciao
Hannes

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 27 Mar 2011 16:25:22 +0200

> Subject: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00
> Date: Sun, 27 Mar 2011 16:18:11 +0200
> From: Dave CROCKER <[email-masked]>
> Reply-To: [email-masked]
> Organization: Brandenburg InternetWorking
> To: IETF Discussion <[email-masked]>

Folks,

I've just posted the above-cited review of the draft that is the basis for this 
thread, onto the IETF list, since it is time we all focus on the full community.

Please direct any comments you might have to that larger forum.

d/
-- 

   Dave Crocker

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Mar 2011 13:54:22 +0200

Dave, 

I just found this quote on "Professional XMPP Programming with JavaScript and jQuery" http://professionalxmpp.com/ 

"
The book's quite inspiring. Very few books on programming make me want to actually program something.
"
—Dave Cridland, Isode

Is this a different Dave Cridland?

For those who have not read through the book it talks about how to implement XMPP-based protocols in JavaScript. 

Ciao
Hannes

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Mar 2011 13:47:00 +0100

> Is this a different Dave Cridland?
No, same one.

> For those who have not read through the book it talks about how to  
> implement XMPP-based protocols in JavaScript.

That's a delightfully simplified view of that book, but more  
accurately, it discusses using an existing XMPP library (Strophe.js)  
which communicates over BOSH (an open-standard method for wrapping  
bidirectional streams in HTTP POST requests) to create web  
applications which operate over standards-based protocols.

In other words, it's discussing using open-standards in the web  
environment.

It doesn't talk about throwing out the very notion of open-standards.

As I said before, your suggestion that one could use Strophe.js  
instead of open-standards was therefore highly misleading, and very  
much counter to your argument that end-user application protocols  
have no place in this world.

Dave.