Are Device Independent Wireless Internet Applications Possible?

As 2003 approaches,the point at which wireless Web users are
expected to outnumber wireline users, there's little talk of the
challenge to build wireless applications for them, applications to
reach reach all of these users (as opposed to segments of these users
whose devices support proprietary protocols).

Open source tools, apps, and projects are expected to consume the
proprietary, wireless Internet, just as they consumed the wireline
Internet with implementations of TCP/IP and HTTP. Further, the
combination of open Internet standards and open implementations of
these standards will fuel the convergence of the wireless and wireline
Internet.

Dominant Wireless Infrastructures Today

There are two major wireless Internet technologies in broad
deployment today,WAP and i-mode, with a third, Java 2 Micro Edition
(J2ME), being adopted by PDA and handset manufacturers. The analyst
group Eurotechnology reported in November 2000 that the global
adoption rate of these technologies was about 60% for i-mode and 39%
for WAP. 81% of these wireless Internet devices are in use in Japan
today, with the rest scattered throughout Korea, the European
Community, and a very tiny percentage in the United States.

By "proprietary", the author means that there is
no mechanism that exists for a corporation, non-commercial entity, or
individual developer to contribute, implement, or extend these
technologies without licensing or payment. Thus, proprietary is
contrasted by "open", which implies that such a mechanism exists.

A handset or PDA manufacturer that intends to
implement any of these technologies must obtain licenses from Sun, the
WAP Forum, or NTT DoCoMo. In the case of WAP, developers are further
threatened by patent litigation by Geoworks, which claims to have a
patent on WML, and is pursuing patent license royalties from all
companies that implement the language.

Each of these wireless technologies today is proprietary and offers
dramatically different implementations. Clearly, this presents a
daunting challenge to any entity hoping to provide either content
(news, sports, stocks, etc.) or applications (games, entertainment,
corporate field force automation, etc.) to a global audience. i-mode,
which has 21 million subscribers as of this writing, uses Compact HTML
(cHTML) for its presentation technology. WAP devices use the Wireless
Markup Language (WML) for their presentation technology. The J2ME
presentation technology is not a mark up language like cHTML or WML
but, rather, Java code. In each of these cases, the technologies are
copyrighted and licensed to device manufacturers (both handset and PDA
vendors), and there are no open specifications or implementations of
them.

The global wireline Internet, however, is built around
non-proprietary standards and open implementations. History
demonstrates that the underlying data transfer protocol (TCP/IP), the
presentation and file transfer protocols (HTTP, FTP), and even the
presentation technologies themselves (HTML 1.0, 2.0, 3.0, 4.0 and its
successor XHTML 1.0) were successful precisely because they were open
standards, which any vendor, non-commercial entity, or developer could
implement.

Today's nascent wireless world reminds one of the Internet's early
days: instead of conflicting implementations by Netscape and Microsoft
of HTML and associated scripting facilities, we have WML/WAP, and
cHTML/i-mode for Web phones and handhelds, and SMS for pagers . Like
the early days of the wireline internet, wireless internet developers
struggle to test their code on as many phones and devices as
possible. The implementations of proprietary technologies are so
inconsistent as to force a "write once, test everywhere" strategy.
Indeed, an entirely new industry has sprung up, as a result of these
conflicting implementations, which promises to test and then certify
that content or applications that one develops will actually run on
implementations of the intended protocols and devices. (See http://www.anywhereyougo.com/,
a firm offering to certify that content and applications written to
the WAP specification actually function on devices that claim to
implement the WAP specification.)

As in the wireline Internet, however, proprietary and conflicting
implementations are unsustainable. To succeed, the wireless Internet
will move to open standards, and this migration has begun already.

What We've Learned from the Proprietary Wireless Internet So Far

The goal of this paper is not to harangue the existing wireless
Internet implementations. The early presentation technologies and
protocols substantially improved the wireless landscape by
demonstrating to the world technologies and business models that were
valuable and, in some cases, valueless.

Lessons from WAP
WAP is something of a contradiction in its technology, implementation,
and intent. WAP is nearly open in its intent, with a strong leaning
toward heterogeneous carrier networks and handsets. WAP is carrier
and handset independent, meaning that any carrier can implement the
specification and any handset manufacturer can implement the
presentation technology inside a WAP browser. The size of WAP Forum,
more than 500 members, demonstrates the compelling benefits of an open
handset and carrier approach. However, this openness is clouded by a
closed WAP Forum which only gives rights to its paying members, and
which hose a technology implementation that worked with no existing
tools and no existing development paradigm. I list below some of the
compelling technology advantages, most of which were
re-implementations of existing wireline Internet standards, as well as
the technical and business flaws.

WAP Benefits:

WML is an XML language, which provides an outstanding
mechanism to ensure that a document is well-formed, valid, and
portable. Dominant Internet technologies such as Java and
corresponding .NET technologies from Microsoft completely embrace an
XML approach to application development.

WAP provides a lightweight scripting language, which is fairly
easy to learn scripting language, inheriting from its Internet cousins
JavaScript, VBScript, and ECMAScript.

WAP, as demonstrated by the chart above, has strong adoption
among carriers and handset manufacturers, and holds second place in
terms of handset units deployed.

WAP Problems:

It has high carrier and developer Costs, requiring a
gateway to transcode Internet content and protocols into WAP content
and protocols. These gateways are costly, inconsistently implemented,
and offer no compatibility test suite to ensure that applications and
content are predictably transcoded by the competing vendors who
implement the gateways, which leads to high deployment and debugging
costs.

Application and Content developers must acquire new, or upgrade
existing, tools in order to author WML pages, as traditional web
development tools are generally incapable of properly authoring and
checking the syntax of WML documents. They must learn new application
development concepts (cards, decks, etc.) that are
non-trivial.

Due to the necessity of the WAP gateway to transcode content
and protocols, there are security concerns about data being decoded
and re-encrypted between the server of origin, hosting the
application, and the WAP gateway as it transforms HTTPS to
WAP/WTLS.

Lessons from i-mode In the i-mode implementation by
NTT DoCoMo, carriers and businesses around the world have witnessed
the first viable wireless Internet business model for developers of
wireless content and applications. Not surprisingly, NTT learned most
of these lessons NTT by observing the wireline Internet.

Under the i-mode network, content and applications developers are
able to sell their content for a monthly fee. All three elements of
the network are satisfied: the end user receives the content they
require; the developer is compensated for creating the content; and
the carrier derives income from a commission drawn from the
developers' fees, as well as per-packet network revenues.

Further, i-mode has taught carriers and businesses the technical
benefits of a nearly open wireless implementation. Specifically, the
i-mode network's use of cHTML has resulted in three key business
technology benefits:

Reduced Costs of Implementation -- because no gateways are
required to transcode content or applications in order for that
content to reach end users' devices, carriers need not purchase
gateways, nor absorb the costs of testing an application to determine
its compatibility with different gateways.

Superior Security -- because there are no gateways on an i-mode
network, there is no capacity for security breaches at a gateway, and
thus there is end-to-end security for applications and
content.

i-mode also taught a rather significant lesson, the impact of which
is only now being realized:

Note, NTT DoCoMo has purchased a 16% interest in
AT&T Wireless. The i-mode protocol will be brought to the United
States and rest of world via the AT&T network as well.

Renegade Implementation -- a proprietary network protocol
like cHTML/PDC-P is not easily shared by other carriers, and thus even
a handset capable of viewing cHTML cannot access cHTML content if the
end user is a SprintPCS, Nextel, or KDDI subscriber. NTT DoCoMo has
exclusive control of the protocol, the presentation technology, and
the billing mechanisms. Thus, for all the benefits listed above,
these benefits can only be realized on the NTT network; developers who
want to contribute to, implement, or modify the specifications
cannot.

Surprisingly, for a company that learned so many lessons from
the wireline Internet, i-mode does not implement any scripting
language. The end user experience is limited by the static nature of
the pages.

Finally, although NTT DoCoMo was the first to implement Java on
the i-mode network, the implementation is a proprietary derivation of
the Java 2 Micro Edition specification and not compliant with the
tests that Sun provides to ensure application portability between
handsets and carriers.

Lessons Learned from Java 2 Platform, Micro Edition
(J2ME) Sun, with its "the network is the computer" approach,
handles wireless development in a way that demonstrates its background
in enterprise application development and deployment platforms. Sun's
historical strength within the telecommunications marketplace was not
lost on the Java team, and all of the expertise of Sun has been
brought to J2ME. Indeed, with J2ME, Sun has completed the evolution
of the Java 2 Platform. Java, first implemented as a client
technology, then embraced as a portable server technology, has come
full circle to find a place on wireless Internet client devices in the
form of J2ME.

Benefits of the J2ME platform include the following.

J2ME applications persist on the client -- the single
greatest asset to the J2ME approach to wireless applications is the
fact that J2ME applications reside on the client and can function on
the client device even when the device cannot connect to the network.
Network dropouts are inconsequential when the application can persist
on the device, capable of caching newly entered data until a new
connection is established.

J2ME applications are secure -- the J2ME application developer
has full access to HTTPS for end-to-end application security.

J2ME applications are pervasive -- nearly every handset, PDA,
and carrier has adopted the J2ME specification.

Applications are far more graphically rich, with far higher
control of the end user experience (full-motion graphics, business
logic executing on the client, etc.)

Constraints of the J2ME platform are as follows.

J2ME in not yet pervasive -- while every manufacturer has
licensed the technology, there are precious few devices on the market
today (approximately 1 million). New cellular phone adoption has been
extremely rapid, however, although with current market conditions this
is unknown.

J2ME designers are not HTML/WMP/cHTML designers -- J2ME
requires that a content or application developer re-author their
application to target J2ME devices (a problem shared with WAP and
i-mode). However, a designer can purchase an upgraded tool to author
WML and learn these skills. In contrast, a designer is unlikely to
take a crash course in Java programming to learn to design
presentations in Java, thus forcing the designer to work with Java
developers in order to implement their application.

J2ME applications may have installation overhead -- in the USA,
carriers have commented that J2ME/MIDlet applications must be
installed on the device via a process of connecting to a PC (not
unlike how Palm Pilots are synchronized with their PC hosts). This
overhead will be costly for large organizations. Note, this is a
choice of the carriers, however, as the J2ME applications rolling out
in Japan install dynamically over the network.