WTAI Enhancements

Most of the work in enhancing the Wireless Telephony Application Interface has been in removing ambiguities and correcting problems in the version 1.1 specifications. Currently, support in WML browsers for WTAI is not wide. However, if you're building applications for the more feature-rich browsers, the following are some of the more significant changes:

 

Ø       Mandatory display of the number in public makeCall(number) function

Ø       New functions for:

Ø       Adding a new phonebook entry: addPBEntry(number, name)

Ø       Voice call control: callStatus(id, field), listCall(id)

Ø       Changing a phonebook entry: change(id, field, value)

Ø       New events for:

Ø       Voice call control: Outgoing Call indication (cc/oc), Connected Call indication (cc/co), DTMF sent (cc/dtmf)

Ø       Incoming network text (nt/it), and network text sent (nt/st)

Ø       Network status indication (ms/ns)

New Push Specifications

Push is a major new piece of functionality that is a significant addition to the WAP developer's toolkit. It's a good example of how the WAP Forum is endeavoring to create web connectivity tailored to the different needs of wireless subscribers, rather than just "bringing the Web to your pocket".

The WAP push framework introduces a means within the WAP effort to transmit information to a device without a previous user action. In the normal client-server model, a client requests a service or information from a server, which then responds by transmitting information to the client. This is known as "pull" technology - the client "pulls" information from the server. The Web is a typical example of pull technology: a user enters a URL (the request) that's sent to a server, and the server answers by sending a web page (the response) to the user.

 

In contrast to this is "push" technology, which is also based on the client-server model, but involves no explicit request from the client before the server transmits its content.

 

As with standard WAP architecture, a proxy lying between the client(s) and the content server performs a crucial role. It may be that the standard WAP "pull" proxy (that is, the WAP gateway) may be the PPG (push proxy gateway) as well, but this is not a requirement.

 

The PPG acts as a store-and-forward agent for push submissions, and may return status information to the push-initiating content server when the operation has been completed. Push submissions may be directed to a single client, or some PPGs may implement an address aliasing scheme whereby a single push submission addressed to a special destination may, in fact, reach a group of clients.

What will Push be used for?

Typical applications for push technology will be those where a user has requested notifications, say, for new e-mail, stock price movements, goals scored at football games, and so on.

 

At its simplest, a push message will consist of a short message and a URL that the user will select for further information. However, one of the more interesting aspects of the push architecture is that it does not dictate that the content must be WML or WMLScript. The header in a push message includes an application identifier that indicates the particular user agent (or application) the content is targeted at. This raises the interesting prospect of WAP being used as the transport mechanism for content intended for any other applications installed on the mobile device.

Push Security

Needless to say, feeding content to a device without the specific request of the client requires careful consideration of security. The WAP specifications provide a lot of ideas about how this is to be achieved, but leaves it to the implementers to decide exactly what approach should be followed.

 

As a general principle, of course, the content server initiating the push must be authenticated in one form or another. This could be through TLS/SSL certificates between the PPG and push initiator, or by using object-level certificates to encrypt and digitally sign submissions, so that end-to-end security is used and the PPG is not involved in the authentication. Digest-based HTTP authentication could also be used.

 

In certain circumstances, clients can delegate trust to the PPG. The client can maintain a list of trusted PPGs, and as long as the push content is being submitted by one of those, the client can accept that the PPG has in turn authenticated the push initiator.

User Agent Profile

The User Agent Profile (UAProf) is included in the v1.2 specifications, but its true significance will only become apparent as the Web moves towards convergence (of which more later). It is placing a very large stake in the ground about the future of WAP and the Web.

 

The UAProf specification extends WAP 1.1 to enable the end-to-end flow of a user agent profile (also referred to as Capability and Preference Information or CPI) between the WAP client, intermediate network points, and the origin server. It seeks to interoperate seamlessly with the emerging standards for Composite Capability/Preference Profile (CC/PP) distribution over the Internet. The specification defines a set of components and attributes that WAP-enabled devices may convey within the CPI. These may include, but are not limited to, the following:

 

Ø       Hardware characteristics (screen size, color capabilities, image capabilities, manufacturer, etc.)

Ø       Software characteristics (operating system vendor and version, support for MExE, list of audio and video encoders, etc.)

Ø       Application/user preferences (browser manufacturer and version, markup languages and versions supported, scripting languages supported, etc.)

Ø       WAP characteristics (WMLScript libraries, WAP version, WML deck size, etc.)

Ø       Network characteristics (bearer characteristics such as latency and reliability, etc.)

 

With this capability, information about a client device's capabilities is available at the content server, so that application developers can tailor content accordingly. The W3C's vision is that, in time, the majority of web content will be defined once, with rendering of that content according to the end device's capabilities carried out as a separate step.

 

Instead of developing content aimed at a single class of end user devices, for example PCs, Wireless devices or TVs, content can be defined once and made available on many devices. This will lead to wider availability of content to consumers, regardless of the client device used.