WAP 2.0 is a family of specifications for mobile web applications and related services. It brought Internet protocols and XHTML-based content into an environment designed for small displays, limited memory, and constrained wireless links. Reading a WAP feature list becomes easier when you separate the browser, the network transport, and any intermediary proxy.
Ask which layer a feature belongs to
| Layer or function | What it supplies | What to identify |
|---|---|---|
| Application environment | Content formats and browser behavior. | Supported markup, images, style sheets, and scripting. |
| Communication protocols | Requests, responses, sessions, and transport. | The stack actually used by the device and network. |
| Proxy or gateway | Intermediary functions such as protocol adaptation or optimization. | Its role and whether this request path requires it. |
| Additional services | Functions such as push and multimedia messaging. | The relevant client, server, and service configuration. |
The WAP Architecture specification describes an extensible framework for these functions. Its motivation includes the limited processing, memory, display, input, and power resources of contemporary handheld devices. Those constraints explain why a desktop page could need different content or presentation on a phone.
Draw two possible request paths
The WAP Forum's January 2002 WAP 2.0 white paper explicitly describes the browsing proxy as optional: a client can communicate with an origin server using HTTP/1.1. It also describes the proxy's possible optimizations and the separate proxy role in push. Read the relevant service architecture before assuming that one diagram represents all WAP traffic.
The Wireless Profiled HTTP specification defines how HTTP is used in this environment, including proxy behavior and tunneling. An end-to-end connection and a connection terminated at an intermediary have different boundaries. For a historical system, establish those boundaries from its configuration and documentation.
Compare the transition without erasing compatibility
Earlier WAP deployments commonly used WML content and a wireless-oriented protocol stack with layers such as WSP and WTP. WAP 2.0 added support for an Internet-based stack with TCP, TLS, and HTTP, while retaining support for the earlier stack. Its application environment introduced XHTML Mobile Profile and associated style-sheet support, alongside approaches for existing WML content.
That transition was broader than a new page format. A browser could support a particular markup language while the network used a particular transport arrangement. “WAP 2.0” therefore needs follow-up questions about implemented features and configuration.
The OMA WAP specification archive groups the conformance release by functional area, including browsing, provisioning, push, and MMS. MMS has its own architecture and transaction specifications. A phone's picture-messaging capability and its browser behavior deserve separate checks.
Inspect an old service one dependency at a time
- Record the exact phone, browser version, supported content formats, and documented service settings.
- Identify the content: a saved WML document, an XHTML page, an image, or a service address. Preserve an original copy before experimenting.
- Draw the configured request path, including any required proxy and the origin server.
- Record the result at the smallest observable stage: file opened, markup rendered, connection attempted, response received, or content rejected.
- Separate content compatibility from the availability of an old carrier portal, proxy, or server.
Use an isolated demonstration with non-sensitive content for historical experiments; current credentials belong on supported software. For present-day browser problems, use mobile browser troubleshooting. For downloadable applications, compare BREW and Java ME MIDlets.