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