For Wireless Security, First Understand Wireless Programming
- Openwave SDK
In This Chapter
In Chapters 1, "Wireless Hardware" and 2, "Wireless Network Protocols," we introduced wireless hardware and the 802.11 standard used in WLANs. Now that we've covered the infrastructure basics, let's briefly examine the wireless programming languages that facilitate communication on this infrastructure.
Although basic wireless communication seems simple on the surface, the programming can be complex. Programmers must optimize everything for a device with minimal memory and processing power. Whether it is for ordering pizza, checking movie times and prices, or sending SMS messages, the code can be quite involved. In addition, the information must be accessible from a wide range of devices, such as cell phones, Blackberry units, and iPAQs. Each of these devices has its own proprietary hardware and software applications protocols.
Programmers attacked this complex task with alacrity, and languages quickly evolved. Although the outcome is not completely standardized, the contestants have been narrowed down to a few stable and very useful languages. This chapter will examine the main types of programming and formatting found in handheld wireless devices. Currently the list includes the following:
We'll introduce wireless programming languages by first discussing the three markup languages. These include Hypertext Markup Language (HTML), Extensible Markup Language (XML), and the combination of the two, Extensible Hypertext Markup Language, (XHTML).
HTML is the primary format used on the World Wide Web. HTML can display Web pages with a wide range of colors, shapes, and objects. Although not a true programming language, HTML has increased in power over the years.
HTML is actually a loosely defined subset of XML. However, whereas XML is a strict language (as you will learn), HTML takes many liberties that have helped it become the popular presentation tool it is today. Although the spirit of the young Internet encouraged freedom, developers have now realized that the freedom of HTML has repercussions. Because HTML is so flexible, many browsers and Web applications have added their own functionality to the base HTML protocol. Like all enhanced functionality, this comes with additional security risks.
For this reason, efforts are underway to replace HTML with a much more regulated and standardized markup language known as XHTML.
XML is the foundation for many data formats, including HTML, WML, XHTML, and more. It has recently become popular because it can facilitate the transfer of data between widely disparate programs, operating systems, and companies. The key to XML's utility is that it enables any developer to design her own data format using her own terms and requirements. In fact, XML is so popular that Microsoft has built its entire suite of products, from operating systems to server components, around the concept of XML.
To illustrate the utility of XML, let's consider a sample corporation that needs to share information about fruit inventory. Because direct access to a database would be a security risk (as well as poor business practice), the developer can create an XML program that defines the type, size, and color of each fruit on hand. Once she has determined the specs, the developer could program the host with the capability to pull data from a database and convert it to an XML file. On the other end, a special client could scan the generated XML file and parse the information to fill its own database. This process would thus allow for rapid and standardized data transfer.
To illustrate this, consider the following sample source code to see how such an XML file would appear. Note the hierarchy and the matching set of labels. Each label is a property, which could have sub-properties. In this case, we are passing information about an apple and a grape.
<FRUIT> <NAME>APPLE <COLOR>RED</COLOR> <SIZE>BIG</SIZE> </NAME> <NAME>GRAPE <COLOR>PURPLE</COLOR> <SIZE>SMALL</SIZE> </NAME> </FRUIT>
By extrapolating from this simple example, you can see how XML data is organized. The use of such relational data methods is still in its infancy, and will continue to grow for many years.
Although XML is the foundation of many other Internet-based formatting languages, its subsets are giving XML the push it needs to become the de facto standard. A recent subset, XHTML, is slowly gaining ground, and is destined to overtake HTML in prevalence.
Thus, XHTML will likely replace HTML. Although this process will take several years, many Webmasters have already embraced XHTML, and are slowly integrating its rules into their development. In fact, XHTML 1.0 is considered by many to be the next version of HTML (HTML 5.0).
What makes XHTML so popular is its simple yet rigid ruleset. This ruleset is so powerful because it enforces a universal standard. The rules are as follows:
- XHTML requires a declaration at the top of every XHTML page.
This new rule tells the browser the type of data to render, which keeps all parts of the data presentation and transfer process flowing smoothly. The following is an example of an XHMTL declaration.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
- All XHTML pages must have the <head> and <body>
Although these tags typically exist in all Web pages, For HTML, Web browsers will overlook the missing data and fill it in automatically when it's not present. However, this is not the case with XHTML.
- All tags must be closed.
Prior to XHTML, Web pages included tags like <p>, which typically had a closing tag </p>. however, it didn't matter if the closing tag was left out. With XHTML, every tag must be closed. In addition, tags like "<HR>", which created a line across a Web page, must now look like <hr />. This is a completely new concept for Web pages.
- All tags must be lower case.
Again, this is a new rule. Previous versions of HTML used uppercase tags; now these tags must be lowercase. As you noticed the rule prior to this one, the <HR> not only gained a slash, but also became lowercase. (This only applies to tags, not attributes.)
- All attributes must have quotes.
Although this rule has traditionally been considered good coding practice, it is now mandatory. This will add complications for dynamically created Web pages.
- All tags must be in the proper hierarchy (not nested).
Again, this was considered good coding practice, but was not required. With XHTML, the following would no longer be correct:
<I><B>Bolded and Italicized</I></B>
Instead, it would now be written as follows:
<i><b> Bolded and Italicized </b></i>
(Note the lowercase letters.)
- All attribute values must be denoted.
This is not a common occurrence in HTML. However, if you are coding a group of radio buttons, one might be listed as "checked." See the following old versus new way of listing this:
Old: <INPUT TYPE=RADIO CHECKED NAME="AnyName">
New: <input type="radio" checked="true" name="AnyName"/>
(Note the use of lowercase, quotes, and a closing slash.)
- All <pre> tags must not contain the following tags:
<big>, <small>, <sub>, <sup>, <img>, or <object>
Form cannot be nested.
All "&" symbols must be written as "&".
All CSS must be written in lowercase letters.
- All <!-- comments --> are illegal.
Of course, commenting is still supported in XHTML, if it is performed with the following syntax:
<[CDATA[comments appear in here]]>
By contrasting these simple but powerful rules with HTML, you can begin to see the advantages of XHTML. In addition, PCS (Personal Communication Service) devices also use XHTML. Because of the myriad of vendors, each with its own proprietary approach, the strict rules of XHTML and XML are vital. Without this standard, Web developers would have to create separate Web pages for each device. Fortunately, because of this standard, developers can create one or two pages for all devices. However, XHTML is still too bloated for many smaller PCS devices. Therefore, another option is required.