Subject: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

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

On 3/23/2011 12:12 AM, Peterson, Jon wrote:
 > 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.

Forgive my confusion, but that appears to be exactly the claim of the cited 
Internet Draft that we've been told this plenary is based on.

If the Plenary presentation is going to present an outline of technical work 
that should be done in the IETF, to support a particular operational protocol 
platform, then the session will differ considerably from the content of the 
Internet Draft.

With respect to that draft, the disparity between what is being claimed about it 
and what content I read prompted the following review:

Review of:          Trends in Web Applications and
                     the Implications on Standardization

Authors:            Tschofenig, Aboba, Peterson, McPherson

I-D:                draft-tschofenig-post-standardization-00

Reviewed by:        D. Crocker <[email-masked]>
Review date:        27 March 2011

This review is intended as input to the IETF's Monday Technical Plenary in Prague.

The "Trends in Web Applications and the Implications on Standardization" draft 
calls for changes to Internet technical standardization efforts, due to changes 
in "web applications" that in turn motivate changes in the "architecture of 
application protocols".  Use of a mobile software agent model -- downloading 
JavaScript from web server to client -- allows highly dynamic tailoring of 
client behavior. HTTP is put forward as the common -- implicitly universal -- 
data transfer platform; when combined with this mobile agent capability it 
eliminates the need for separate application protocols.  The draft extensively 
explores this view, variously highlighting the benefits of having a web server 
download JavaScript and the detriments of expensive, slow standards processes, 
as well as the cost and coordination effort of having client and server being 
separately developed and separately installed.

Some of the document's predicates and conclusions are left hanging as pure 
assertions, without direct linkage to the actual content of the draft and 
without putting forward any substantiation:  The reader has no basis for 
analyzing the authors' logic and therefore cannot make their own evaluation of 
the draft's views.  Worse, various assertions of fact are, I fear, not correct. 
I explore these issues below.

1. Architecture

The document promises, but does not provide, a discussion of protocol 
architectures, nor does it recommend which standards efforts still make sense to 
pursue.  There appears to be an implication that efforts should be devoted to 
improvement of the underlying mobile agent platform, but this is not stated 
explicitly.

As a matter of style, a document talking about architecture should have 
diagrams. When the discussion calls for changes to the architecture, the 
differences should be displayed and discussed. This sets the bar higher for a 
such drafts, but is necessary to guide reader understanding and analysis, and 
the subsequent discussion.

Architecture begs depiction.

2. Software

The draft is predicated on a common point of confusion between software 
architecture and network protocol architecture.  They are typically independent.

To repeat:  Software architecture is not network protocol architecture.

A change in one does not automatically mean any changes to the other.

Moving from a classic model of independent client and server development and 
installation, to a model with integrated development based on using a mobile 
agent environment, with automatic download, qualifies as a substantial change in 
a software model, It does not necessarily mean any changes in a protocol model 
or protocol details -- which might mean a protocol architectural change.
.  To the extent that the mobile agent environment is being defined in terms of 
particular "middleware" and transport protocol components -- such as JavaScript 
and HTTP -- that is a design decision that might or might not affect 
higher-level (application) protocols.

3. API

There is another fundamental error in the draft: conflating an API with a 
protocol. (Unfortunately,  discussion on the list has followed suit and suffered 
from this confusion.)

They are different: An API is not a protocol, and does not dictate the details 
of a protocol.

An API is merely a tailored interface at one end of the protocol and while it of 
course correlates with the details of the protocol, the correlation is never 
perfect and the protocol still needs specifying.  So while an API is necessary, 
it is not sufficient.

An instructive demonstration that they are quite different is the history of 
Netbios.  (See RFC 1001/1002.)  Simply put, an API can permit a variety of very 
different protocols with very different properties, while an API never specifies 
the exact details of bits over the wire.

4.  Mobile Agents

Downloading JavaScript from a server to a client is a constrained example of a 
mobile software agent model, dating back to the 1970s, with interesting work in 
the 1990s being General Magic's Telescript, as well as SafeTCL.  In the more 
general form, mobile agents travel around, interacting with each place they 
land, such as the calendaring programs of potential meeting attendees, to 
determine the best time for getting together.

The coarse-grained depiction of the activities discussed in this draft are:

       ........                                           ........
       :Client:        TCP/HTTP session initiation   ->   :Server:
       ........                                           ........
                      [Application selection         ->]

                  <-   Mobile agent upload

                  <-   Application activity          ->

Note that mobile agent upload requires its own protocol standard.

In terms of protocol "stacks", that upload phase looks something like:

      Agent Exchange Protocol    or     Agent Exchange Protocol
      -----------------------           -----------------------
               HTTP                              TCP
      -----------------------                    ...
                TCP
                ...

A mobile agent model creates an exciting software capability.  But its use in 
the constrained context of downloading a client does not mandate changes to 
existing application protocols nor to standards processes.  It also carries 
significant security and trust risks.  Remember that there already is a common 
and problematic name for software that is automatically loaded and executed on a 
user's machine, without the user's control...

The draft has extensive discussion about the current limitations of the 
JavaScript and Web client platform, as if those limitations are minor or easily 
remedied.  They aren't.  Limitations as extensive as those described in the 
draft, ensure a severely limited scope of use for the mobile agent model.

There is a reason that browsers have an option to disable JavaScript.

5.  Application Protocol

The draft characterizes HTTP as "replacing" application protocols -- for example:

>    The need for Internet standards beyond HTTP to
>    implement an email inbox application consequently diminishes...

So the draft asserts that POP and IMAP are no longer be needed. This view is 
quite simply wrong.

It misses the simple reality that an alternative environment based on HTTP still 
has an application protocol running at the top of the stack; for functional 
specificity between client and server, there must be additional conventions 
followed between them.

A set of conventions between network participants is called a protocol.

HTTP and HTML5 and Javascript do not combine to specify email conventions.  If 
client and server are doing email interactions then there is an email protocol.

A better "middleware" layer protocol platform might make it easier to specify 
the higher-level email protocol.  It might even allow more streamlined email 
protocol details.  But it does not eliminate the email protocol, since that is 
where the semantics reside.

Once the mobile agent is exchanged, the client/server interactions that perform 
the application functions constitute the application protocol, whether over HTTP 
or not and the protocol stack for this phase is the same as for any other 
application protocol stack model:

      Mailbox Protocol    or     Mailbox Protocol
      ----------------           ----------------
           HTTP                       TCP
      ---------------                ...
           TCP
           ...

6.  Proprietary

The draft further confuses the use of proprietary protocols with the absence of 
protocols.  In the above example with email, the self-contained environment that 
can be created by having the same team develop the server and the 
automatically-downloaded, Javascript, purpose-built client -- such as for doing 
email semantics across the wire -- is still a protocol.

The protocol might be a standardized protocol like IMAP or it might use a 
proprietary protocol, but it is still a protocol.

Sometimes it is appropriate to consider whether to develop a new, proprietary 
application protocol or better to use an existing, standardized.  This is a 
discrete, classic analysis to conduct, looking at tradeoffs. However it is 
independent of the software architecture used to get the client application 
software onto the client machine.

Note that the new, proprietary protocol will suffer the same learning curve with 
bugs and functionality that all new protocols experience.

The draft also appears to erroneously believe that standardization requires 
starting with a standards effort at the beginning of a technical effort. 
Starting the standards process later into the lifecycle of a protocol often 
works quite well, as demonstrated by NFS, SSL/TLS, Jabber/XMPP, and DKIM.

Open systems interoperability can start with a proprietary effort, but it 
ultimately requires a standards effort, since open systems are predicated on 
sharing control and access, while proprietary systems are predicated on 
centralized control.

The draft appears to see only the benefits in this reliance on proprietary 
protocols, without any sense of the attendant detriments.  Proprietary work can 
indeed be performed more quickly than standardized work.  It also can be 
tailored more.  However it also is subject to less review and less 
interoperability.  This means that it is likely to have more design flaws, more 
bugs and more data and usage isolation.  Witness the remarkable lack of 
interoperability among the many proprietary instant messaging services and the 
continuing difficulties in collaborating with shared calendaring.

Application protocol and object standardization activities are required, if data 
are to be shared.

7. Client Thickness

If the client/server interaction is really only the user-interaction surface of 
the mail system, where all of the actual email semantics are on the server, then 
this is not an email application on the client.  It is a generic user interface.

Keyclicks and text rendering are important, but they are not application semantics.

If there is limited email semantics on the client, then this is a specialized 
protocol, long called a "split UI".

If the client fully implements mailbox semantics for interacting with the 
server, then its interactions use a protocol comparable to IMAP or POP.

The draft fails to demonstrate or deal with these distinctions.

8. Extraneous

The draft has an extended discussion about a number of important hardware and 
software limitations that appear to be independent of the language and platform, 
as well as having nothing to do with any protocol.  These should be removed, or 
else they should be used as a basis for recommending specific work, in the IETF 
or elsewhere.

Summary
-------

Careful review of network service and protocol architectures is a worthy task, 
as is carefully considering whether and when to pursue standardization.  To the 
extent that there is standards work that will improve a common platform for 
mobile agent use, it too should be explored.

Unfortunately, the current draft does not assist in pursuing these goals.

The capabilities that prompted this draft are certainly worthy of IETF 
assistance.  This should begin with meaningful consideration of its needs, not 
with cavalier declarations about the end of any need to develop application 
protocols..

Specific Recommendations
------------------------

Mobile agent mechanisms are indeed exciting and the the paradigm does require 
protocol standardization.  It relies on a middleware networking infrastructure 
for exchanging agents and for defining agent syntax and semantics.  As noted 
earlier, conventions between a client and a server are called a protocol.   In 
addition to the usual concerns for interoperability, mobile agent models invoke 
intimidating degrees of security and trust concerns.  These need to be addressed 
and resolved directly.

Standards dealing with mobile agent security and trust concerns would be 
extremely helpful.

Similarly, standards for common "frameworks" for the use of mobile agents -- in 
effect defining classes of mobile agent applications -- could be helpful, since 
they would provide a higher point of departure and reduce incremental design and 
development effort.  Curiously, such an effort also could significantly help the 
security challenges:  An application class might permit pre-installing certified 
class-specific "sandboxes" to safely contain the mobile agent, while permitting 
carefully-disciplined access to local resources.

Discussions should explore these and related tasks.

As for the view that it is time to pursue basic changes to the development of 
application protocol standards, the case has yet to be made.

In fact, the case has yet to be started.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

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

Hi Dave, 

thank you for the detailed review of the draft. 
For time reasons I only focus on a few minor items; a more detailed response will follow later.

> 
> 2. Software
> 
> The draft is predicated on a common point of confusion between software architecture and network protocol architecture.  They are typically independent.
> 

While we indeed try to keep software architecture and network protocol architecture separately my observation of the Web protocols we looked at is that this does not seem to be the case here. While theoretically one could have any form of mobile code in the current Web deployment we are not talking about a random language for mobile code but instead we are only talking about JavaScript here. 

So, this is not a confusion from our side but rather an observation of the widespread deployment and success of JavaScript. 

> 
> 
> 3. API
> 
> There is another fundamental error in the draft: conflating an API with a protocol. (Unfortunately,  discussion on the list has followed suit and suffered from this confusion.)
> 
> They are different: An API is not a protocol, and does not dictate the details of a protocol.
> 
> An API is merely a tailored interface at one end of the protocol and while it of course correlates with the details of the protocol, the correlation is never perfect and the protocol still needs specifying.  So while an API is necessary, it is not sufficient.
> 
> An instructive demonstration that they are quite different is the history of Netbios.  (See RFC 1001/1002.)  Simply put, an API can permit a variety of very different protocols with very different properties, while an API never specifies the exact details of bits over the wire.

I fully agree that API in the way we use it in the IETF is not a protocol. 

However, it seems that other folks outside the IETF do not follow that definition and people talk, for example, about the Geolocation API: 
http://dev.w3.org/geo/api/spec-source.html
 
When you look at these "APIs" you will notice that they are actually more than just a programming interface. They are actually protocols.

So, there is a terminology mismatch here. 

> 
> 
> 
> 4.  Mobile Agents
> 
> Downloading JavaScript from a server to a client is a constrained example of a mobile software agent model, dating back to the 1970s, with interesting work in the 1990s being General Magic's Telescript, as well as SafeTCL.  In the more general form, mobile agents travel around, interacting with each place they land, such as the calendaring programs of potential meeting attendees, to determine the best time for getting together.
> 

By no means we claim that the idea of mobile code is a new idea. What is new is the widespread deployment. 

> A mobile agent model creates an exciting software capability.  But its use in the constrained context of downloading a client does not mandate changes to existing application protocols nor to standards processes.  It also carries significant security and trust risks.  Remember that there already is a common and problematic name for software that is automatically loaded and executed on a user's machine, without the user's control...
> 
> The draft has extensive discussion about the current limitations of the JavaScript and Web client platform, as if those limitations are minor or easily remedied.  They aren't.  Limitations as extensive as those described in the draft, ensure a severely limited scope of use for the mobile agent model.
> 
As you note above there are security risks with that approach as well. We are aware of these challenges (and some other limitations). 
We (the authors) believe that the IETF community should take a closer look at these security challenges (not only those that result from JavaScript but from the Web in general). To start the work on some of them the Websec working group was created last year in the IETF and the formation of a group in the W3C is pending. 
Clearly, this will not be enough. More work is needed (as I stated at the HASMAT BOF about 9 months ago) to identify the longer term story for dealing with some of the problems we expect to see in the future. 

We do not believe that the security challenges will be solved easily. In fact we say: 

"
   It is unavoidable to get the impression that the hard problems,
   particularly to security concerns regarding the distribution of new
   software in whatever form, have not been tackled.  Instead, the
   browser becomes the new operating system, inherits the same
   weaknesses and is likely to share the same fate.
"

> So the draft asserts that POP and IMAP are no longer be needed. This view is quite simply wrong.
> 
> It misses the simple reality that an alternative environment based on HTTP still has an application protocol running at the top of the stack; for functional specificity between client and server, there must be additional conventions followed between them.
> 
> HTTP and HTML5 and Javascript do not combine to specify email conventions.  If client and server are doing email interactions then there is an email protocol.
> 
> A better "middleware" layer protocol platform might make it easier to specify the higher-level email protocol.  It might even allow more streamlined email protocol details.  But it does not eliminate the email protocol, since that is where the semantics reside.
> 
> Once the mobile agent is exchanged, the client/server interactions that perform the application functions constitute the application protocol, whether over HTTP or not and the protocol stack for this phase is the same as for any other application protocol stack model:
> 

I think the important aspect for IETF standards development is the following. IMAP and POP are protocols standardized a while ago already. They exist and that's fine. 
Imagine that you are a protocol designer that wants to develop a new feature for an email client. As an example, you want to define a new extension that makes certain email functions more efficient or so. 

You now have various options: You can write a new specification (like we did in the past) or you could add a piece of HTML/JavaScript code to your deployment and make use of it. It will immediately be available to your customers that use email through a browser. 

Which approach is the right one to do? Well. It depends on a number of factors.  

The authors view is that the increased importance of the Web deployment will lead many developers to consider the second option rather than to go for the former. 

> 
> 6.  Proprietary
> 
> The draft further confuses the use of proprietary protocols with the absence of protocols.  In the above example with email, the self-contained environment that can be created by having the same team develop the server and the automatically-downloaded, Javascript, purpose-built client -- such as for doing email semantics across the wire -- is still a protocol.

It is unfortunate if the draft gave the impression that these JavaScript mechanisms aren't protocols. Clearly they are, as you point out. 
We need to make this more clear. 

As you state below, in certain cases you may well implement a standardized protocol in JavaScript. This is, for example, done in case of XMPP. See, for example, http://professionalxmpp.com/

> The protocol might be a standardized protocol like IMAP or it might use a proprietary protocol, but it is still a protocol.
> 
> Sometimes it is appropriate to consider whether to develop a new, proprietary application protocol or better to use an existing, standardized.  This is a discrete, classic analysis to conduct, looking at tradeoffs. However it is independent of the software architecture used to get the client application software onto the client machine.

I agree with you. This of course assumes that web developers are aware of the work we do in the IETF and how easy it is usable for the Web environment. 
For us in the IETF this means that our protocols have to be easy to implement with Web programming languages. To give you an example: In the OAuth work from a security point of view it would have been great to sign an entire HTTP message but many of the programming languages did not pass the raw HTTP message up to the developer. So, it wasn't really an option. 

> 
> Note that the new, proprietary protocol will suffer the same learning curve with bugs and functionality that all new protocols experience.
> 
Definitely true. For this purpose many web developers use frameworks and libraries. We reference a couple of them in the draft, such as JQuery. 

> The draft also appears to erroneously believe that standardization requires starting with a standards effort at the beginning of a technical effort. Starting the standards process later into the lifecycle of a protocol often works quite well, as demonstrated by NFS, SSL/TLS, Jabber/XMPP, and DKIM.

I am not sure we say that. We definitely do not believe that. 

> 
> Open systems interoperability can start with a proprietary effort, but it ultimately requires a standards effort, since open systems are predicated on sharing control and access, while proprietary systems are predicated on centralized control.
> 
> The draft appears to see only the benefits in this reliance on proprietary protocols, without any sense of the attendant detriments.  Proprietary work can indeed be performed more quickly than standardized work.  It also can be tailored more.  However it also is subject to less review and less interoperability.  This means that it is likely to have more design flaws, more bugs and more data and usage isolation.  Witness the remarkable lack of interoperability among the many proprietary instant messaging services and the continuing difficulties in collaborating with shared calendaring.

We may need to describe the pros and cons more in the document. The document does not describe how we would like the world to look like but rather how it looks like and how we expect it to move forward.  

> 
> Application protocol and object standardization activities are required, if data are to be shared.
> 
The need for server-to-server communication does not seem to go away, as we state in the draft. Also the work on data formats seems to be needed but it turns out to be quite difficult, as we notice for a long time on location, contact information, etc. 

> 
> 
> 7. Client Thickness
> 
> If the client/server interaction is really only the user-interaction surface of the mail system, where all of the actual email semantics are on the server, then this is not an email application on the client.  It is a generic user interface.
> 
> If there is limited email semantics on the client, then this is a specialized protocol, long called a "split UI".
> 
> If the client fully implements mailbox semantics for interacting with the server, then its interactions use a protocol comparable to IMAP or POP.
> 

We actually do not deal with purely "screen sharing" approaches. That's also an interesting area of work that people are looking into (even for games). 

> 
> 
> 
> 8. Extraneous
> 
> The draft has an extended discussion about a number of important hardware and software limitations that appear to be independent of the language and platform, as well as having nothing to do with any protocol.  These should be removed, or else they should be used as a basis for recommending specific work, in the IETF or elsewhere.
> 
> 
The hardware and software limitations are important for judging where limitations when going for a Web based environment with protocol design. When we did our interviews we tried to identify where the current limitations are of this HTML/JavaScript model and the writeup considers what we had been told. For example, if you want to standardize a gaming protocol that aims at high-end ego-shooters then the Web model is not useful for you.

Ciao
Hannes

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 28 Mar 2011 17:26:38 +0200

Beginning of the Technical Plenary... this is my version of posting to 
bad-attitude...

On 3/27/2011 4:59 PM, Peterson, Jon wrote:
> Without speaking to your review of the draft as such, let me restate what has
> already been said on the apps-discuss list:

Jon,

Forgive me, but a review of that archive did not produce the referenced 
clarification.  We /were/ told of two speakers -- who, indeed, are not on the 
IAB -- is quite different.  Could you please provide a pointer, so I can stop 
worrying that my reading comprehension is getting worse than it's historically 
terrible state...

> plenary will be presented by persons who are not on the IAB, and whose
> opinions will not necessary reflect the thinking of any IAB members.

What is odd about this statement is that it has been 2 IAB members (you and 
Hannes) who were actively responding to the apps discussion thread. Your 
postings were quite uniform in disagreeing with the concerns people were 
expressing on the apps list, based on the title and description produced for an 
IAB-sponsored plenary session.

As I read the text, there is no restraint in these bits of text.  They declare a 
new world and pretty much the end of apps protocol standards work.

Did you not really mean them?  Certainly the comments being made now sound as if 
the scope of the session is far more constrained.

While I do hear the recent notifications that pointedly detach the session from 
the IAB, please note that choosing to consume this much time of this many IETF 
folk lends it credibility and makes it a kind of endorsement.

Further, the repeatedly-cited draft that I reviewed was characterized as 
providing more complete details behind the plenary, and that draft was written 
by 3 IAB members and an AD who is an ex-IAB member.

I understand that this does not make it formal IAB work product, but the IAB is 
hardly uninvolved at a deep level. There is a very clear and strong degree of 
implicit IAB endorsement surrounding this work and this plenary.

 From your more recent postings, it appears the actual content will have little 
to do with what we were told by the title, the summary, or the cited draft.

On the other hand, what we are now being certainly sounds interesting...

 >
 > While we indeed try to keep software architecture and network protocol
 > architecture separately

I found nothing in the draft that stated or maintained the distinction.

 >    my observation of the Web protocols we looked at is that this does not 
seem to be the case here.

Please review my review comments concerning client/server interaction that has 
any application-specific series.

 > While theoretically one could have any form of mobile code in the current Web
 > deployment we are not talking about a random language for mobile code but

Please explain that is relevant to the basic points I raise in the review.

 > instead we are only talking about JavaScript here.

You are saying that, in this case, software architecture and networking 
architecture are not separate.  This suggests a very basic disparity in the 
nature and roles of the two.

 > So, this is not a confusion from our side but rather an observation of the
 > widespread deployment and success of JavaScript.

There are two confusions that persist:  One is the continuing assertion that 
there is no higher level protocol involved in the interaction between the client 
and the server -- which I covered in my review, and the other is that anyone is 
disagreeing that JavaScript is popular (and even useful.)

 >> Netbios.  (See RFC 1001/1002.)  Simply put, an API can permit a variety of
 >> very different protocols with very different properties, while an API never
 >> specifies the exact details of bits over the wire.
 >

"In the way we use it"???  An API is never a protocol, Hannes.

 > However, it seems that other folks outside the IETF do not follow that
 > definition and people talk, for example, about the Geolocation API:
 > When you look at these "APIs" you will notice that they are actually more
 > than just a programming interface. They are actually protocols.

Anyone can look Through the Looking Glass and define established terms in new 
and conflicting way.  Anyone also can simply misuse a term.

I would hope that the IAB could help the community in quality assurance on the 
meaning and use of established terms, especially ones that were established long 
before many IETF participants were born.

 > So, there is a terminology mismatch here.

Surely not by any IAB members...

 > As you note above there are security risks with that approach as well. We are
 > aware of these challenges (and some other limitations).

I noted that you were.  My comment was that your document seemed to treat this 
issue as mild, whereas it is not only major, it is arguably beyond the state of 
the art.

 > We (the authors) believe that the IETF community should take a closer look at
 > these security challenges (not only those that result from JavaScript but
 > from the Web in general). To start the work on some of them the Websec
 > working group was created last year in the IETF and the formation of a group
 > in the W3C is pending.

Websec concerns detecting and prevent infection by viruses?

quite simply wrong.
 >>
 >> It misses the simple reality that an alternative environment based on HTTP 
still has an application protocol running at the top of the stack; for 
functional specificity between client and server, there must be additional 
conventions followed between them.
 >> HTTP and HTML5 and Javascript do not combine to specify email conventions. 
If client and server are doing email interactions then there is an email protocol.
 >>
 >> A better "middleware" layer protocol platform might make it easier to 
specify the higher-level email protocol.  It might even allow more streamlined 
email protocol details.  But it does not eliminate the email protocol, since 
that is where the semantics reside.
 >>
 >> Once the mobile agent is exchanged, the client/server interactions that 
perform the application functions constitute the application protocol, whether 
over HTTP or not and the protocol stack for this phase is the same as for any 
other application protocol stack model:
 > I think the important aspect for IETF standards development is the following. 
IMAP and POP are protocols standardized a while ago already. They exist and 
that's fine.
 > Imagine that you are a protocol designer that wants to develop a new feature 
for an email client. As an example, you want to define a new extension that 
makes certain email functions more efficient or so.
 >
 > You now have various options: You can write a new specification (like we did 
in the past) or you could add a piece of HTML/JavaScript code to your deployment 
and make use of it. It will immediately be available to your customers that use 
email through a browser.
 > Which approach is the right one to do? Well. It depends on a number of factors.

This example goes to the core of the difference between network protocol and 
software architecture.  Your are describing a false dilemma.

The HTML/Javascript software choice is still going to be using a protocol back 
to the server and there is nothing with your using a standard like IMAP and 
choosing to do a proprietary upgrade to it.

After demonstrating its utility, you might even choose to pursue standardizing it.

 >> The draft further confuses the use of proprietary protocols with the absence 
of protocols.
...
 >
 > It is unfortunate if the draft gave the impression that these JavaScript 
mechanisms aren't protocols. Clearly they are, as you point out.
 > We need to make this more clear.

Dandy.

 > I am not sure we say that. We definitely do not believe that.

Dandy.

 >> The draft appears to see only the benefits in this reliance on proprietary 
protocols, without any sense of the attendant detriments.
...
 >
 > We may need to describe the pros and cons more in the document.

Yes.

 > The need for server-to-server communication does not seem to go away, as we 
state in the draft. Also the work on data formats seems to be needed but it 
turns out to be quite difficult, as we notice for a long time on location, 
contact information, etc.

It does not matter whether it is server-server or client-server, with respect to 
this point:  If application services are to share things, the sharing needs to 
be standardized.

Sharing happens within a user's host, not just between servers.

 >> 7. Client Thickness
..
 > We actually do not deal with purely "screen sharing" approaches. That's also
 > an interesting area of work that people are looking into (even for games).

The draft gave no indication of which model it wants to pursue.

 >> 8. Extraneous
 >>
 >> The draft has an extended discussion about a number of important hardware 
and software limitations that appear to be independent of the language and 
platform, as well as having nothing to do with any protocol.  These should be 
removed, or else they should be used as a basis for recommending specific work, 
in the IETF or elsewhere.
 >>
 >>
 > The hardware and software limitations are important for judging where 
limitations when going for a Web based environment with protocol design.

As discussed in the draft, some or all of the limitations were universal, not 
just about web apps.

d/

-- 

   Dave Crocker

---

From: Eric Burger <[email-masked]>
Date: Tue, 29 Mar 2011 13:24:32 +0200

I think this encapsulates what Dave is trying to get across:

Yes, it is MUCH easier for a server developer to stuff in a little more JavaScript.

Now, you have a 100% proprietary system, with no hope or desire for interoperability, that gets deployed much faster than someone taking their extension to the IETF for inclusion in, for example, IMAP.  The only reason one would go for the standard solution is if they want to interoperate with other vendors.  As you point out, there is absolutely no reason for anyone to participate in the standards process if they have no intention of interoperating with OTHER implementations.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Mar 2011 13:31:13 +0200

Correct. 

The interoperability need shifts away from the client-to-server side (for example, to the server-to-server side; see Jonathan's plenary presentation slides) and to building blocks that are considered useful in various contexts. 

The BarBOF about JSON signing and encryption we had yesterday evening is an example of such a building block.

Ciao
Hannes

On Mar 29, 2011, at 1:24 PM, Eric Burger wrote:

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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 29 Mar 2011 13:35:28 +0200

On 3/29/2011 1:24 PM, Eric Burger wrote:
> Now, you have a 100% proprietary system, with no hope or desire for
> interoperability, that gets deployed much faster than someone taking their
> extension to the IETF for inclusion in, for example, IMAP.  The only reason
> one would go for the standard solution is if they want to interoperate with
> other vendors.  As you point out, there is absolutely no reason for anyone
> to participate in the standards process if they have no intention of
> interoperating with OTHER implementations.

WFM, within the portion of the issue is seeks to cover.

The two points I would are:

1. This model has more downsides than just no interoperability; I cited them in
my review.

2. Proprietary systems like this often need standards too, albeit ones developed
privately, with private review:  Within a company it is typical to have the
mobile code and the server be implemented by different teams and they need to
code against a common spec, hence a protocol stanards...
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 29 Mar 2011 13:40:34 +0200

On 3/29/2011 1:31 PM, Hannes Tschofenig wrote:
> Correct.
>
> The interoperability need shifts away from the client-to-server side (for
> example, to the server-to-server side;

No, that's wrong and I believe it is not what Eric said at all.

THERE IS STILL A CLIENT/SERVER PROTOCOL, HANNES.

ALL THAT CHANGES IS THAT THE CLIENT/SERVER PROTOCOL IS NOW PROPRIETARY.

I apologize for shouting.  I'm shouting for the classic reason that I'm taking 
your continuing to misunderstand this multiply-repeated and very basic point as 
a hearing problem.

Server-server is an entirely different task and different part of the architecture.

d/
-- 

   Dave Crocker

---

From: Scott Brim <[email-masked]>
Date: Tue, 29 Mar 2011 17:13:21 +0200

On Tue, Mar 29, 2011 at 13:24, Eric Burger
<[email-masked]> wrote:
> interoperability

There has to be interoperability in the system, but not at every
interface.  Bear with me while I compare this situation to big old
computers connecting to a network.  The I/O bus, for example, does not
have to be standardized -- it's an internal matter.  It's only when
you reach an administrative boundary that you need a standard.  A
standard API can help when there is advantage to opening up the field,
e.g. BSD sockets, so you create a standard interface and if necessary
you establish an administrative boundary at that point.

OK, so you probably know where I'm going.  In a system such as mail,
where are the administrative boundaries?  There are two scenarios:

  - An "application", for example an MUA makes it possible for you to
    do your mail.  This is essentially a "service" that interfaces to
    a "client", the human.  There is no administrative boundary there,
    and the ways in which "client" and "server" interact is not
    standardized.  But there is an administrative boundary when the
    application wants to talk to either a mail transport agent or
    another such service.  At that point there is a published
    interface spec.

  - A "service" such as Gmail or Hotmail is serving a "client"
    specific to it.  That interface is proprietary -- unlike above,
    where there is an administrative boundary, everything here is
    "internal".  But there is a boundary between such "services", and
    that is standardized.  In some cases an individual "service" can
    have several (SMTP, CALDAV etc.)

Some web-style services have decided that there is an advantage to
letting a hundred flowers bloom, and they have defined clear
boundaries and specified interfaces.  Consider Twitter.

So back to what you said ... there is hope for interoperability, where
it is seen as useful.  Some do, some don't.

> The only reason
> one would go for the standard solution is if they want to
> interoperate with other vendors.  As you point out, there is
> absolutely no reason for anyone to participate in the standards
> process if they have no intention of interoperating with OTHER
> implementations.

Yup.  Just because some don't doesn't mean it is not possible.  And in
those situations where it looks like "there is no interoperability",
therre is interoperability at administrative boundaries.

Next step ...

When things like rtcweb want standardized ways for clients to speak to
each other over a transport provided by web services, they are
creating a "layer network" (q.v.).  In this case the web service
interface is like a link layer (it's specified for use within a
particular subsection of the layer network), and the end-to-end
communication is like a network layer.  Where does it have to be
locally standardized, and where does it have to be globally
standardized?

Scott

---

From: Eric Burger <[email-masked]>
Date: Tue, 29 Mar 2011 22:53:40 +0200

Got it in 1.

On Mar 29, 2011, at 1:40 PM, Dave CROCKER wrote:

> I apologize for shouting.  I'm shouting for the classic reason that I'm taking your continuing to misunderstand this multiply-repeated and very basic point as a hearing problem.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Mar 2011 09:14:51 +0200

Dave, 

I explain the change with two figures in order not to be misunderstood (again). 
I use SIP as an example; Jonathan gave a nice presentation.

Working Assumption previously: 

    ............................          ..............................
    .                          .          .                            .
    .                +-------+ .          . +-------+                  .
    .                |       | .  SIP     . |       |                  .
    .                | Proxy |------------- | Proxy |                  .
    .                |   1   | .          . |  2    |                  .
    .                |       | .          . |       |                  .
    .              / +-------+ .          . +-------+ \                .
    .             /            .          .            \               .
    .            /             .          .             \  SIP         .
    .     SIP   /              .          .              \             .
    .          /               .          .               \            .
    .         /                .          .                \           .
    .        /                 .          .                 \          .
    .       /                  .          .                  \         .
    .   +-------+              .          .                +-------+   .
    .   |       |              .          .                |       |   .
    .   |       |              .          .                |       |   .
    .   | UA 1  |              .          .                | UA 2  |   .
    .   |       |              .          .                |       |   .
    .   +-------+              .          .                +-------+   .
    .              Domain A    .          .   Domain B                 .
    ............................          ..............................

                        Figure 1: The SIP trapezoid

We have lots of standardization efforts that focus on the UA<->Proxy leg in the RAI area. 

Suggested new working assumption: 

                +-----------+             +-----------+
                |   Web/    |             |   Web/    |
                |   SIP     |     SIP     |   SIP     |
                |           |-------------|           |
                |  Server   |             |  Server   |
                |     1     |             |     2     |
                +-----------+             +-----------+
                     /                           \
                    /                             \   Proprietary over
                   /                               \  HTTP/Websockets
                  /                                 \
                 /  Proprietary over                 \
                /   HTTP/Websockets                   \
               /                                       \
         +-----------+                           +-----------+
         |JS/HTML/CSS|                           |JS/HTML/CSS|
         +-----------+                           +-----------+
         +-----------+                           +-----------+
         |           |                           |           |
         |           |                           |           |
         |  Browser  | ------------------------- |  Browser  |
         |           |          Media            |           |
         |           |                           |           |
         +-----------+                           +-----------+

                      Figure 2: Browser RTC Trapezoid

The server-to-server interaction I was referring to in my previous mail is the interaction between server 1 to server 2. With cross-domain usage there still a standardization need. This is what I mean by "the interoperability need shifts". 

We had spoken about the implications of that change already.

Ciao
Hannes

---

From: Scott Brim <[email-masked]>
Date: Wed, 30 Mar 2011 09:20:22 +0200

Right.  You might add control boundaries.  What's happening is that
the server is extending a pseudopod down into the user environment, so
that the 'user agent' is within its control boundary.  There will
still be other apps, other user agents, in the user environment that
are outside of service control -- they will need standardized
interfaces to services.

---

From: Eric Burger <[email-masked]>
Date: Wed, 30 Mar 2011 10:18:25 +0200

And the Proxy <-> Browser interaction is 100% out of IETF scope.  For that matter, the IETF should be pointing out how dangerous and evil such a proposal is, as it means the end of consumer choice and a competitive marketplace for clients.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 30 Mar 2011 09:30:12 +0100

> are outside of service control -- they will need standardized

Please, Scott, Hannes, take the time to read this carefully.

The server/server protocol remains an open standard, indeed. But as  
The Other Dave C says, there is still a client/server protocol, but  
it's now (as clearly marked on Hannes's diagram) a proprietary one.  
Any client/server interface that's forced into being an open standard  
becomes a second-class citizen for legacy access.

You may believe this is not a big loss, but it is most unfortunate,  
for two reasons:

- We [should] promote the use of open standards over proprietary ones.

There is more than mere pragmatism involved in standardization. We  
don't merely want things to work, we want them to work well,  
everywhere. By removing the ability to interoperate with full  
features over the "last mile", we eliminate the ability to innovate  
without operating a service provider, in effect, and unless that  
service provider is particularly large, any innovation will simply be  
duplicated by the larger ones, removing any incentive for smaller  
outfits. Promoting innovation - and this is a much bandied-about term  
which we can also phrase as "making things better faster" - needs to  
occur by lowering barriers to entry.

The use of mobile code and (in effect) self-deploying clients does  
indeed lower some barriers to entry, but it raises other ones.

- This model spells the death of end-to-end applications.

Hannes's diagram shows clearly that SIP is no longer spoken between  
clients, in this brave new world, but only between servers. This  
means that any intelligence - any interoperability - between services  
has to now occur solely at the server/server link. In almost every  
protocol which federates to any degree, this has proven to be a very  
poor model.

It is unfortunate that every example chosen by Hannes et al provides  
a clear example of both the above cases. To pick the two I'm most  
familiar with:

1) Email - IMAP and POP - allows MUAs to send RFC 5321 formatted  
emails to each other, and allows MUAs to independently adopt  
end-to-end functionality signalled via this format. For example, iCal  
(more specifically iMIP) operates without any support from the MTAs,  
and indeed for certain points of view we can effectively ignore that  
anything more than the MUA exists at all.

Similarly, innovation has continually occured at the edge -  
Thunderbird, Opera Mail, and so on - all have innovated thanks to a  
standards-based last mile.

2) Strophe.js - XMPP and BOSH. XMPP does have relatively smart  
servers, as compared to other protocols, but it's very clear to  
anyone who's paid much attention that innovation generally occurs  
between endpoints on the XMPP network - even the XEP-0045 Multi User  
Chat we're using in (almost?) every WG meeting this week - which we  
cheerfully call "jabber" - occurs as a result of interactions between  
and end-user client and the chat service directly, with the user's  
own server actually playing the passive role of simply routing  
stanzas from client to remote service with no knowledge of what the  
stanzas might signify. Again, the end-to-end principle holds (where  
appropriate), and allows us to ignore the servers' existence for much  
of the use-cases.

BOSH provides a standardized interface to XMPP for web applications  
(and in principle other applications too), and Strophe.js - and JsJAC  
- both take advantage of this to provide both innovative and  
standardized end-user services.

The majority of servers do not even ship with a standard client - I'm  
only aware of two which do, and one of these (to my intense suprise)  
actually uses a customized open-source client - which obviously  
suggests that innovation occurs - at a fast pace, I'll add.

In my experience - and I can claim to have a fair amount in this area  
- it is several orders of magnitude harder to get deployment of a XEP  
which relies on both client support and every server in the path. In  
fact, the only one I can think of is AMP (XEP-0079), which has zero  
deployment. Even pure S2S protocols are hard - yet end-to-end  
protocols such as XEP-0184 (which provides a simplified protocol for  
one part covered by AMP) rapidly get wide deployment. It seems  
inconceivable that the same pace of innovation could occur if the  
client developers were cut out of the equation, especially given the  
(necessarily) slow pace of the larger service providers.

The ability to embed XMPP functionality into a web page *is* very  
useful, and very powerful. But this is nothing like the same as being  
able to sling in some arbitrary javascript chat applet - the real  
benefit of Strophe.js, BOSH, and XMPP is that you can provide a  
direct gateway into the XMPP federation and access standardized  
services directly from the browser.

And this is reliant on several open standards running over the last  
mile.

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: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Mar 2011 11:08:13 +0200

As said, the implications of such a decision have been discussed and there are pros and cons to the approach. 
"evil" is probably not a correct clarification.