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 <dcrocker@bbiw.net>
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