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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxx>
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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]