W* Effect Considered Harmful

The Wireless Application Forum has developed an entire stack of network protocols parallel to, and only marginally compatible with, the existing Internet architecture. They are convinced handheld wireless devices are -- and will remain -- four orders of magnitude less powerful than conventional Internet hosts and thus require optimized transport, applications, and content. At each turn, WAP Forum has chosen to reinterpret existing Internet standards -- often incompatibly. The shift from UDP to WDP, TLS to WTLS, HTTP to WTP, HTML to WML, ECMAScript to WMLScript -- termed 'the W* Effect' -- is disingenuous at best, and at worst, locks in early WAP adopters to today's lowest common denominator.

This report presents a summary of WAP, its history and key players, a layer-by-layer tour of its standards (and its competitors at each layer), and its market potential for handset providers, network operators, application servers, and content providers. This provides context for understanding the strategic conflict between WAP and a host of other, more established Standards Development Organizations (SDOs).

The hegemonic spirit of the age inspires industry slogans of "Windows Everywhere!," "Java Anywhere!," and "AOL Everywhere!" While these are mere market visions as yet, it's informative to look back at one technical paradigm in computing that has conquered or co-opted every effective rival to its progress over the last three decades: "IP Over Everything."

The Internet has adapted to radical growth in scale (bandwidth, hosts) and in character (timesharing, PCs, embedded systems). In particular, the death of TCP/IP has been oft foretold, but it has been adapted to cope with greater congestion, greater latency variation, greater bandwidth, link compression, and security requirements.

The latest challenge is integrating handheld wireless devices into today's wired Internet. Such devices have much lower bandwidth, much lower processing power, and much smaller user interfaces.

The "control hypothesis" is that these devices can be accommodated as just another kind of Internet host. That approach is to tweak around the edges by profiling 'smarter' TCP over airlinks, 'compact' HTML, and 'split-proxy' security.

The other approach is to throw everything out and reinvent the protocol stack from scratch. And for good measure, to sprinkle pixie dust over the whole suite by claiming compatibility with those established standards. Unwired Planet, Inc. and its mostly-captive Wireless Application Forum have opted for the latter. In the long run, it cannot succeed.

The choice of 'adapt or reinvent' has been mapped onto two different visions of wireless devices. One views them as miniaturized PCs, the other as cellphones-on-steroids. WinCE, Mobile NCs, and Symbian's EPOC operating systems are predicated on the former -- indeed, only a "real computer" would even have an OS onboard. WAP Forum's technology aims for the latter: deploying an absolutely standardized 'microbrowser' environment on today's handsets.

This dichotomy is also entangled with the choice of service model: should the device only access the carrier's value-added services, or any public Internet resource? WAP Forum and its major backers have proclaimed that handheld Internet access is not about 'surfing', and so eschewed generic approaches for custom applications hosted by the carrier. There isn't even an escape hatch -- standard HTML pages do not map directly onto WML.

Unwired Planet was founded in May of 1995 to develop handset-based access to the Internet. By December, it had codified its "insights" as US Patent 5,809,415: "Method and architecture for an interactive two-way data communication network". AT&T Wireless' PocketNet was their most visible early adopter: a commercial disappointment that could barely send e-mail and fetch stock quotes.

From the beginning, their strategy has been to give away its client. As UP's recent S-1 IPO filing states, "we license our UP.Browser software to wireless telephone manufacturers free of per-unit royalties and provide maintenance and support services for an annual flat fee."

With that lure, UP convinced Nokia, Ericsson, and Motorola to join in launching WAP Forum, which quickly rubber-stamped a slightly-reworked edition of UP's then-current product.

By now, there are 91 member firms (at $27,500 per year). Member manufacturers represent 90% of global handset shipments; commitments to ship 'WAP-enabled products' cover 75%. Member carriers have 100 million subscribers. Dozens of internal working groups have proliferated, including several devoted to WAP marketing alone.

WAP Forum Chairman Chuck Parrish is also an Executive VP of Unwired Planet -- and tellingly, its second most highly compensated employee. UP is counting on first-mover monopoly profits from their influence over WAP Forum and three-year head start. Their UP.link server software costs network operators on the order of $1 million for its server software -- plus a per-device licensing fee. Not per-activated-WAP-user -- they expect royalties for every 'WAP-capable device,' regardless. A 2 million subscriber carrier faced a $20 million commitment!

WAP Tools. Server software is the key to deploying WAP, and UP's competitors are still catching up. Nokia and Ericsson have announced servers, as well several independents: APiON (Ireland), CMG (Netherlands; OEM'd from Nokia), and Dr. Materna (Germany). Most of these systems run on Solaris. The largest computer services firms have not committed yet: Lucent, IBM, HP, and Oracle are only rumored to have started work.

Client SDKs for content providers are available from UP, Nokia, Ericsson, and Dynamical Systems Research (UK). Interviewing current vendors of Web translators for handhelds such as AvantGo, Spyglass, Proxinet, and Online.Anywhere uncovered only vague plans.

WAP Devices. It's designed to scale down to two-line, one-way, text pagers, so in one sense there are millions of fielded WAP-compatible devices. In a more conventional vein, there are shipping UP.browser-equipped phones from Motorola (i1000plus), Nokia (7110), and LG (NeoPoint 1000).

WAP support is nonexclusive, though: many of the same firms are partners in Symbian (Psion, Nokia, Ericsson, Motorola, Phillips, IBM, Oracle, NTT, and Sun). Its EPOC32 screenphones can work with mobile IP today and WAP soon. A little further up the complexity scale, WAP support stops: there are no announced plans for WAP-enabled WinCE, PalmOS, or laptop devices.

WAP Services. While a few operators have deployed WAP services (notably Finland) and many more have run trials, the industry will be watching a few high-profile North American launches this year. Nextel has announced Nextel Online by Q499; AT&T Wireless will relaunch son-of-PocketNet; Sprint PCS is uncommitted. Otherwise, carriers may still wait 2-3 years for "third generation" high-bandwidth systems (UMTS) and mobile-IP service to more capable handhelds (with "real" browsers).

Beyond carrier-hosted applications like email and calendaring, content providers have been limited to marquee partners so far: CNNmobile, Reuters, Netcenter, and other consumer brands should be expected. There have not yet been any customer-driven internal applications of the sort envisioned by WirelessKnowledge. As detailed below, WML card 'decks' are sufficiently different from the existing Web to require custom software.

With WAP, all the smarts are built into the WAP Gateway at the carrier's premises. To the public Internet, it becomes the termination point: from there to the device, WAP Forum's standards kick in. Claiming that 'wireless is different', WAP 1.1 rewrites almost every Web standard in the book.

Network Layer. For good measure, there's a low-level control message protocol: WCMP is similar to, but less informative than ICMP. To adapt to the myriad airlink protocols out there, WAP defines its own format for datagram packets. WDP is based on UDP, but with its own port numbering semantics. Security is inserted next. Rather than an an analogy to IPsec, WTLS offers SSL/TLS like transport-layer security, using new elliptic curve cryptosystems for low-powered terminals. What the Internet calls "transport", though is in the next layer: WSP. It's a session protocol roughly equivalent to TCP, but with experimental transaction features.

Application Layer. WSP also folds in what the Internet calls "applications": a creatively reconceived HTTP with binary encoding, push, and stateful access. It's used to fetch 'decks' of 'cards' written in Wireless Markup Language, which is less like HTML pages than a BASIC-like programming language for text screens, complete with scoped functions, variables, and timers. WML is an XML application, to be sure, but it can only be transmitted in a homegrown compressed format called Wireless Binary XML (WBXML). Finally, the 'microbrowser' -- whose user interface has been homogenized to minute detail -- must execute WMLScript, their own, incompatible profile of ECMAScript.

WAE and WTA Servers. Together, these specifications form the Wireless Application Environment (WAE). A WAE server is roughly equivalent to a Web server or proxy. Wireless Telephony Application servers are built on top of WAE, but represent telephone switches instead. To the degree it handles call signaling and user interfaces to conference calls, etc. it diverges from IETF's Session Initiation Protocol and other Voice-over-IP efforts.

This NIH attitude requires an incredible amount of engineering effort to follow through. However, the commercial demand has proved sufficient to recreate most of the technology described above. WAP Forum is issuing conformance statements (and, eventually, branding); UP has established a WAP interoperability laboratory; and carriers are signing contracts with integrators. WAP is already a success for the near term.

Once deployed, the spotlight shifts to subscribers for 2000. Toeing the industry line that novice users won't expect to surf the Internet, initial product plans focus on built-in applications, hybrid Web-WAP portals, and limited Web access. UP.Sm@rt is already available for carrier-hosted WML-based datebook, phonebook, and memo pad applications. Nextel Online with Netcenter is an example of the second offering: enter your appointments and stock portfolio into a Web page, and UP.link will update you on the go. The last category includes reformatted news and adapters for critical Web forms. UP's S-1 filing lists "ABCNews.com, Bloomberg, Reuters, Quote.com, ESPN Sportszone and Travelocity," for example.

How satisfied will customers be in this pasture? These plans do not raise hopes for a grassroots movement of Web sites available in WML format; not even tools easy enough for corporate IS/IT departments to port mission-critical applications to it (see Section 2.6). A phone will essentially be tied to whatever services the carrier hosts when WAP standards fail to take hold on the Web.

How satisfied will carriers be? Carriers won't enjoy running application servers and their tech support. They don't want to miss out on the potential minutes lost because Web content isn't available, either. Look for WAP contracts to include "traditional" wireless data, too: the targeted high-end business customer is precisely the demographic that can also leverage the phone as an IR modem or mobile IP node.

How satisfied will manufacturers be? The entire goal of the microbrowser enterprise is to utterly homogenize handsets -- not just at the user interface, but programmer interfaces as well. Manufacturers don't like selling commodities, which is why so many are hedging their bets with Symbian, WirelessKnowledge, or Mobile NCs. They're planning ahead for HTML microbrowsers, active content, and multimedia -- to break out of the 2-10 line text display WML is predicated upon.

How satisfied will standards committees be? There is an immense investment in each of the existing standards WAP has cribbed from. Conflicts will surface as soon as WAP attempts to promulgate its standards as any but de facto. At IETF, the network layer will remain TCP/IP, tuned for "long, thin pipes". At W3C, the application layer will remain HTTP, XHTML, and DOM. At ECMA/ISO, the scripting language will remain ECMAScript. At ICANN, IANA will not take over registries created by the WAP Interim Naming Authority (WINA).

The bottom line is that WAP is a wrapper around present-day phones and pagers. It will bring a modicum of 'open systems' to the wireless market through interchangeable phones and information services, but it does not appear to have the headroom for truly diverse Internet information services and radically more capable devices. The network effects of treating a phone as just another, albeit dumb, HTML browser, and a just another, albeit slow, TCP/IP device could easily trump all the marginal performance improvements WAP touts.

This report will argue that WAP should be adopted cautiously. WAP is simply not the long-term answer, and the more it is seen to be immediately inevitable, the longer it will take the wireless-data industry to eventually dig out from that hole.

There is a core myth of 'standards-compliance' at the heart of WAP waiting to be discredited in the press and at several standards bodies. WAP Forum takes pains to appear cooperative, issuing joint white papers with W3C and predicting future iterations of HTML will support WML constructs; XML will adopt a standard binary encoding; HTTP-ng will look like WSP; WTLS's cryptography will be accepted for TLS; and so on.

Another benefit of WAP is that it's based on existing Internet standards. For example, the Wireless Markup Language specification portion of WAP is based on the HDML (Handheld Device Markup Language) specification and is an XML (Extensible Markup Language)-based language. Microbrowser technology based on WAP allows each handheld device to decide how to best display information received from a server.

Instead, the technical public will eventually become aware of the technical issues raised in this report. In particular, these issues will be raised (constructively) at the venues WAP overlaps (Section 4), addressing potential divergence sooner rather than later.

Numerous IETF working groups are addressing long, thin, networks, as well as W3C working groups on XML and HTTP -- a credible reply to WAP's claims of exceptionalism ('wireless is different').

As for Unwired Planet it's worth noting that they know they have a narrow window of opportunity to catapult themselves to the head of the line, and they're not afraid of sticking premium prices to carriers. It's a lucrative market if it's still around in two years.

At first glance, WAP's architecture appears cleanly layered, inheriting from the OSI and Internet models. The rub is in their claim that it's parallel to the existing Web/TCP/IP stack, as they do in the following slide:

In this section, we present the component specifications of the Wireless Application Environment (WAE) and the Wireless Telephony Application (WTA). We discuss the intent of each WAP proposal, its equivalent 'control' technologies, and relevant market stakeholders.

Internetworking requires interoperable error reporting: a bedrock standard for signaling erroneous addresses, link congestion, and higher-level protocol errors (bad port number, etc). Internet Control Message Protocol (ICMP) thus became the very first step in the transformation of ARPAnet into the Internet.

WAP needs to operate across widely varying airlink "networks", so it also specified an equivalent WCMP. However, no individual carriers are multiprotocol, so there isn't any internetworking going on at all in the WAP market. Because most packet data airlinks include their own error-correction and dropout detection at a lower layer, WCMP is largely irrelevant.

WCMP is not included in the current WAP/1.1 revision. Although WDP/1.1 still references the WAP/1.0 edition as a SHOULD, none of the 20 current airlink adaptations in Section 5.4 of WDP require its use. WCMP is incompatible with ICMP.

The official rationale is that "The Wireless Control Message Protocol (WCMP) provides an efficient error handling mechanism for WDP, resulting in improved performance for WAP protocols and applications." WCMP specifies several error codes, which differ from ICMP. WCMP also allows GSM, Flex and ReFlex addresses instead of IP numbers.

"WCMP Type values are different from ICMP Type values. WCMP Type values have been selected by adding 50 to the respective ICMP Type. WCMP Codes are the same [as] in ICMP."

WDP is roughly equivalent to UDP. In fact, carriers running mobile IP to the handset (CDPD, iDEN, or circuit-switched PPP) MUST use UDP instead. As with WCMP, the only rationale for reinventing a parallel format was to accommodate airlink addresses ("MSISDN number [handset serial number], IP address, X.25 address or other identifier") and airlink restrictions on packet size and even character sets.

The services offered by WDP include application addressing by port numbers, optional segmentation and reassembly and optional error detection. The services allow for applications to operate transparently over different available bearer services.

Of course, when they do, IANA will likely bounce half their applications right back, because IESG policy now forbids allocating parallel port numbers for "secure version of X". Basic protocols must be capable of negotiating security upgrades of the same port

WAP is in the process of registering ports for applications in the WAP space. However, at the moment no applications to IANA have yet been made and ports from the Dynamic/Private range are defined. These temporary ports will be changed when ports from the registered range are approved.

The first slide in this section claimed that WDP is somehow similar to TCP. This is simply not true: that depiction papered over an inconvenient misalignment of security architectures. The classic Internet stack offers security at the packet- and transport-layers with two separate technologies, IPsec and TLS respectively. WTLS (mis)applies TLS to both individual datagrams and socket connections.

This conflation is only possible because of a deeply embedded assumption that a handset always talks to a single, permanent WAP Gateway. Otherwise, there wouldn't be an advantage to negotiating a single master secret to these different modes -- and it would be impossible to also buffer against lost, duplicated, and reordered packets. Yes, that's right: WAP Forum has TLS doing TCP's job!

Both datagram and connection oriented transport layer protocols must be supported. It must be possible to cope with, for example, lost, duplicated, or out of order datagrams without breaking the connection state.

Since encrypted data cannot be compressed, this layer (like TLS) also provides compression services -- but since it's below the transport, Class 2 and 3 implementations run the risk of double-compression. It's not just the performance loss of recompressing WML/WTP content; it's the possibility of cryptoanalytic weakness since WAP's upper layer compression is not just gzip, but a very predictable tokenization (WBXML).

WTLS defines three levels of security capabilities; only Class 1 is mandatory-to-implement.

WTLS also specifies use of UP partner Certicom's elliptic curve public key encryption. Elliptic curves are more efficient to computer, but not as broadly implemented as stock RSA. This ciphersuite has not been documented on the IETF standards-track either.

To be sure, an RSA key exchange can take as long as 30 seconds on Palm Pilots and other low-power devices. If it's too expensive to have a public-key operation for every transaction, there will have to be a trusted proxy in the middle, effectively splitting the workload. ProxiNet was founded on this insight: devices authenticate themselves to a proxy server once, letting their proxy cluster handle multiple identities and SSL logons to Internet resources. The link itself only requires bulk encryption, a much smaller computational load. Thus, public key generation is done only once, at device provisioning.

It is unclear how effective current TLS ISV's experience will crossover to WAP's own WTLS implementations. Simply preserving the cryptosystems and handshakes aren't enough to directly reuse TLS libraries to implement WTLS.

Unlike in TLS, the record layer does not fragment information blocks. It is assumed that the transport layer takes care of the necessary fragmentation and reassembly.

For example, there are conflicting values for warning classes:

Upon careful comparison of the WTLS pdf files and the TLS Internet-Draft, new alerts were also added, for no clear reason:

Extending the confusion between network- and transport- layers in WTLS, WTP also solves a mix of transport- and application-layer problems. It is roughly equivalent to TCP, but without any notions of flow-control or windowing. WTP also adopts several tricks for fast-reestablishment and handshake-minimization to qualify as T/TCP-like (IETF's experimental-track Transactional TCP).

Furthermore, rather than simply expose a streams or socket interface, WTP offers three application message models that seem a lot more like RPC or remote method invocation than the Internet definition of "transport":

Class 0: Unreliable invoke message with no result message
Class 1: Reliable invoke message with no result message
Class 2: Reliable invoke message with one reliable result message

WTP optionally offers segmentation and re-assembly and selective acknowledgements, though much of that ought to remain the purview of lower-layer WDP.

At the same time, WTP radically redefines the meaning of "acknowledgement" to include explict user confirmation. That's like wiring e-mail style read-receipt into TCP.

"If the WTP user does not confirm the indication primitive after a specified time, the transaction is aborted by the provider. Note that this is a much stronger form of a confirmed service than the traditional definition [ISO8509]."

WTP imitated 16-bit TCP port numbering to differentiate the sorts of applications, outstanding concurrent requests, and the direction (using the low-order bit). They did not try more modern approaches such as hashing protocol URIs to map ports to services. WTP added individual transaction-ids, but issues them numerically and requires service in id-order, pessimistically forcing strict ordering in the face of missing or delayed segments.

WTP is the heart of an independent WAP Gateway server project, such as APiON's. The lower levels discussed so far can all be elided by choice of airlink and security level -- but WTP is the lowest layer the microbrowser absolutely requires.

This chapter describes how WTP relates to other WAP protocols. For a complete description of the WAP Architecture refer to [WAP]. The following table illustrates the where the services provided to the WTP user are located.

At this layer, again, WAP forum scrambles accepted definitions of networking terms. Wireless Session Protocol is actually intended to replace Hypertext Transfer Protocol. The IETF is currently investigating true session-layer support over TCP, with the goal of multiplexing several 'virtual' connections over a single "real" connection. That does not include negotiating upper-layer application protocols, data encoding syntax, or nomadic support for restarting sessions hours later. WSP does all that:

"a) establish a reliable session from client to server and release that session in an orderly manner;
b) agree on a common level of protocol functionality using capability negotiation;
c) exchange content between client and server using compact encoding;
d) suspend and resume the session."

On top of that, WSP also yokes together session-oriented and non-session-oriented services. It's the equivalent of a connectionless TCP -- and isn't that known as 'Reliable UDP,' one of the only cardinal sins in Jon Postel's book?

Thus, it's no surprise WAP Forum also liberally reinvented HTTP itself (while still using http: as WSP's URL scheme).

a) provide HTTP/1.1 functionality:
1) extensible request-reply methods,
2) composite objects,
3) content type negotiation;

b) exchange client and server session headers
c) interrupt transactions in process
d) push content from server to client in an unsynchronised manner
e) negotiate support for multiple, simultaneous asynchronous transactions."

They have added request headers for the sole purpose of being echoed back in the reply, presumably to let the handset avoid storing even the tiniest amount of per-transaction state (p. 14). They have not justified abandoning TCP RST/FIN (close) in favor of their own suspend/resume semantics -- are there observed usage statistics that motivate such complexity? Push can require human intervention to confirm, tying up connection state for very long intervals, potentially. There are several new code registries they arrogate management of (to their Wireless Interim Naming Authority, WINA):

In this context, covert-channel hacks like piggybacking time-of-day requests in nonstandard headers with nonsensical values make perfect sense:

"When the gateway receives a WSP method request that includes a header named X-WAP.TOD [with the value set to '0'], it will include that header in the response, with the header value set to the Gateway's current time of day."

This example is not even in the WSP document, but rather tucked away in an ancillary guide to reinterpreting HTTP/1.1 caching [UACaching-11-Feb-1999.pdf]. (Since handsets will barely manage even dozens of web resources in the next year, this seems premature.) Similarly, the rules for copying headers between messages on a stateful WSP connection are in yet a third document [WAEspec-17-Feb-99.pdf].

This clock callback is the kind of over-engineering indicative of telco-mindset overdetermined standardization. In IETF style, local clocks are just that: a platform-specific problem (and with timebases already encoded in virtually every airlink protocol, that would be just fine). Occam's Razor is wielded all too infrequently at WAP Forum.

At least this layer of WAP's specifications has a one-to-one correspondence to a real standard. However, rather than apply HTTP's zip/deflate compression options in WSP, WAP Forum devised a specific algorithm for XML content. WBXML tokenizes normal XML by preparsing it into a tree structure, extracting common text strings, and transmitting it according to a compression state machine at both ends.

The format is designed to preserve the element structure of XML, allowing a browser to skip unknown elements or attributes. The binary format encodes the parsed physical form of an XML document, ie, the structure and content of the document entities. Meta-information, including the document type definition and conditional sections, is removed when the document is converted to the binary format.

Though WBXML can be applied to merely well-formed XML documents, it does require a public Document Type Definition. The first payload byte encodes the DTD used, locking them into a WINA-controlled 255-slot registry for Formal Public Identifiers (FPIs, see Section 7.2 of the spec). In lieu of something smart, like hashing the FPI, they fixed codes 1, 2, and 3 to WML/1.0, WTA Events, and WML/1.1. Requiring DTD codes forecloses other XML Schema proposals from W3C that are expected to replace DTDs.

On other counts, they did refer to existing practice. So, rather than send the actual charset name, they save four bytes and send an IANA-registered charset numbers (originally only for ASN.1 SNMP MIB definitions, see Section 7.3 of the spec).

The general concept is that there are 255-slot code pages for tag, attribute name, attribute value, and other string tokens. Actual tag references use two high-order bits to encode the content model (empty or open) and presence of attributes, limiting it to 31 tags per code page. Nothing in WBXML speaks to WML's unilateral hijacking of the '$' character. If in fact WBXML was optimized for immediate internal representation, there would have to be hooks for $variable references in the tree.

WML files encoded by the different Encoders appear to be compatible, or least can be made compatible by tweaking the WML source. It only on minor points that incompatibilities arise. However, also these minor points can make a WAP application unusable for an end user.

Claiming that "verbose markup… 1. Wastes network bandwidth and 2. Wastes cache memory", Peter King of Unwired Planet argued for W3C endorsement of WBXML -- though no performance numbers from WAP Forum have ever justified those claims.

W3C's Martin Dürst correctly replied that generic compression should offer comparable or better results without wiring the format to a specific DTD, and that cache representation is an entirely implementation-dependent problem. WBXML can't be pipelined (streamed), to boot: it places a common string table in the preamble -- which wastes precisely the most latency-contributing early bits (streaming delivery allows rendering to begin as soon as the first packet is received).

Nevertheless, these factors torpedo WBXML as a general-purpose solution, isolating WAP-compliant tools further. Furthermore, W3C has chartered an XML Internal Set WG precisely to investigate common in-memory representations and XML Linking to consider online-access to remote XML trees -- and W3C also owns the trademark to XML…

Unwired Planet's initial products introduced "Handheld Device Markup Language," which lives on today in XML-ized form as WAP Forum's 1.1 release of Wireless Markup Language. HDML, however homophonic, has very little relationship to HTML, though. It is ideally suited to today's multiline handset displays -- too perfectly.

WML exposes a flat context (ie, a linear non-nested context) to the author. Each WML input control can introduce variables. The state of the variables can be used to modify the contents of a parameterised card without having to communicate with the server. Furthermore, the lifetime of a variable state can last longer than a single deck and can be shared across multiple decks without having to use a server to save intermediate state between deck invocations.

The last part of that quote also refers to WML's ability to 'parameterize' a deck. If, say the only part of a customer-service deck that changes is the name and account number, a WSP server can vend a single resource and let the client substitute those bits of state. Their claims of cache efficiency and reduced traffic are fallacious, since such a deck isn't shared at the handset; it's only shared at the server, which is perfectly capable of computing a custom deck with a CGI script.

WML uses an enhanced, explicit event binding model. There are three ways to establish an event binding in WML. These mechanisms bind events to explicit tasks (the actions to be taken in response to the event).

• The <a> element creates an anchor in a span of text (similar to HTML). When the anchor is activated, the task bound to the <a> element is executed.
• The <do> element binds a task to a card-level user-interface object and allows the display attributes of that user-interface object to be specified. When that user-interface object is activated, the task bound to the <do> element is executed.
• The <onevent> ("on event") element binds a task to an intrinsic event of its enclosing element.

Within each event binding, the author may specify a task to be performed. In WML 1.0, the defined tasks are:

• <go>--visit an identified resource
• <prev>--return to the previous resource in the history list
• <refresh>--redisplay the current resource
• <noop>--do nothing

Needless to say, all these features interact with each other. The result is dramatically different from HTML:

12.5.1 The Go Task

The process of executing a go task comprises the following steps:

1. If the originating task contains setvar elements, the variable name and value in each setvar element is converted into a simple string by substituting all referenced variables. The resulting collection of variable names and values is stored in temporary memory for later processing. See section 10.3 for more information on variable substitution.
2. The target URI is identified and fetched by the user agent. The URI attribute value is converted into a simple string by substituting all referenced variables.
3. The access control parameters for the fetched deck are processed as specified in section 11.3.1.
4. The destination card is located using the fragment name specified in the URI.
   a) If no fragment name was specified as part of the URI, the first card in the deck is the destination card.
   b) If a fragment name was identified and a card has a name attribute that is identical to the fragment name, then that card is the destination card.
   c) If the fragment name can not be associated with a specific card, the first card in the deck is the destination card.
5. The variable assignments resulting from the processing done in step #1 (the setvar element) are applied to the current browser context.
6. If the destination card contains a newcontext attribute, the current browser context is re-initialised as described in section 10.2.
7. The destination card is pushed onto the history stack.
8. If the destination card specifies an onenterforward intrinsic event binding, the task associated with the event binding is executed and
9. If the destination card contains a timer element, the timer is started as specified in section 11.7.
10. The destination card is displayed using the current variable state and processing stops.

At the same time, the WAP suite does not specify the exact behavior of a WML User Agent. Some guidelines are in Section 5.1.5 of WML and throughout WMLScript. Part of the variability is display size: HDML had to be reengineered so WML could display multiple cards per screen on palmtops. Thus, for the first time a single card could contain multiple input controls.

On the other hand, they explicitly rejected the Web-normative way to handle UA- and content-specific formatting: WML does not support any form of style sheets.

WBMP was quietly slipped into Section 6 and Appendix A of [WAEspec-17-Feb-99.pdf] in WAP/1.1. They have created a new image format inspired by -- but not even interoperable with -- W3C and ISO-standard Portable Network Graphics (PNG). It can support multiple bit planes, palettes, animation, and compression algorithms. For good measure, though, WBMP is only currently defined for Type 0: one-bit, uncompressed icons. All that overengineering in lieu of standard (and dead-simple) X Bitmaps (XBM)…

Lightweight vector graphics ought to be a very useful format for small-scale, variable-geometry displays. There is no mention of W3C's Scalable Vector Graphics WG or existing standard Computer Graphics Metafile (CGM). Current state-of-the-art already embraced FAX viewing on handsets, but G3 TIFF is also absent.

They also botched the usage of image references in WML. The lowsrc approach has been long discredited and never became part of standard HTML. As for offering an alternate local namespace, the handset should simply cache it by URI -- the phone itself will know it has "/images/smiley.gif" onboard by cache etag. 

Many handheld devices have a set of small images, or icons, that are used by the native user interface or the browser application. By using the "localsrc" attribute of the WML <img> element the author can re-use those images without having to download new ones. The purpose is similar to that of the HTML "lowsrc" attribute: to save time and bandwidth.

WAP Forum's scripting solution is specified in two parts: WMLScript, "its lexical and syntactic grammar, its transfer format and a reference bytecode interpreter," and the Standard Libraries, " including a language library, a string library, a dialog library, a floating-point library, a browser library and a URL library."

WMLScript is not fully compliant with ECMAScript. The standard has been used only as the basis for defining WMLScript language. The resulting WMLScript is a weakly typed language. Variables in the language are not formally typed in that a variable’s type may change throughout the lifecycle of the variable depending on the data it contains. The following basic data types are supported: boolean, integer, floating-point, string and invalid. WMLScript attempts to automatically convert between the different types as needed. In additions, support for floating-point data types may vary depending on the capabilities of the target device.

WAP Forum has devised yet another tokenization format for 'compiling' WMLScript over the air. URI semantics have been bent to allow special fragment-identifiers to link to WMLScript function calls instead of web resources.

The result is incompatible SDKs, much less devices in the field. DSR' survey again comments:

The Ericsson WMLScript compiler handles variable on the stack in a different way than Nokia's or DSR's WMLScript compilers (and WMLScript VMs). The WAP specifications are actually not very clear on this point. Initial contacts with Ericsson and representatives from WP Forum suggest that both are aware of this problem.

From a network operator's perspective a 'microbrowser' brings a consistent look and feel to value-added information services. WTA brings the same consistency to handset telephony services. A carrier could publish common WML decks for initiating calls, transferring calls, answering or forwarding calls, arranging conference calls, checking voice mail, and two-way paging for its entire subscriber base, reducing customer support costs for all its supported handsets.

WTA provides telephony-specific extensions for call control features, call logging, paging, address book, and phonebook services. It accesses the underlying call signaling of various airlinks. There are specific adaptation layers for features specific to GSM, IS-136 (TDMA), and Pacific Digital Cellular (PDC).

WTA user interfaces are a superset of WAE with push delivery. WTA calling features can be accessed as WMLScript function calls or by resolving URLs representing those function calls.

unlike a typical WML user agent, the WTA user agent has a very rigid and real-time context management component. For example, the user agent drops outdated (or stale) events, does not place intermediate results on the history stack, and typically terminates after the event is handled.

Within the WTA framework, the client and server co-ordinate the set of rules that govern event handling via an event table. WTA origin servers can adjust the client’s rules by pushing (or updating) a client’s event table if required 

This section describes the key players and strategic choices WAP raises for several sectors: manufacturers, operating systems, carriers, gateways, and content providers.

WAP Forum was co-founded with three manufacturers representing the vast majority of handset sales today. By now, 90% of handset capacity is represented at the Forum, and 75% of that capacity has committed to shipping some form of WAP-compliant phone -- over 20 manufacturers licensing UP.browser alone. Some shipping examples include the NeoPoint 1000 from Lucky Goldstar, the Motorola i1000+, and the Nokia 7110.

But to the degree the microbrowser sets the lowest-common-denominator interface to phones -- even potentially usurping manufacturer-specific UIs for telephony features -- WAP could become a value-destroying proposition. Homogenization is the first step to commoditization.

UP's offer of free UP.browser licenses fills a short-term gap in the product pipeline, but within 18-24 months, the premium providers will return to producing HTML microbrowsers in our opinion. Subsidized client software is not enough to lock-in global handset manufacturers

That explains why so many manufacturers are also hedging their bets. The same three vendors are partners in Symbian (below) and developing other phone concepts such as the Nokia 9000 line. Qualcomm, for example, is taking an opposite tack and pairing with a palmtop vendor to produce the pdQ.

The other strategic decision is the degree to which IP tone makes inroads in the market. Handsets that can double as infrared-linked IP links could be very successful with mobile professionals who also have laptops and palmtops. Microbrowsers become less important to such a device, but without the R&D cost of installing a full OS: let the heavy iron run the dancing hippo applets.

Ericsson-led Bluetooth and Motorola's Piano are less critical diversions. The interest in RF micro-scale networking does not obviate the need for wide-area WAP access. However, to the degree both systems are IP-centric, they reinforce the trend above. (Neither of these standards are particularly open; Bluetooth development kits run to $7,000)

The other side of the hardware market is in base stations and airlink equipment. Since WAP Gateways are designed to operate at a carrier's head-end data center, cellular base stations and telephone switches should not have to be altered. WTA servers will require close integration with switches, but through existing APIs defined by existing airlink signaling. Still, this is why Lucent, Siemens, and the like are joining WAP Forum in 1999.

A complete information-management solution on a handheld rapidly outgrows a microbrowser's cache-and-timers platform. A true operating system for low-power, low-resource devices can do a better job of rendering, filing, and synchronizing with PCs.

Psion's Symbian is producing an EPOC32-based operating environment for phones to palmtops to miniature laptops in partnership with Motorola, Nokia, NTT, IBM, Sun, and others. EPOC32 is aimed at ARM processors and graphic displays (rather than pure text devices). It provides true IP Web browsing and email, content translation, and even a Java VM. For this platform, retrofitting WAP support means installing a special-purpose network stack alongside TCP/IP and special-purpose browser. That's exactly what's promised, but we suspect that actual implementation of WAP hooks is not guaranteed, and not a priority.

WirelessKnowledge is an altogether different take on the problem: Microsoft and Qualcomm are focusing on the 'server-side' operating environment. Their goal is an Exchange-derived information routing system for corporate IS/IT. E-mail, faxes, group communications and such would be delivered to an outsource message server, then delivered back to mobile professional by PDA, phone, fax, or, recently rumored, WAP deck.

Microsoft’s WinCE is conspicuously absent from this sweepstakes. While telephony might be integrated into handheld computers running WinCE, the reverse does not seem likely. There are no signs WinCE will be adopted for handheld screenphones. Of course, even the Economist noted that "[Bill Gates] is said to regard Symbian as an even bigger threat than the DoJ."

PalmOS currently has several options for wireless Internet access. With a CDPD modem and a native TCP/IP stack, off-the-shelf PalmOS web, mail, and even telnet clients are available. For accessing standards-compliant Web content, though, it helps to offload content extraction, distillation, and security to proxy farms connected to the wired Internet.

ProxiNet got its start by splitting SSL and SSH to locate public key login operations on a trusted proxy and just encrypting the 'last mile' to a small device. They have since developed expertise in provisioning very large-scale, fault-tolerant proxy clusters and a 'building-block' software architecture for reprocessing pages.

AvantGo aims more specifically at push delivery to palmtops, but also offers proxy-based distillation.

Ericsson’s WebOnAir proxy is designed for any wireless IP device, but particularly Win9x laptops. It strips out metadata, insignificant whitespace, tidies up HTML, and optionally strips Java applets, JavaScript, downsamples graphics, and compresses the resulting stream.

Online.Anywhere focuses on the third aspect: intelligent content extraction. Customizable site profiles indicate what elements to extract from standard web pages for relayout on different devices (TV, phone, palmtop, etc). This approach brings to layout what webMethods' Web Interface Definition Language (WIDL) brings to data mining.

Carriers, as ever, need to sell more minutes -- in a soon-to-be-glutted market. With up to six competitors in a metropolitan area, expect serious price erosion in the US market. Churn rates are going to remain a dominant factor in profitability. If 'smartphones' can demonstrably add usage and lock-in users, carriers will flock to WAP.

As it is, though, many carriers are in wait-and-see mode at WAP, and in particular, with Unwired Planet. Amidst all the pilot products, there's little evidence of breakaway success. The larger national carriers are leery of moving first in this area.

Even so, Nextel Online is launching an innovative hybrid portal-phone service with Netscape and UP. The portal could aggregate general news, industry information, and local directories. More to the point, the user's portal is a control panel for subscribing to stock feeds, adding phone numbers, and scheduling meetings. All of these processes could link back to the phone: schedule alerts, news updates, handset access to the portal itself in WML format.

The strategic choices facing carriers are a classic telco ones: capital and reliability. It isn't cheap to acquire WAP Gateway software and proxy farms for operating it -- especially from the one vendor with any kind of operational experience.

UP, as outlined in its S-1 IPO filing, has placed the burden of profitability on the carrier end of its products. They're giving away the handset clients for virtually free, but charging carriers per subscriber. Not per UP.link-using subscriber, but for every device that could run UP.link. Only one carrier has had the negotiating clout to date to force UP to share the risk of subscriber adoption. Others may be paying fees in the millions of dollars for the server -- and several dollars per subscriber as well. Given that even two-line alphanumeric pagers can be considered WAP-capable, that can be quite a capitation.

In the longer-term, carriers stand to benefit from the handset homogenization manufacturers fear. UP's white papers for carriers, for example, sketch out the possibility of WML user interfaces for self-service billing and customer care, even provisioning an entire prepaid cellular account from a handset without human intervention.

Thus, carriers may even succeed without "Internet" access per se. While early adopters and heavy users may expect full integration with all possible Web sources, mass consumer markets may be satisfied with a limited menu of carrier-provided information services. Once a solid WAP marketplace exists, deployment may even make economic sense without any information services at all: just for making more abstruse calling features accessible and for phonebook management.

The final strategic lever in carriers' hands is choice of airlink. They are the final arbiters of whether IP-centric wireless data will prevail over WDP/WTP/WSP.

The point of establishing a WAP Forum was to catalyze the development of independent, interoperable implementations. UP, Ericsson, Nokia, APiON, and Dynamical Systems have all announced WAP Gateway servers; and IBM, HP, and Oracle are rumored to be interested a year or two further out.

These entrants could have rather diverse business models. UP must make its fortunes on software sales, but handset vendors may subsidize development to spur equipment sales and upgrades. Similarly for computer vendors, whose real motivation may be the Gateway cluster and service contracts. Other independents, like APiON, may make money on software sales simply by virtue of independence: the telecommunications industry is justifiably afraid of competitors buying suppliers.

The strategic question is how Gateway vendors choose to interoperate with existing Internet standards. Development could stop with WSP, leaving it to the carrier to actually produce WML/WMLScript content and update it. A full-service, Internet-oriented approach would yield a proxy farm capable of distilling any Web content -- but then again, perhaps not into WML, which is not well-suited to 'browsing'.

The ultimate end of the value chain is the origin site itself: what incentives will Web content providers have to publish handheld-savvy content? This is where the network effects of standardization are strongest. Ideally, content ought to be produced in XML and customized with Cascading and Extensible stylesheets to the various browsers out there. Then it's just a matter of adoption to judge when WebTV or WAP phones or voice-response boxes become popular enough to warrant publishing a new stylesheet.

Of course, the vast majority of content won't even be that flexible: at best it will be HTML4-compliant and perhaps follow the W3C's Web Accessibility Initiative Guidelines to ensure it's meaningful in text-only mode.

Carrier partnerships are at the other end of the spectrum. Providing custom, WML versions of news content or WML forms to services like travel agency, stock brokerage, and the like will only make sense at the outset if there is direct compensation in some form or another. Gateways, carriers, and providers will have to work together closely for at least 12-18 months before producing WML decks independently.

WML Developer's Kits are only emerging just now. WirelessDeveloper'99 will be the first conference of its kind this May, focusing on deploying horizontal and vertical applications over several wireless data solutions. 4,500 developers registered to download a copy of UP's SDK through the end of March, and similar numbers ought to be expected for Nokia and Ericsson's WAP IDEs.

There are no promises of standalone, nor open-source implementation of various WAP layers like WBXML, WMLScript, WSP, WTP, WTLS, or WDP that I know of. This is another serious practical impediment to the adoption of WAP Forum standards beyond the Forum.

At almost every juncture, faced by the choice of referencing existing Internet practice by reference or by copy, WAP Forum chose to copy -- and modify. And each standard copied into WAP's specification space is another organizational toe stubbed.

It’s a paranoid engineer's game to avoid the uncertainty of moving targets by copying a specification in order to freeze it, or to propose a special purpose solution that takes advantage of tricks legal across layers. This tendency resonates with a separate tendency to overspecify the system, which results in ever-larger, ever-more-complex specifications.

This paper has established the degree to which WAP Forum has specified its system -- far beyond merely establishing communication protocols and data formats. For example, it's not enough to stipulate that WSP transports MIME-formatted entities: there are special coders for XML, special format for icons, special rules for explicit-acknowledgment, and special user interfaces to vCards and vCalendar entries.

WAP Forum has consciously adopted this policy, and seems to be making little effort to redress it by promoting its revisions back to their original communities for further review. In other words, they appear to be hoarding change control.

The output of the WAE effort is a collection of technical specifications that are either new or based on existing and proven technologies. Existing technologies leveraged by the WAE effort include:

• Unwired Planet’s Hand Held Mark-up Language (HDML),
• World Wide Web’s Consortium’s (W3C) eXtensible Markup Language (XML) [14],
• World Wide Web’s Consortium’s (W3C) Hypertext Markup Language (HTML) [5],
• ECMA-262 Standard "ECMAScript Language Specification" [6] that is based on JavaScript™,
• IMC’s calendar data exchange format (vCalendar) [7] and phonebook data exchange format (vCard),
• A wide range of WWW technologies such as URLs and HTTP [8], along with
• A wide range of Mobile Network technologies such as GSM call control services and generic IS-136 services such as send flash.

The resulting WAE technologies are not fully compliant to all of the motivating technologies. Where necessary, modifications were made to better integrate the elements into a cohesive environment and better optimize the network interaction and user interface for small screen limited capability terminals that communicate over wireless networks.

Even WAP's standards-review process has been incompatibly cribbed together. Their maturity levels (Draft, Prototype, Proposed, Approved) correspond neither to IETF's (Internet-Draft, Proposed, Draft, Standard) nor W3C's (Note, Working Draft, Proposed, Recommended). Their documents include IETF definitions of MUST, SHOULD, and MAY, but do not share its commitment to IPR-freedom. Their documents are developed by dues-paying Members behind closed doors like W3C, but without a single public mailing list for discussion and review.

In the subsections that follow, we will examine WAP Forum's exposure to other bodies' institutional interests and its liason efforts, if any.

WAP Forum leadership clearly recognizes that the Web Consortium controls the greater part of the standards they rely upon, and have worked since June 1998 to nurture a working relationship. That dialogue culminated in a joint communiqué last September that merely stated areas of mutual interest. There is overlap at almost every level of the protocol stack, but the three most crucial future developments WAP Forum must leverage to remain relevant are 1) the migration to XHTML (nee HTML5), 2) Binary XML, and 3) next generation HTTP.

It is worth noting that the W3C Mobile Interest Group itself does not make that cut. Discussions in that forum to harmonize guidelines for 'compact' HTML4, capability negotiation with CC/PP, and other near-term changes have not made any joint progress.

Regarding XHTML, Unwired Planet helped edit a two-part input document exhorting that group to ensure WML-style state-management, tasks, and variable substitution would remain possible; and to ensure the event model could encompass WTA push events. Neither step is fairly likely, since W3C has enforced an architectural split between declarative markup language issues and operational Document Object Model issues. Almost everything in WML and WMLScript's model of an active client violates that separation.

What XHTML is doing will create a formidable competitor to WML. The Web Consortium is working to recast HTML as a set of XML modules with more clearly structured FORMs and TABLEs; and navigation aids which enable accessibility in a broad sense: for print, audio-only, and other disabilities -- and thus also for small devices. Combined with XSL 'behavior sheets', W3C has already mapped out a migration path to alternative user interfaces and devices. That path makes it easier to envision reliable distillation proxies

Regarding the evolution of HTTP, W3C is pushing the Mandatory extension mechanism to HTTP/1.1, an RDF-based Composite Capability/Preference Profile (CC/PP) content selection framework, and a message multiplexing (MEMUX) session layer. W3C is not in a position to adopt the scrambled WTLS/WTP/WSP substack as a replacement for HTTP. Nor has WAP Forum acted on literally years of advance warning that the W3C HTTP-NG project was aimed precisely at low-bandwidth and wireless devices and its likely architecture. As it stands, there is no possibility of session-layer interoperability, the Mandatory scheme has been rejected by WAP Forum, and the debate between User-Agent and CC/PP (and, for that matter, IETF CONNEG) content negotiation has come to a standstill.

Regarding XML, W3C has separately chartered a working group to recommend a common internal representation (beyond the tree structure already implicit in DOM). It has evinced no interest in custom binary-coding of XML, referring instead to the potential for general-purpose compression as demonstrated in its research papers and code library. Since W3C owns the XML trademark, it may even be in a position to take a more critical view of WAP Forums pseudo-standard. It's not just a product, for which W3C grants use, but a competing definition of XML at stake.

The IETF has a massive investment in adapting TCP/IP to 'long, thin networks,' as cellular links are known. There are several research groups focused just on optimizing TCP for radio links, ranging from TCP over Satellites to Mobile Ad-Hoc Networking, which posits handsets as routers.

"Non-IP alternatives face the burden of proof that IP is so ill-suited to a wireless environment that it is not a viable technology." This is one of the most hotly debated issues in the wireless arena. Here are some arguments against it:

• It is generally recognized that TCP does not perform well in the presence of significant levels of non-congestion loss. TCP detractors argue that the wireless medium is one such case, and that it is hard enough to fix TCP. They argue that it is easier to start from scratch.
• TCP has too much header overhead. 
• By the time the mechanisms are in place to fix it, TCP is very heavy, and ill-suited for use by lightweight, portable devices.

and here are some in support of TCP:

• It is preferrable to continue using the same protocol that the rest of the Internet uses for compatibility reasons. Any extensions specific to the wireless link may be negotiated.
• Legacy mechanisms may be reused (for example congestion control)
• Link-layer FEC and ARQ can reduce the BER such that any losses TCP does see are, in fact, caused by congestion (or a sustained interruption of link connectivity). Modern W-WAN technologies do this (CDPD, US-TDMA, CDMA, GSM), thus improving TCP throughput.
• Handoffs among different technologies are made possible by Mobile IP [RFC2002], but only if the same protocols, namely TCP/IP, are used throughout.
• Given TCP's wealth of research and experience, alternative protocols are relatively immature, and the full implications of their widespread deployment not clearly understood.

There is active interest in developing session-layer multiplexing over TCP as well. A Requirements for Unicast Transport Session (ruts) BOF was held in December 1998 and a Support for Lost of Unicast Multiplexed Sessions (SLUMS) BOF was held in March 1999. Another half-dozen proposals have emerged in this area, not least of which is W3C's MEMUX. This community is looking for efficient concurrent sessions between hosts as well as fast-setup and teardown -- subsuming parts of WTP and WSP.

And while there is interest in wireless/nomadic application support (such as disconnected IMAP4 email), IETF is not likely to evince much interest in scripting, markup, or graphics formats.

As apathetic as IETFers may seem at the top of the stack, the sense of attendees we spoke to recently was very negative about WAP Forum's low lever redefinitions.

Section 2 of this paper described a series of registries embedded in WAP specifications. As of October 1998, WAP Forum decided to centralize those registries under a WAP Interim Naming Authority (WINA). Its charter, [WINA-process.doc] states its relationship to IANA (soon to be part of ICANN) thusly:

The Internet Assigned Numbers Authority already manages a number of name and code spaces. These include… Content Types, Port Numbers, [and] Character Sets

WINA is a complement to IANA, and deals with spaces not presently administered by IANA. These are either unique code spaces, or special encoding of already known name spaces.

While it's admirable WAP Forum will ratify an open process to maintain WAP-specific registries, it has not always been clear why they have chose to recode existing namespaces (WCMP Type codes, numbering ISO charsets, numbering FPIs), and encouraging centralized registries where URIs would do (header fields, WMLScript Library IDs). Furthermore, it does not appear WINA has duly attempted to register what should be at IANA with IANA, such as TLS chiphersuite codes, HTTP methods, and WTP port numbers.

While IANA is a purely reactive institution (it runs registries according to definitions in Internet Standards with policies set by the IESG), it does not serve anyone's interests to duplicate -- or approximate -- its work.

These three bodies are involved in the ECMA-262 standardization and evolution process. It does not appear WAP Forum consulted any of them regarding its publications of a derivative language "…not fully compatible with ECMAScript…" The remainder of this section considers the role of the US National Committee for Information Technology Standards (NCITS, formerly X3).

The closest to web standards NCITS has come is PNG and VRML. PNG is relevant insofar as WBMP defines another binary icon format that's very PNG-like in its extensibility. There is no reason to expect NCITS to take action here, though.

Similarly, though they have a role in Java and ECMAScript standardization, the dormancy of the scripting Technical Committee in particular does not indicate it will become a flashpoint for debate.

WBXML, though, will probably come to a halt here. To the degree their members represent the conventional wisdom of SGML, there is incredible importance placed on preserving the actual stored form of data, and not as much on interactive access. This will come to a head if V1 ever does tackle a tokenized XML -- which in turn would be unlikely unless W3C submits its own work in this area.

There is no Wireless work per se in any Technical Committee at present.

MNCRS mandates TCP/IP over PPP, optionally including NFS, FTP, and Telnet, while looking ahead to IPsec encryption & authentication. The middleware layers are heavily dependent on JavaSoft APIs for directories, user interface, smart cards, and so on. Upper layer application support includes a phonebook API, for example -- but as an arbitrary database it seems too rich for GSM SIM card phone lists and too unstructured for Internet Mail Consortium's vCards (as used by WAP Forum).

The intent, though, is to standardize the lower, not the upper layers. While WAP Forum is seemingly intent on describing a single class of device -- the multiline text handset -- Mobile NCs are a horizontal platform for any sort of Internet client.

As mentioned above, WAP Forum references the Internet Mail Consortium's documents describing vCard contacts and vCalendar schedules. IMC is committed to releasing their work as IETF standards, so there should be no problem citing them.

To the degree industry groups like the European Telecommunications Standards Institute (ETSI) and Universal Mobile Telecommunications System (UMTS) Forum touch upon mobile Internet services, it's to reaffirm IP as the fundamental data service of the future. We don't believe WAP can flourish over IP networks in the long-term…

WAP Forum cooperates with several other airlink interface bodies: "the Association of Radio Industries and Businesses (ARIB), Code Division Multiple Access Development Group (CDG), …Telecommunications Industry Association (TIA), Universal Wireless Consortium (UWC) and Telecommunications Technology Committee (TTC)." These relationships do not touch upon our concerns about WAP’s architecture, though.

There have been comments at the last W3C Mobile Workshop regarding an "ETSI MEXI" working group and an "Internet Screen Phone" reference group. No further details can be confirmed at this time.

Despite the growth in numbers, one analyst remained skeptical about the long-term viability of WAP. Jane Zweig, senior vice president with Herschel Shosteck Associates Ltd. of Wheaton, Md., said she believed the companies joining the WAP Forum are "hedging their bets."

She said the membership fee was small change for companies that wanted to make sure they participated in wireless access to the Internet. In a recent report on WAP, Zweig said the standard is too limiting because it filters out much of the data available on the Internet so that it be accessed by voice-centric handsets.

Zweig's report said a data-centric approach using handheld computers or personal digital assistants ultimately will provide the kind of full Internet access the broad market wants.

"Although the point is content delivery, WAP will likely fail to provide a meaningful content experience for the mass-market end user," Zweig said.

She added that WAP likely will fill a valuable short-term niche.