A comparison of the WAP 1 standard and Wap 2 draft:
Original document: WAP1
Revised document: WAP2
Deletions are shown with the following attributes and color:
Strikeout, Blue RGB(0,0,255).
Deleted text is shown as full text.
Insertions are shown with the following attributes and color:
Double Underline, Redline, Red RGB(255,0,0).
The document was marked with 161 Deletions, 159 Insertions, 0 Moves.
WAP-210-WAPArch
Proposed Version 17-October-2000
Wireless Application Protocol
Architecture Specification
1. Scope
This version of the WAP Architecture continues the themes and builds on the successes of the initial WAP architecture.
Network elements remain similar in function. For example, the architecture uses performance and feature-enhancing
proxies to offload processing from constrained devices, to expose features and functions of the wireless network, and to
provide for network and service management. This version of the architecture has been enhanced to allow for a broader
selection of connection paths between clients and origin servers as necessary, for example to provide end-to-end
security..
5. Background
5.1 Motivation
WAP is positioned at the convergence of twothree rapidly evolving network technologies, wireless data, telephony, and the
Internet.
· Secure - enables services to be extended over potentially unprotected mobile networks while still preserving the
integrity of user data; protects the devices and services from security problems such as denialloss of serviceconfidentiality.
The nature of wireless devices is that they are inherently mobile. This mobility introduces new opportunities for
services that are sensitive to mobility and can provide location-dependent information. The WAP specifications and
architecture capitalise on this unique aspect of wireless devices by including mobility as part of the application model.
The requirementsThe WAP specifications will accommodate a range of devices, from devices that provide very basic functionality to
devices that continue to expand their capabilities. This motivates an architecture where functionality may be moved to
different locations within the network as appropriate, i.e. either to devices or to network servers as necessary.
5.2 Architectural Goals
The goals of the WAP Forum architecture are to: · Leverage existing standards where possible;.· Define a layered, scaleable and extensible architecture; · Support as many wireless networks as possible; · Optimise for narrow-band bearers with potentially high latency; · Optimise for efficient use of device resources (low memory/CPU usage/power consumption); as follows. This summary is informative and non-exhaustive; the order
of the items does not represent any priority or importance.
· Provide a web-centric application model for wireless data services that utilises the telephony, mobility, and other
unique functions of wireless devices and networks and allows maximum flexibility and ability for vendors to
enhance the user experience.
· Enable the personalisation and customisation of the device, the content delivered to it, and the presentation of the
content.
· Provide support for secure and private applications and communication; · Enable the creation of Man Machine Interfaces (MMIs) with maximum flexibility and vendor control; · Providein a manner that is consistent and
interoperable with Internet security models.
· Enable wireless devices and networks that are currently or in the near future being deployed, including a wide
variety of bearers from narrow-band to wide-band.
· Provide secure access to local handset functionality, such as logical indication for incoming call; .
· Facilitate network-operator and third party service provisioning; · Support multi-vendor interoperability by defining the optional and mandatory components of the specifications; and · Provide a programming model for telephony services and integration...
· Define a layered, scaleable and extensible architecture.
· Leverage existing standards where possible, especially existing and evolving Internet standards.
6. Architecture Overview
6.1 The World-Wide Web Model
The WWW protocols define three classes of servers: · Origin server - The server on which a given resource (content) resides or is to be created.
· Proxy - An intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. The proxy typically resides between clients and servers that have no means of direct communication, eg across a firewall. Requests are either serviced by the proxy program or passed on, with possible translation, to other servers. A proxy must implement both the client and server requirements of the WWW specifications.
Gateway - A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource.The requesting client may not be aware that it is communicating with a gateway.
6.2 The WAP Model
The WAP programming model (Figure 2) is similar tothe WWW programming model with a few enhancements. Adopting the
WWW programming model. This provides several benefits to the application developer community, including a familiar
programming model, a proven architecture, and the ability to leverage existing tools (eg, Web servers, XML tools, etc.).
The most significant enhancements WAP has added to the programming model are:
· Push
· Telephony Support (WTA)
The classical request-response mechanism is commonly referred to as pull to contrast it with the push mechanism.
6.3 Feature/Performance-Enhancing Proxies
WAP utilises proxy technology to connectoptimise and enhance the connection between the wireless domain and the WWW.
The WAP proxy typically is comprisedmay provide a variety ofthe following functionalityfunctions, including:
· Protocol Gateway - The protocol gateway translates requests from the WAPa wireless protocol stack (WSPe.g., the WAP 1.X
stack--WSP, WTP, WTLS, and WDP) to the WWW protocol stack (HTTP and TCP/IP).The gateway also
performs DNS lookups of the servers named by the client in the request URLs.
· Content Encoders and Decoders - The content encoders translate WAP content into compact encoded formats to
reduce the size of data over the network.
· User Agent Profile Management - User agent profiles describing client capabilities and personal preferences
[UAProf] are composed and presented to the applications.
· Caching Proxy - A caching proxy can improve perceived performance and network utilisation by maintaining a
cache of frequently accessed resources.
It is possible to create an origin server that includes the WAP proxy functionality. Such a server might be used to facilitate end-to-end security solutions, or applications that require better access control or a guarantee of responsiveness, eg, WTA.
6.4 Supporting Servers
Figure 4. Supporting Services
The WAP Architecture also includes supporting servers, which provide services to devices, proxies, and applications as
needed. These services are often specific in function, but are of general use to a wide variety of applications.
The supporting servers defined by the WAP Forum include, but are not limited to:
· PKI Portal--The PKI Portal (shown in Figure 4) [WPKI] allows devices to initiate the creation of new public key
certificates.
· UAProf Server--The UAProf Server [UAProf] allows applications to retrieve the client capabilities and personal
profiles of user agents and individual users.
· Provisioning Server--The Provisioning Server [ProvArch] is trusted by the WAP device to provide its provisioning
information..
6.5 WAP Network Elements
In the example, the WAP clients communicates with two servers in the wireless network. The WAP proxy translatesapplication servers through a number of different proxies or directly. WAP clients
support the proxy selection mechanism that allows them to utilise the most appropriate proxy for a given service or to
connect directly to that service as necessary. Proxies translate WAP requests to WWW requests thereby allowing the
WAP client to submit requests to the web server.
The proxy also encodes the responses from the web server into the compact binary format understood by the client.
If the web server provides WAP content (e.g., WML), the WAP proxy retrieves it directly from the web server.
However, if the web server provides WWW content (such as HTML), a filter is used to translate the WWW content into WAP content. For example, the HTML filter would translate HTML into WML.
The Wireless Telephony Application (WTA) server is an example origin or gateway server that responds to requests from the WAP client directly. The WTA server is used to provide WAP access to features ofProxies may be located at the wireless carrier in order to provide feature enhancements coupled to the wireless network
provider's telecommunications infrastructure.
6.4(e.g., telephony, location and provisioning) or to optimise the communication between device and application server
(e.g., protocol translation and cookie caching). Proxies may be located in a secure network to provide a secure channel
between wireless device and the secure network.
In some instances, the device might make direct connections to application servers, for example to provide a secure
connection directly between the device and application server.
The supporting servers provide support functions required by or generally useful to devices, proxies, and application
servers. These functions include Provisioning, PKI, user agent profiles, etc..
6.6 Device Architecture
The architecture for WAP devices is shown in Figure 6. The Application Framework provides the device execution
environment for WAP applications. WAP applications are comprised of markup, script, style sheets and multimedia
content, all of which are rendered on the device. The WAP Application Environment (WAE) processing model defines
the structure in which these various forms of executable and non-executable content interact.
The network protocols on the WAP client are shared between client and server. They are described in further detail
below. Content renderers interpret specific forms of content and present them to the end user for perusal or interaction.
Common functions are defined to be utilised by the application framework, including persistence and data
synchronisation.
The Wireless Identity Module (WIM), as specified in [WIM], contains the identity of the device and the cryptographic
means to mutually authenticate WAP devices and servers.
The architecture also provides a mechanism to access external functions that are embedded or attached to the devices
via the External Functionality Interface (EFI).
6.7 Security Model
WAP can provide end-to-end security between WAP protocol endpoints. If a browser and origin server desire end-to- end end-to-end
security, they mustcan communicate directly using the WAP protocols. End-to-end security may also be.© security protocols. Moreover, the WAP specifications include
support for application-level security, such as signed text..
7. Components of the WAP Architecture
This is achieved through a layered design of the entire protocol stack (Figure 4)7). Each layer provides
a set of functions and/or services to other services and applications through a set of well-defined interfaces. Each of the
layers of the architecture is accessible by the layers above, as well as by other services and applications.
Application Layer (WAE) Application Layer (WAE) Session Layer (WSP) Session Layer (WSP) Security Layer (WTLS) Security Layer (WTLS) Transport Layer (WDP) Transport Layer (WDP) Other Services and Applications Bearers: Transaction Layer (WTP) Transaction Layer (WTP) GSM IS-136 CDMA CDPD PDC-P Etc... PHS iDEN FLEX Figure 4. WAP Architecture The WAPlayered architecture enables other services and applications to utilise the features of the WAP stack through a set of well-defined interfaces. External applications may access the session, transaction, security and transport layers directly. The following sections provide a description of the various elements of the protocol stack architecture.
7.1 Wireless Application Environment (WAE) The Wireless Application Environment (WAE) is a general-purpose application environment based on a combination of World Wide Web (WWW) and Mobile Telephony technologies. The primary objective of the WAE effort is to establish an interoperable environment that will allow operators and service providers to build applications and services that can reach a wide variety of different wireless platforms in an efficient and useful manner. WAE includes a micro-browser environment containing the following functionality: · Wireless Markup Language (WML) - a lightweight markup language, similar to HTML, but optimised for use in hand-held mobile terminals; · WMLScript - a lightweight scripting language, similar to JavaScript™; · Wireless Telephony Application (WTA, WTAI) - telephony services and programming interfaces; and · Content Formats - a set of well-defined data formats, including images, phone book records and calendar information.
A much more detailed description of the WAE architecture is provided in [WAEoview]..
Version 30-Apr-1998 Page 16 (20) 7.2 Wireless Session Protocol (WSP) The Wireless Session Protocol (WSP) provides the application layer of WAP with a consistent interface for two session services. The first is a connection-oriented service that operates above the transaction layer protocol WTP.
The second is a connectionless service that operates above a secure or non-secure datagram service (WDP).
The Wireless Session Protocols currently consist of services suited for browsing applications (WSP/B). WSP/B provides the following functionality: · HTTP/1.1 functionality and semantics in a compact over-the-air encoding, · Long-lived session state, · Session suspend and resume with session migration, · A common facility for reliable and unreliable data push, and · Protocol feature negotiation.
The protocols in the WSP family are optimised for low-bandwidth bearer networks with relatively long latency.
WSP/B is designed to allow a WAP proxy to connect a WSP/B client to a standard HTTP server. See [WSP] for more information.
7.3 Wireless Transaction Protocol (WTP) The Wireless Transaction Protocol (WTP) runs on top of a datagram service and provides as a light-weight transaction-oriented protocol that is suitable for implementation in "thin" clients (mobile stations). WTP operates efficiently over secure or non-secure wireless datagram networks and provides the following features: · Three classes of transaction service: · Unreliable one-way requests, · Reliable one-way requests, and · Reliable two-way request-reply transactions; · Optional user-to-user reliability - WTP user triggers the confirmation of each received message; · Optional out-of-band data on acknowledgements; · PDU concatenation and delayed acknowledgement to reduce the number of messages sent; and · Asynchronous transactions.
See [WTP] for more information.
7.4 Wireless Transport Layer Security (WTLS) WTLS is a security protocol based upon the industry-standard Transport Layer Security (TLS) protocol, formerly known as Secure Sockets Layer (SSL). WTLS is intended for use with the WAP transport protocols and has been optimised for use over narrow-band communication channels. WTLS provides the following features: · Data integrity - WTLS contains facilities to ensure that data sent between the terminal and an application server is unchanged and uncorrupted.
· Privacy - WTLS contains facilities to ensures that data transmitted between the terminal and an application server is private and cannot be understood by any intermediate parties that may have intercepted the data stream.
· Authentication - WTLS contains facilities to establish the authenticity of the terminal and application server.
· Denial-of-service protection - WTLS contains facilities for detecting and rejecting data that is replayed or not successfully verified. WTLS makes many typical denial-of-service attacks harder to accomplish and protects the upper protocol layers..© Copyright Wireless Application Protocol Forum, Ltd, 1998.
All rights reserved.
Version 30-Apr-1998 Page 17 (20) WTLS may also be used for secure communication between terminals, eg, for authentication of electronic business card exchange.
Applications are able to selectively enable or disable WTLS features depending on their security requirements and the characteristics of the underlying network (eg, privacy may be disabled on networks already providing this service at a lower layer).
See [WTLS] for more information.
7.5 Wireless Datagram Protocol (WDP) The Transport layer protocol in the WAP architecture is referred to as the Wireless Datagram Protocol (WDP).
The WDP layer operates above the data capable bearer services supported by the various network types. As a general transport service, WDP offers a consistent service to the upper layer protocols of WAP and communicate transparently over one of the available bearer services.
Since the WDP protocols provide a common interface to the upper layer protocols the Security, Session and Application layers are able to function independently of the underlying wireless network. This is accomplished by adapting the transport layer to specific features of the underlying bearer. By keeping the transport layer interface and the basic features consistent, global interoperability can be achieved using mediating gateways.
See [WDP] for more information.
7.6 Bearers The WAP protocols are designedseparates service interfaces from the protocols that provide those services to allow for evolution
of the specifications and selection of the most appropriate protocol for a given context. Many of the services in the
stack may be provided by more than one protocol. For example, either HTTP [RFC2616] or WSP [WSP] may provide
the Hypermedia Transfer service.
7.1 Bearer Networks
Protocols have either been designed or selected to operate over a variety of different bearer services, including short
message, circuit-switched data, and packet data. The bearers offer differing levels of quality of service with respect to
throughput, error rate, and delays.
7.7 Other Services and Applications The WAP layered architecture enables other services and applications to utilise the features of the WAP stack through a set of well-defined interfaces. External applications may access the session, transaction, security and transport layers directly. This allows the WAP stack to be used for applications and services not currently specified by WAP, but deemed to be valuable for the wireless market. For example, applications, such as electronic mail, calendar, phone book, notepad, and electronic commerce, or services, such as white and yellow pages, may be developed to use the WAP protocols.
7.8 Sample Configurations of WAP Technology WAP technology is expected to be useful for applications and services beyond those specified by the WAP Forum.
Figure 5 depicts several possible protocol stacks using WAP technology. These are for illustrative purposes only and do not constitute a statement of conformance or interoperability
Applications over Transactions WTP WDP UDP IP eg, GPRS, CSD, CDPD, iDEN non-IP eg, SMS, USSD, GUTS, FLEX Applications over Datagram Transport WDP UDP IP eg, GPRS, CSD, CDPD, iDEN non-IP eg, SMS, USSD, GUTS, FLEX WAP Technology Outside of WAP WAE WSP/B WTP WDP UDP IP eg, GPRS, CSD, CDPD, iDEN non-IP eg, SMS, USSD, GUTS, FLEX WAE User Agents WTLS No Layer WTLS No Layer WTLS No Layer Figure 5. Sample WAP Stacks The leftmost stack represents a typical example of a WAP application, ie, WAE user agent, running over the complete portfolio of WAP technology. The middle stack is intended for applications and services that require transaction services with or without security. The rightmost stack is intended for applications and services that only require
7.2 Transport Services
The Transport Services layer offers a set of consistent services to the upper layer protocols and maps those services to
the available bearer services. The Transport Services transport unstructured data across the underlying bearer networks.
These transport services create a common abstraction that is consistent across all the bearers.
The Transport Services include, but are not limited to:
· Datagrams - The datagram service provides data transport in which self-contained, independent entities of data
carry sufficient information to be routed from the source to the destination computer without reliance on earlier
exchanges between this source and destination computer and the transporting network. UDP (User Datagram
Protocol) [STD0006] and WDP (Wireless Datagram Protocol) [WDP] are two protocols used to provide the
datagram transport service in the WAP architecture.
· Connections - The connection service provides data transport service in which communication proceeds in three
well-defined phases: connection establishment, two-way reliable data transfer and connection release. TCP
(Transmission Control Protocol) [STD0007] is a protocol used to provide the connection transport service of IP 1
bearers for the WAP architecture. In order to cope with the wireless network characteristics, the TCP protocol can
be profiled for its use, see [WP-TCP].
7.3 Transfer Services
The Transfer Services provide for the structured transfer of information between network elements.
The Transfer Services include, but are not limited to:
· Hypermedia Transfer - The hypermedia transfer services provides for the transfer of self-describing hypermedia
resources. The combination of WSP (Wireless Session Protocol) [WSP] and WTP (Wireless Transaction Protocol)
[WTP] provide the hypermedia transfer service over secure and non-secure datagram transport with or without security..© transports. The HTTP
(Hypertext Transfer Protocol) [RFC2616] provides the hypermedia transfer service over secure and non-secure
connection-oriented transports.
· Streaming - The streaming services provide a means for transferring isochronous data such as audio and video.
· Message Transfer - The message transfer services provide the means to transfer asynchronous multimedia
messages such as email or instant messages. MMS Encapsulation [MMSEncapsulation] is a protocol used to
transfer messages between WAP devices and MMS servers.
7.4 Session Services
The session services provide for the establishment of shared state between network elements that span multiple network
requests or data transfers. For example, the Push session establishes that the WAP Device is ready and able to receive
pushes from the Push Proxy.
The Session Services include, but are not limited to:
· Capability Negotiation - The WAP architecture includes specifications for describing, transmitting, and managing
capabilities and preference information about the client, user, and network elements. See [UAProf] for more
information. This allows for customisation of information and content returned by the origin server or pushed by
the application.
· Push-OTA - The Push-OTA (Over The Air) session service provides for network-initiated transactions to be
delivered to wireless devices that are intermittently able to receive data (e.g., modal devices and devices with
dynamically assigned addresses). The Push-OTA service operates over the connection-oriented transport service
and datagram transport [PushOTA].
· Sync - The Sync service provides for the synchronisation of replicated data.
1 Utilisation of TCP connections over IP may require additional components of the TCP/IP protocol suite. One example
for such a component is ICMP..
Compliance and Interoperability The WAP Forum views multi-vendor interoperability as an important element to the success of WAP products. In order to provide as high a probability as is technically possible that two WAP products developed independently by two different vendors will successfully interoperate, a rigorous definition of conformance, compliance, and testing must be developed. To this end the WAP Forum has created a WAP Conformance Specification [WAPConf] and is working to maintain current information relating to all issues of WAP interoperability.
Successful interoperability can only be achieved by testing products. Testing can be divided into two broad categories of static testing and dynamic testing. Static testing is a manufacturer's statement of the capabilities and functions of a product. Static testing will identify obvious areas of incompatibility between two products, ie, where one implements a feature which the other does not support. All WAP specifications will provide a means for static testing in the form of a Protocol Implementation Conformance Statement (PICS), see [WAPConf] for more details on static testing.
Dynamic testing is the real form of testing which leads to a high degree of confidence that two products will successfully interoperate. Dynamic testing involves the execution or exercising of a product in a live environment, ultimately proving that the product meets the stated claims given in the static test, ie, PICS. There are three general approaches to dynamic testing: pair-wise testing or bake-offs; use of a reference implementation against which all products are measured; and definition of formal test suites containing test cases to be run against a product in a testing laboratory. Each of these approaches to dynamic testing has cost trade-offs and some technical pluses and minuses. The cost of each approach is related to the total number of products that need to be tested. The WAP Forum will promote the most cost effective method that leads to the greatest degree of confidence for successful interoperability given the total number of WAP products available in the market at a given time. This is an evolutionary approach that will change over time as the WAP industry matures. As a starting point the WAP Forum is promoting pair-wise testing in a laboratory environment for new WAP products. As the WAP industry evolves reference implementations may be identified, followed by the definition of formal test suites for WAP specifications..©
· Cookies - The Cookies service allows applications to establish state on the client or proxy that survives multiple
hypermedia transfer transactions. See [HTTPState] for more information.
7.5 Application Framework
The Application Framework provides a general-purpose application environment based on a combination of World
Wide Web (WWW), Internet and Mobile Telephony technologies. The primary objective of the Application Framework
is to establish an interoperable environment that will allow operators and service providers to build applications and
services that can reach a wide variety of different wireless platforms in an efficient and useful manner.
The Application Framework includes, but is not limited to:
· WAE/WTA User-Agent - WAE is a micro-browser environment containing markup (including WML and
XHTML), scripting, style-sheet languages, and telephony services and programming interfaces, all optimised for
use in hand-held mobile terminals. See [WAEOverview] for more information.
· Push - The Push service provides a general mechanism for the network to initiate the transmission of data to
applications resident on WAP devices. See [PushArchOverview] for more information.
· Multimedia Messaging - The Multimedia Message Service (MMS) provides for the transfer and processing of
multimedia messages such as email and instant messages to WAP devices.
· Content Formats - The application framework includes a set of well-defined data formats, including images, audio,
video, animation, phone book records and calendar information.
7.6 Security Services
Security forms a fundamental part of the WAP Architecture, and its services can be found in many of its layers. In
general the following security facilities offered are:
· Privacy - facilities to ensure that communication is private and cannot be understood by any intermediate parties
that may have intercepted it.
· Authentication - facilities to establish the authenticity of parties to the communication.
· Integrity - facilities to ensure that communication is unchanged and uncorrupted.
· Non-Repudiation - facilities to ensure parties to a communication cannot deny the communication took place.
The Security Services span all the various layers of the WAP Architecture. Some specific examples of the security
services include:
· Cryptographic Libraries - This application framework level library provides services for signing of data for
integrity and non-repudiation purposes. See [WMLScriptCrypto] for more information.
· Authentication - The Security Services provide various mechanisms for client and server authentication. At the
Session Services layer HTTP Client Authentication [RFC2617] may be used to authenticate clients to proxies and
application servers. At the Transport Services layer, WTLS and TLS handshakes may be used to authenticate
clients and servers.
· Identity - WIM provides the functions that store and process information needed for user identification and
authentication [WIM]
· PKI - The set of security services that enable the use and management of public-key cryptography and certificates
[WPKI], [WAPCert].
· Secure Transport - At the Transport Services layer protocols are defined for secure transport over datagrams and
connections. WTLS is defined for secure transport over datagrams. WTLS and TLS are defined for secure
transport over connections. TLS is the preferred method for secure transport over connections (i.e. TCP). See
[WTLS] and [RFC2246] for more information.
· Secure Bearer - Some bearer networks provide bearer level security. For example, IP networks (especially in the
context of IPv6) provide bearer-level security with IPSec [RFC2401]..
Future Work Items The Future Work Items list is a collection of areas that warrant further consideration in order to determine whether or not any working groups should be chartered with developing recommendations or specifications. The list is neither prescriptive nor exhaustive. This list is not prioritised in any way, ie, no importance can be attached to the numbering scheme. Areas for consideration can be added or deleted at any time. The list currently contains the following items: 1. Connection-oriented data transport 2. Integration of SIM Toolkit, smartcard and WAP 3. Integration of MExE (ETSI) and WAP 4. Additional integration with the telephony network 5. Downloadable WMLScript libraries 6. Compression (WTLS or other layers) 7. Application levels security, eg, crypto scripting libraries 8. Wider scope of security architecture, including smartcard support, improved handling of
7.7 Service Discovery
Service discovery forms a fundamental part of the WAP Architecture and its services can be found at many layers.
Some specific examples of Service Discovery services include:
· EFI - The External Functionality Interface (EFI) allows applications to discover what external functions/services
are available on the device.
· Provisioning - The Provisioning service allows a device to be provisioned with the parameters necessary to access
network services. See [ProvArch] for more information.
· Navigation Discovery - The Navigation Discovery service allows a device to discover new network services (e.g.
secure pull proxies) during the course of navigation such as when downloading resources from a hypermedia
server. The WAP Transport-Level End-to-End Security specification [TransportE2ESec] defines one navigation
discovery protocol.
· Service Lookup - The Service Lookup service provides for the discovery of a service's parameters through a
directory lookup by name. One example of this is the Domain Name System (DNS) [STD0013].
7.8 Other Services and Applications
The WAP layered architecture enables other services and applications to utilise the features of the WAP stack through a
set of well-defined interfaces. External applications may access the various services directly. The WAP layered
architecture builds upon an extensible set of protocols. This allows the WAP stack to be used for applications and
services not currently specified by WAP, but deemed to be valuable for the wireless market. Such applications and
services may benefit from adding protocols or particular protocol capabilities. For example, applications, such as
electronic mail, calendar, phone book, notepad, and electronic commerce, or services, such as white and yellow pages,
may be developed to use the WAP protocols.
8. Sample Configurations of WAP Technology
Because several of the services in the WAP stack can be provided using different protocols based on the circumstances,
there are more than one possible stack configurations. The following figures depict several possible protocol stacks
using WAP technology. These are for illustrative, informative purposes only and do not constitute a statement of
conformance or interoperability, nor is this set of examples exhaustive.
Figure 8. Example WAP 1.X Gateway.Proposed Version 17-October-2000 Page 22 (25)
Ó Ó Copyright Wireless Application Protocol Forum,Ltd, 2000-2001
All rights reserved
Figure 8 depicts the protocol stacks for the original WAP architecture. The WAP Gateway converts the hypermedia
transfer service between the datagram-based protocols (WSP, WTP, WTLS, WDP) and connection-oriented protocols
commonly used on the Internet (HTTP, SSL, TCP).
Figure 9. Example WAP HTTP Proxy with Profiled TCP
Figure 9 depicts a WAP HTTP proxy. The proxy configuration is widely used in the Internet for ordinary web access,
multimedia data, e.g. music, video clip downloading and so on. This configuration locates the WAP Proxy between
wireline and wireless networks to enhance performance by using the wireless profile of TCP.
Figure 10. Example WAP Proxy Support for TLS Tunneling
Figure 10 depicts a WAP HTTP proxy that has established a connection-oriented tunnel to the web server (e.g., in
response to a CONNECT command). This configuration is used to allow TLS to provide end-to-end security, certificate authority hierarchies, etc.
9. Support for streaming multimedia content for higher bandwidth bearers, eg, GPRS 10. Support for multicast data 11. Support for location dependent mobile services, eg, positioning functions and features 12. Downloadable applications 13. Speech API 14. Management Entity Definitions for each layer and across all layers of the WAP 15. Quality of Service for the WAP stack with respect to each bearer service 16.between
mobile terminal and origin server. E-commerce is a compelling use case for end-to-end security..Proposed Version 17-October-2000 Page 23 (25)
Ó Ó Copyright WirelessApplication Programming Interfaces for each layer of the WAP stack 17. Interoperability Testing (see previous section on compliance and interoperability testing)Protocol Forum,Ltd, 2000-2001
All rights reserved
Figure 11. Example Direct Access
Figure 11 depicts a WAP device directly accessing a Web Server via the Internet. The wireless IP router is a standard
part of an IP network that is used to transfer IP packets from one link layer (e.g., the wireless link) to another (e.g., the
wired link). This configuration can apply to the case where bearer-level security (such as IPSec) is utilised.
Figure 12. Dual Stack Support
While the previous configurations show single protocol stacks for each of WAP configuration, Figure 12 depicts a
device that supports both the 1.x and 2.x protocol stacks. This configuration is useful in cases where a device needs to
interoperate with both old a new WAP servers..Proposed Version 17-October-2000 Page 24 (25)
Ó Ó Copyright Wireless Application Protocol Forum,Ltd, 2000-2001
All rights reserved
9. Conformance and Interoperability
The WAP Forum views vendor interoperability as an important element to the success of WAP products. In order to
provide as high a probability as is technically possible that two WAP products developed independently by two
different vendors will successfully interoperate, a rigorous definition of conformance, compliance, and testing has been
developed.
Conformance answers the question, "Does an implementation meet the standard as written?" The WAP Forum charters
a neutral third party to build a comprehensive test suite from its specifications. Usually, implementations are tested
against known references.
Interoperability answers the question, "Will this implementation work with other products developed to the same
standard?" Interoperability testing uses a test suite designed to test implementation to implementation compatibility,
and implementations are tested against each other. Interoperability testing is not focused on compliance--two products
with the same non-compliant implementation will be interoperable.
Figure 13. Interoperability and Compliance
The WAP Forum Certification Program is focused on conformance, but offers some interoperability testing as well.
The Certification Program covers the entire value chain as shown in Figure 13.
To improve interoperability at the authoring level, the WAP Forum provides authoring guidelines to improve the
accessibility of WAP content. To certify content, the WAP Forum will test certified content to ensure it conforms to the
specifications (e.g., WML is checked to be syntactically correct). To certify WAP clients and servers, the WAP Forum
conducts interoperability testing of an implementation against multiple reference implementations.
The WAP Forum has defined a number of Class Conformance Profiles, e.g. Class A, Class B, and Class C. An
implementation may be certified in one or more class. The class conformance requirements are specified in
[ClassConform].
Each WAP Specification includes static conformance requirements (SCRs) for that specification. These define which
features are mandatory and optional and are the basis for the conformance test suite..
See also:
Comments and corrections to: webmaster@tomw.net.au