Method and system for network management

[0001] This application relates to and incorporates by reference the following group of applications. The invention of each application is assigned to the assignee of this invention. The group of applications includes the following.

[0002] U.S. patent application Ser. No. 09/087,515, entitled “Method and Apparatus for Communicating Information over Low Bandwidth Communications Networks,” filed May 29, 1998, having inventors Jeffrey C. Hawkins, Joseph K. Sipher and Scott D. Lincke.

[0003] U.S. patent application Ser. No. 09/087,563, entitled “Method, System and Apparatus for Packet Minimized Communications,” filed May 29, 1998, having inventors Ronald Marianetti II, Scott D. Lincke, and Jeffrey C. Hawkins.

[0004] U.S. patent application Ser. No. 09/086,888, entitled “Method and System for Secure Communications,” filed May 29, 1998, having inventors Ronald Marianetti II and Scott D. Lincke.

[0005] U.S. patent application Ser. No. 09/087,552, entitled “Method and Apparatus for Wireless Internet Access,” filed May 29, 1998, having inventor Jeffrey C. Hawkins.

[0006] U.S. patent application Ser. No. 09/299,064, entitled “Method, Apparatus and System for Selection of a Port for Data Exchange,” filed Apr. 23, 1999, having inventors Adam D. Hampson, Steven C. Lemke, Daniel F. Chernikoff, Bruce G. Thompson, and William C. Witte.

[0007] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosures, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

[0008] This invention relates the field of network management. In particular, the invention relates the use of a palm-sized computer to access network management information and carry out network management functions.

[0009] Wireless communications provides one method for mobile users to communicate to a wired network. In particular, wireless communications allows consumers to receive and send information. Examples of such wireless networks include cellular phones, pager systems, and satellite systems. The wireless network systems can be broken into relatively high bandwidth and low bandwidth systems. High bandwidth systems are for example satellite systems. Lower bandwidth systems include cellular phones and mobile radio systems. Still lower bandwidth systems include pager networks and low bandwidth packet switched radio systems (e.g., the BellSouth Mobile Data Mobitex™ system).

[0010] For users to access information on the Internet or their own networks using wireless communications, the method in which they access the information is highly dependent on the type of wireless communications available to the user. For example on a high bandwidth network such as a wired network or a satellite system, the usual techniques for browsing data on the Internet are adequate.

[0011] One area in which Web access is becoming more desirable is in handheld devices. Handheld devices are emerging as important computer devices. Handheld devices typically implement a relatively small, but important function set. Examples of such handheld devices are the PalmPilot™ handheld device available from 3COM Corporation, Inc. of Santa Clara, Calif. Examples of the function set supported are address books, calendars, and task lists.

[0012] In the past, wireless communications with handheld devices have been performed using wireless modems, such as are available from Novatel Communications, Inc. of Calgary, Alberta, or wireless transceivers for dedicated wireless data access network. Essentially a wireless modem operates in the cellular phone network and supplies approximately 9600 baud bandwidth to the handheld device. This allows the user to access the web at a relatively low bandwidth.

[0013] An unrealized application for wireless, handheld devices is accessing network management information and performing network management functions. Network administrators are often away from their network management console when they are paged or called upon to perform network management functions. Given the immediacy of their clients' needs and their hectic schedules, network administrators would greatly benefit from use of wireless, handheld devices to assist with network management.

[0014] The present invention includes methods and devices for network management using a palm-sized computer. In some embodiments, the palm-sized computer is conveniently connected to the synchronization server via a wireless link. A network management method practicing the present invention includes the steps of accessing a page containing network management information stored on the palm-sized computer, selecting indicating a network management function to be performed, connecting to a synchronization server, transmitting the selected or indicated function, and receiving updated network management information responsive to the selected function. One aspect of the present invention is the convenience size of the computer. It may be smaller than four by six inches, as are the Palm™ personal digital assistants. The display may be 160 by 160 pixels or compatible. The display preferably is pressure sensitive and indicating a choice involves pressing a stylus against the display. The network functions that may be accessible from the palm-sized computer include changing the configuration of a device, changing its inventory description, or accessing its historical information. In support of network management, the palm-sized computer may provide access to Web-based, intranet-based, or server-based support information. Connecting the palm-sized computer with the synchronization server step may include placing the palm-sized computer in a communications cradle or using a radio or infrared signal. The synchronization server may start on demand. The transmitting and receiving steps may include encoding and decoding information using a compact markup language, which may use variable bit-length strings or five-bit encoding of characters to minimize the amount of data that needs to be transmitted. Forms may be cached on both the palm-sized computer and the synchronization server so that only data, and not the form itself, needs to be transmitted. The synchronization server may communicate with a proxy server or network management server, in response to the palm-sized computer.

[0015] A related method practicing the present invention may provide access to network inventory management data. This method may include accessing a page form stored on the palm-sized computer which contains choices about a scope of network inventory information, selecting indicating the desired scope of information sought, connecting with the synchronization server, transmitting the selected or indicated scope, and receiving network inventory information. The selected scope may be a single device or a category of devices. The aspects elaborating upon the foregoing network management method apply equally well to this method of accessing network inventory management data.

[0016] The present invention also maybe practiced as a device. In one embodiment, a device for network management includes the palm-sized computer running a browser application, the synchronization server in communication with the palm-sized computer, and a network management server in communication with the synchronization server. The palm-sized computer may be smaller than four by six inches and have a display compatible with 160 by 160 pixels. The display may be pressure sensitive for input. The palm-sized computer may store a variety of forms adapted for requesting, reporting and modifying device information. The form-accessible device information may include device configuration, device inventory description and device historical information. Communications between the palm-sized computer and synchronization server may be through a communications cradle or utilizing a radio or infrared link.

[0033] The following description of various and embodiments of the invention is presented for purposes of illustration and description. The description is not intended to limit the invention to the precise forms disclosed. Many modifications and equivalent arrangements will be apparent people skilled in the art.

[0034] Thus, some of the more important features of various embodiments of the invention have been described. The following provides an overview of the sections in the detailed description.

[0035] The Definitions section provides definitions of terms used in the detailed description.

[0036] The System Introduction section provides an introduction to the various elements of the wireless communications system.

[0037] The Wireless Network Topology section introduces the protocols used to communicate between the various devices in the system.

[0038] The Method and System Using Palm-Sized Computer for Network Management section describes an integrated use of a palm-sized computer, a wireless system and software for network management.

[0039] The Content Layer section describes the markup languages used in the system.

[0040] The Transfer Layer section describes a compact transfer protocol (CTP) used for communicating between the wireless communications device and the proxy server.

[0041] The Reliable Message Protocol section describes reliable and efficient variable length message delivery over the wireline and wireless networks.

[0042] The Wireless Network Interface section describes a set of programs that can be used to access the wireless network as an IP network.

[0043] The Proxy Server Details section describes how the proxy server works with the content layer, the transfer layer, and the reliable message protocol.

[0044] The Communications System Details section describes how the content layer, the transfer layer, the reliable message protocol, the network interface and the proxy server can be used together.

[0045] The following glossary will be helpful in understanding the description.

[0046] Computer—is any computing device (e.g., PC compatible computer, Unix workstation, handheld device etc.). Generally, a computer includes a processor and a memory. A computer can include a network of computers.

[0047] Handheld Device (or Palmtop Computer)—a computer with a smaller form factor than a desktop computer or a laptop computer. Examples of a handheld device include the Palm III™ handheld computer and Microsoft's palm sized computers.

[0048] User—any end user who would normally wish to retrieve information from the World Wide Web.

[0049] Internet—is a collection of information stored in computers physically located throughout the world. Much of the information on the Internet is organized onto electronic pages. Users typically bring one page to their computer screen, discover its contents, and have the option of bringing more pages of information.

[0050] Client—a computer used by the user to make a query.

[0051] Server—a computer that supplies information in response to a query, or performs intermediary tasks between a client and another server.

[0052] World Wide Web (or Web or web)—is one aspect of the Internet that supports client and server computers handling multimedia pages. Clients typically use software, such as the Netscape Communicator® browser, to view pages. Server computers use server software to maintain pages for clients to access.

[0053] Program—a sequence of instructions that can be executed by a computer. A program can include other programs. A program can include only one instruction.

[0054] Application—is a program or a set of hyper-linked documents.

System Introduction

[0055] FIG. 1 illustrates a wireless communications device communicating with a web server. In this example, the wireless communications device includes a handheld computer (or portable computer) having wireless communications capabilities. The handheld computer has predefined applications that correspond to a portion of the web site being served by the web server. Using the applications, a user can use to make queries of the web server. Some embodiments of the invention provide compression techniques that enable the wireless handheld computer to complete a web based information request using only one packet up to a proxy server and only one packet back down to the wireless communications device.

[0056] FIG. 1 includes a wireless communications device 100, a base station 170, a proxy server 180, the Internet 190, and a web server 140. The wireless communications device 100 includes a screen 101 and is running an operating system 102. The operating system supports the execution of a browser 104. The browser 104 runs with the wireless application 106 and displays an example query form 105 and an example query response 107. Between the base station 170 and the proxy server 180 is a private network 172. The web server 140 includes a CGI (Common Gateway Interface) program 142. The CGI program 142 is responsible for generating the HTML page 144. FIG. 1 also includes a number of arrows indicating queries and responses. These queries and responses include a wireless CTP (Compressed Transport Protocol) query 122, a CTP query 124, an HTTP query 126, an HTTP response 136, a CTP response 134, and a wireless CTP response 132. The wireless communications device 100 communicates with the base station 170 via wireless communications. The base station 170 is coupled to the proxy server 180 via the private network 172. The proxy server 180, and the web server 140 are all coupled to the Internet 190.

[0057] The wireless communications device 100 represents a handheld device that has wireless communications capabilities (also referred to as a portable computer or handheld computer with wireless communications capabilities). In one example system, the wireless communications device 100 includes a Palm III™ compatible handheld device having wireless communications capabilities. The wireless communications device 100 is for communicating over the BellSouth Mobile Data (BSMD) Mobitex system. Other embodiments of the invention support other wireless communications networks. Importantly, the BSMD Mobitex system is a relatively low bandwidth network. The embodiments of the inventions support querying of web based data using such a low bandwidth network.

[0058] The operating system 102 is an example of an operating system that can run on a handheld computer. Examples of such operating systems include the Palm OS™ operating system, available from the 3COM Corporation, of Santa Clara, Calif. The operating system 102 supports the running of applications. The operating system 102 also supports low level communications protocols, user interface displays, and user input.

[0059] The browser 104 is an example of a program (or group of programs) that supports some standard browsing features (e.g., displaying markup language documents, following hyper-links). The browser 104 is for generating queries and receiving responses. The browser 104 can interface with groups of hyper-linked, marked up documents (also referred to as pages). The browser 104 can also interface with standalone programs that do not use marked up documents. In this example, the browser 104 is executing with the wireless application 106. The browser 104 is described in greater detail below.

[0060] The wireless application 106 represents one of many predefined applications that are stored locally on the wireless communications device 100. Each wireless application represents a static portion of a web site tree. That is, this information does not change significantly over time. The web site tree is the data structure representing the hyper-linked web pages of a web site. (Note that the tree is actually usually a graph.) Each predefined application is used for accessing a different web site. The predefined applications can be downloaded to the wireless communications device 100 through wireless communications, but more typically, they are downloaded through a docking cradle or through infrared communications with another wireless communications device 100.

[0061] The wireless application 106, in this example, includes a number of hyper-linked pages. One of the pages includes the example query form 105. This example query form 105 is used to generate a query that is answered as the example query response 107. Alternatively, the wireless applications can standalone applications access through the browser 104. The applications can be C programs, JAVA programs, and/or compressed markup language (CML) or HTML pages.

[0062] The query response 107 represents the dynamic data in the web site tree (the data that can change often). The query response 107 includes information retrieved from the web server 140.

[0063] The example query form 105 and the example query response 107 can be stored in a CML format. The markup language is compressed relative to HTML. This compressed markup language is described in greater detail below. What is important is that the compressed markup language is a subset and superset of HTML and is requires far fewer bytes than HTML typically requires. Additionally, the compressed markup language represents a compressed description of information to be displayed on the screen 101. The browser 104 uses the representation to generate the display on the screen 101.

[0064] The base station 170 represents a wireless communications base station. The BSMD Mobitex system includes base stations like the base station 170. The base station 170 is responsible for communicating with the wireless communications device 100 and other wireless communications devices (e.g. pagers).

[0065] The private network 172 represents the communications links between a base station 170 and a proxy server 180. The BSMD Mobitex system has such a private network. Between the base station 170 and the proxy server 180, many servers, routers, and hubs, etc. may exist. In some embodiments, the private network 172 may communicate with the proxy server 180 through the Internet 190. The proxy server 180 would then communicate with the web server 140, also through the Internet 190.

[0066] The proxy server 180 represents one or more computers that convert queries from the wireless communications device 100 into queries that are compatible with Internet protocols. The proxy server 180 communicates with the wireless network, which can include low bandwidth and high latency communications. The proxy server 180 decompresses information from the wireless network side for use on the Internet 190 side of the proxy server 180. Also, the proxy server 180 converts Internet protocols and content into a form that can be used by the wireless network and the wireless communications device 100. In some embodiments, the proxy server 180 can converts image content to a size and bit depth appropriate for display on the wireless communications device 100. In some embodiments, the proxy server 180 communicates over the Internet 190 using standard Internet protocols such as, TCP, HTTP, and SSL. This allows developers to use already existing Internet protocols in their web servers.

[0067] In some embodiments, the proxy server 180 is substantially stateless. That is, it does not keep state information about specific wireless communications device accesses. This configuration of the proxy server 180 tolerates communication and protocol errors more readily and allows for simpler scaling of the proxy server 180. Statelessness should not be confused with caching. The proxy server 180 can cache CML web pages for use by multiple wireless communications devices 100.

[0068] In order to achieve reasonable performance and cost over wireless networks, the browser 104 works in tandem with the proxy server 180. The wireless communications device 100 and proxy server 180 communicate with each other using a compressed transport protocol (CTP) built on top of IP. The goal of this protocol is to enable a user to fetch and display a web page on the wireless communications device 100 with a one packet request sent to the proxy server 180. Typically, a one packet response is returned to the wireless communications device 100.

[0069] In one embodiment of the invention, the maximum packet size (for higher protocol packets, like IP) allowed over a low cost wireless network is 512 bytes. Taking into account a compressed header (usually three bytes), the maximum raw data size is 512−3=509 bytes.

[0070] The proxy server 180 transmits a typical page of web content to the wireless communications device 100 in roughly 500 bytes. This can be challenging given that most web pages have lots of formatting information, hot links and images. Web pages are typically many Kbytes in size. A hot link reference can easily take up 100 bytes or more. Just to fill the wireless communications device screen 101 with text (11 lines of 35 characters each) would take nearly 400 bytes even if there were no formatting information included.

[0071] This is why the wireless communications device 100 and the proxy server 180 use compressed web pages.

[0072] The Internet 190 represents the Internet. However, the Internet 190 could be replaced by any communications network.

[0073] The web server 140 responds to web accesses. The web server 140 serves regular, and specially constructed, HTML pages. In this example, the wireless communications device 100 is accessing the special HTML pages (e.g., HTML page 144). The example query response 107 corresponds to the HTML page 144. In other embodiments of the invention, the same HTML page can be served in response to a query from the wireless communications device 100 as is served to other types of clients. The HTML page 144 is generated by the CGI 142. The CGI 142 represents a program that can dynamically generate HTML pages in response to HTTP requests.

[0074] Turning to the query and response elements, the wireless CTP query 122 represents a compact transfer protocol (CTP) formatted query from the wireless communications device 100. The base station 170 receives this query and forwards it to the proxy server 180. The forwarded query is represented by CTP query 124. The proxy server 180 takes the CTP query 124 and converts it into one or more HTTP queries 126. The web server 140 receives this HTTP formatted query 126 and generates an HTTP response 136 that includes the HTML page 144. The proxy server 180 receives the HTTP response 136, and generates the CTP response 134. The base station 170 generates the corresponding wireless CTP response 132. The wireless communications device 100 then generates the display on the screen 101 of the example query response 107. Before describing this process in detail, the browser 104 is described in greater detail.

Browser

[0075] The browser 104 and supporting wireless messaging programs comprise the client processing resources for some embodiments of the invention. The web browser 104 works well with both wireless and wireline connections, enabling users to seamlessly access the web whether they are connected through the phone line or not. The messaging support enables a user to send and receive wireless messages with other users that have Internet e-mail accounts.

[0076] The browser 104 support both wireless and wireline connections. An effective wireless browsing solution leverages the use of the proxy server 180 in order to deliver satisfactory performance. A solution embodied in the roles established for the wireless communications device 100 and the proxy server 180 dramatically reduces the amount of data that is sent between the wireless communications device 100 and the proxy server 180 over the slow wireless link. This form of browsing is referred to hereinafter as thin browsing.

[0077] The performance of wireline links, on the other hand, is high enough that a wireless communications device 100 can talk directly to a source of data such as a web content server using standard Internet protocols such as HTML, HTTP and TCP. This is how existing desktop browsers work and will be referred to hereinafter as standard browsing.

[0078] Thin browsing can be used over wireline links as well as wireless links. The only extra requirement is that the proxy server 180 be accessible to the wireless communications device 100 over the Internet or an intranet. Standard browsing, on the other hand, is more appropriately used over wireline links because of increased chattiness and bandwidth requirements.

[0079] The browser 104 is structured as a single user-interface that runs either a standard browser engine or a thin browser engine. With either engine, the user interface essentially appears the same, and the way original HTML web content is interpreted and displayed will be almost identical. The browser 104 relies on the proxy server 180 for reducing the amount of traffic and the number of transactions required. Although designed primarily for use over wireless networks, the browser 104 can be used over wireline networks as well.

[0080] The primary purpose of the thin browser engine is for accessing content designed specifically for the limited screen 101 size and functionality of a wireless communications device 100. For some embodiments, this layout and size are the only differences between content rendered for a wireless communications device 100 and existing desktops. Thus, content creators for desktop content can use the same tools that are used for creating and publishing desktop content when creating and publishing content for the wireless communications device 100.

[0081] Content rendered for the wireless communications device 100 can reside on standard HTML based web servers in standard HTML format (e.g., see web server 140). The proxy server 180 performs a dynamic conversion of the HTML content into the more compact CML form before transmitting the content to the wireless communications device 100.

[0082] The browser 104 will not prevent a user from accessing desktop oriented sites, but the browser 104 can behave differently when accessing them. For example, graphics can be ignored when not accessing a wireless communications device friendly site whereas the user will have the option to enable graphics for wireless communications device friendly sites. Another example of the difference is the browser 104 protects the user from unintentionally downloading a large desktop oriented site. A user option enables the user to set the maximum size desktop page that may be downloaded. If a page is encountered which exceeds this maximum size, the page is clipped by the proxy server 180 before being sent down to the wireless communications device 100. The user is able to set this maximum size on a page per page basis in the favorites list of the browser 104.

[0083] When the user first launches the browser 104, the browser 104 is able to display the user's home page without sending or receiving even a single byte over the network. This is in contrast to the standard web browser that go over the network to fetch the home page, or at least to check that the locally cached version of the home page is up to date.

[0084] The browser 104 relies much more on pre-loaded content. A transaction typically takes place over the wireless network only when necessary. For example, in some embodiments of the invention, the browser 104 assumes that the locally cached form is up to date and only submits a network request to the proxy server 180 after the user fills in a form requesting an update.

[0085] Thus, the browser 104 is particularly suited for accessing real-time data, not casual browsing. Thus, emphasis is placed on optimizing the process of filling out a form (e.g., with airline flight information) then submitting the form, and getting the real-time data back. Although, the user will still be able to casually browse any web site, the increased cost and volume of data involved with going to most standard web sites makes casual browsing relatively undesirable over a wireless network.

[0086] A typical user scenario for the browser 104 would then be as follows. The user extends, or rotates, the antenna on the wireless communications device 100 and thereby automatically power up the wireless communications device 100. The browser 104 displays the user's home page (stored in local memory). The home page has been configured by the user with a set of service icons such as weather info, traffic info, airline info, stock quotes, etc. before the browser is used. The user clicks on one of the service icons, such as the airline information. This starts the corresponding wireless application which contains a form. The browser 104 displays the form (also stored in local memory) for the user to enter the flight number or city codes. The user enters the information in the form and hits the “submit” button. Now, for the first time in this scenario, the browser 104 sends a request out over the network to fetch the airline information. When the response comes back from the proxy server 180 (three to five seconds later), the information for that flight will be displayed on the screen 101.

[0087] As just described, there are a number of significant differences between the browser 104 and a standard web browser. First, the primary usage of the browser 104 is for accessing real-time data through form submittal. Second, most forms are pre-loaded into the wireless communications device 100 local memory or present in read only memory. Third, forms are assumed to be valid, and therefore no activity will take place over the network until the user actually fills in the form and submits it.

Browser and HTML Compatibility

[0088] The following describes the HTML compatibility of one embodiment of the browser 104. Other embodiments of the invention have different features.

[0089] In order to display most content published today on the Internet 190, the browser 104 supports the most common features of HTML. However, because of the screen size and limited memory and performance of wireless communications device 100, some HTML features may be limited in functionality or not supported at all.

[0090] Because of a limited number of available fonts and font styles, the browser 104 may not render every possible text attribute in HTML. A number of font sizes and styles map to the same font on the wireless communications device 100. However, the user does not encounter significantly reduced readability or usability as a result of the mapping.

[0091] The proxy server 180, as directed by the wireless communications device 100, can filters out all images, unless the user explicitly enables images, or the content author imbeds the appropriate tag into the content indicating that this page is wireless communications device 100 specific and that the images should be downloaded to the wireless communications device 100.

[0092] All text hyperlinks can be supported. If images are downloaded, then image maps will also work.

[0093] Forms will have nearly full functionality. The only feature of HTML forms that may not be supported is the use of dialogs that let the user choose a file name by browsing the local directory structure on the wireless communications device 100.

[0094] Tables that are too wide to fit on the screen can be wrapped.

[0095] CGI (Common Gateway Interface) scripts can be supported. CGI scripts are used by the web server 140 to respond to form submissions by browsers and for customizing web content for a particular user. When the browser 104 requests a web document that corresponds to a CGI script, the browser 104 can append text parameters to the end of the base document URL. The proxy server 180 will parse the parameters out of the URL and send them to an executable program on the web server 140, as identified by the URL. Most CGI executables will then output dynamically generated HTML that is consequently returned to the browser 104 and displayed. From the browser's 104 point of view then, fetching a web document that uses CGI scripts is no different from fetching a static web document (other than having a slightly more complex URL).

Example Method of Wireless Communications

[0096] FIG. 2 illustrates a method of communicating between a wireless communications device and a web server. Such a method can be implemented using the system of FIG. 1.

[0097] The example method of FIG. 2 can be broken into three processes: a build a distributed web site process 202, a query process 204, and a response process 206. By using these three processes, a distributed web site can be created where static information is primarily kept on the wireless communications device 100 and dynamic information is kept on the web server 140.

[0098] At block 210, a content developer defines a wireless application. In one embodiment of the invention, this includes defining a number of HTML pages. The HTML pages represents the forms used for querying the web server 140. A program is then used to convert the HTML pages into compressed markup language pages to generate the wireless application 106. This process is discussed in greater detail below in the compressed markup language section.

[0099] At block 220, the web server 140 is created, or modified, to support reduced content HTML pages. An example of such a page is shown as HTML page 144. These pages can be generated exactly the same way as regular HTML pages. However, as a guiding principle, the amount of information should include little more than the absolute minimum of information that a user would find useful.

[0100] At block 230, a user loads the wireless application 106 onto the wireless communications device 100. This can be done as a HotSync™ operation in a manner similar to the way in which other applications are loaded onto the wireless communications device 100. The wireless communications device 100, for example, can be connected to a computer via a cradle and the wireless application 106 can be loaded from the computer. Alternatively, the wireless application 106 can be downloaded over the wireless network. However, this second method of loading the wireless application 106 is less desirable in that it will require a significant amount of bandwidth. Thus, in a preferred embodiment, the user loads the wireless application 106 over a high bandwidth network (e.g., the cradle download or by an infrared transfer from another wireless communications device 100).

[0101] Thus, some of the web site information is stored on the wireless communications device 100 and some of it is stored in the web server 140. Thus, the building of the distributed web site process 202 has been described.

[0102] The query process 204 includes the following steps. At block 240, the user fills in a query form 105 as part of the wireless application 106. In the example of FIG. 1, the user is filling out a form to find Italian restaurants in San Francisco. Once the user has completed the form, the user selects the look up button. The look up button causes the wireless communications device 100 to initiate the wireless CTP query 122. The block 240 is completed by the sending of the wireless CTP query 122 and the CTP query 124 to the proxy server 180. The wireless CTP query 122 is sent to the base station 170. The base station 170, and related hardware, perform any necessary changes to the wireless CTP query 122 to generate the CTP query 124, and send the CTP query 124 over the private network 172.

[0103] At block 250, the proxy server 180 converts the CTP query 124 to an HTTP query 126 and forwards that HTTP query 126 to the web server 140. Thus, the query process 204 is completed.

[0104] Now the response process 206 is described. At block 260, the web server 140 generates and sends an HTML page 144 to the proxy server 180. At block 260, the web server 140 generates the HTTP response 136 in response to the HTTP query 126. In this example, because the HTTP query 126 corresponds to a wireless communications device 100 query, the web server 140, and in particular the CGI 142, sends the HTML page 144 in the HTTP response 136. Returning to block 250, the conversion from the CTP query 124 to an HTTP query 126 may involve more than one HTTP request. This may occur where the web page has multiple referenced objects that need to be retrieved from the web server 140. Thus, the proxy server 180 may initiate multiple requests depending on the response in block 260. Note however, only one CTP request was needed.

[0105] At block 270, the proxy server 180 converts the HTML page 144 into the example query response 107 and sends the example query response 107 to the private network 172. The example query response 107 is inside of the CTP response 134, which is transmitted from the proxy server 180, across the private network 172, to the base station 170. The base station 170 then sends the corresponding wireless CTP response 132 to the wireless communications device 100.

[0106] The operating system 102 notifies the browser 104 that the wireless CTP response 132 has been received. The browser 104 requests the contents of the wireless CTP response 132 from the operating system 102. The contents are the example query response 107. Thus, at block 280, the browser 104 can display the example query response 107 on the screen 101.

Example User Interface

[0107] FIG. 3 includes a number of pictures showing an example display generated by the wireless communications device 100. These displays would be generated when a user attempts to find restaurants in San Francisco.

[0108] The wireless communications device 100 includes a launcher under which wireless applications can be grouped. The launcher interface 303 displays the list of available wireless applications. Note that the browser 104 is not specifically listed. This is because the user would typically only want to run a specific web site access application, not the browser 104 by itself. In this example, the user has selected “fine food” from the launcher interface 303.

[0109] In response to the selection, the example the browser 104 and the wireless application 106 begin executing. The browser 104 displays the example query form 105. The example query form 105 is a CML page in the wireless application 106. Then, the user can select/enter various field values for a query. In this example, the user is selecting the location field value “San Francisco”.

[0110] The completed query form 305 is shown next. The user now wishes to send the query. This can be done by selecting the “look up” button. This sends the wireless CTP query 122 out through the network and to the web server 140. The wireless communications device 100 then receives the wireless CTP response 132.

[0111] The response includes the information for the example query response 107. The browser 104 displays the example query response 107 on the screen 101. Here a number of restaurant names and phone numbers are shown. The user can scroll up and down through the list.

[0112] Also presented on the screen 101 is a toolbar 310. The toolbar 310 allows the user to perform various functions within the browser 104. The toolbar 310 includes a back button, a connection indicator, and a drop down list. The back button allows the user to go back to the previous query form. The wireless communications indicator indicates whether the wireless communications device 100 is performing a wireless communications query. The drop down list indicates a history of the query results that the user has requested during past use of the browser 104.

Wireless Network Topology

[0113] FIG. 1 and FIG. 4 show the general topology of a wireless communications network. As shown, the wireless client 405 (in FIG. 4, the wireless communications device 100 and its software have been combined into the wireless client 405) communicates directly with the proxy server 180. The wireless client 405 does not communicate directly with the actual source of data. The source of data can be a web or mail server that has content desired by the wireless client 405. FIG. 1 shows the Internet 190 as the source of data and the source of data will be referred to as the Internet 190 throughout this application. Using this scheme, the wireless client 405 and the proxy server 180 can use a much more efficient (“thin”) protocol between themselves than used by Internet mail and web servers. On the other hand, the proxy server 180 uses standard Internet protocols (HTTP, TCP) when communicating with existing mail and web servers. The proxy server 180 acts as an agent. The proxy server 180 takes requests from the wireless client 405, obtains the requested information from the Internet 190, and re-formats and sends the requested information back to the wireless client 405. The proxy server 180, acting in this manner, can hide the relatively chatty and bandwidth intensive protocols used by standard Internet 190 servers from the wireless link.

[0114] The thin protocols used between the wireless client 405 and the proxy server 180 are IP based. IP based protocols are widely used and enable the wireless client 405 to communicate with many different wireless networks. Furthermore, basing wireless client 405 and proxy server 180 processing resources on IP provides a layer of isolation and independence from the actual wireless network in use.

[0115] FIG. 4 shows a wireless network topology 400 used for some embodiments of the invention. The main components of the wireless communications system are the wireless client 405, the wireless network access point 410, the tunneler 430, the proxy server 180, and the Internet 190. The wireless network access point 410 has a corresponding wireless network access point radio 420.

[0116] The wireless client 405 communicates across the wireless network using its own client radio 440 to transmit messages to and receive messages from the wireless network access point radio 420. The wireless network access point 410 is the nearest regional station in a wireless network with a connection to a proxy server 180. The wireless network is by nature not IP based, and its most basic packet type is referred to herein as wireless network protocol packet (WLNP). Consequently, the wireless client 405 encapsulates its IP packets with a WLNP header before the packets can be sent by the client radio 440.

[0117] The packets sent over the air include a number of headers in the following order: a WLNP header, followed by a compressed user datagram protocol (C-UDP) header, followed by a reliable message protocol (RMP) header. The headers encapsulate a Request/Response Message Fragment (RQMF/RSMF) of the packet. The RQMF/RSMF of each packet holds the message fragments. These fragments are commands, requests, and responses sent between a wireless client 405 and the proxy server 180 that enable a wireless client 405 to browse web pages, send and receive e-mail, and otherwise obtain access to content.

[0118] In some embodiments, the wireless network has guaranteed delivery built into it. For these embodiments, it is not necessary to incur the extra overhead of a full connection-oriented protocol such as TCP on top of the wireless network protocol. Instead, the wireless client 405 uses the Internet 190 UDP. The UDP is a simple datagram based, best effort delivery protocol. Using UDP, it is possible that a web page can be viewed from the wireless client 405 by sending just one packet up to the proxy server 180 and receiving just one packet back. The TCP protocol, on the other hand, would require a minimum of 5 packets back and forth between the proxy server 180 and the wireless client 405 to view the web page. The wireless network does not, on the other hand, guarantee order of delivery, so an RMP header is placed in front of the data area in each UDP packet. The RMP is used to detect and correct for out-of order or duplicate packet deliveries.

[0119] Instead of using raw UDP internet headers which are 28 bytes in length (20 bytes for the IP information, 8 bytes for the UDP information), the wireless client 405 uses a smaller, compressed form of the UDP header called C-UDP. A C-UDP header contains just enough information so that the actual IP/UDP header can be reconstructed at the other end of the wireless link. There are a number of fields in a standard IP/UDP header that are rarely changed and/or redundant over the wireless network and these fields can be highly compressed or left out altogether in the C-UDP header, as discussed in greater detail below.

[0120] The wireless network access point 410 receives WLNPs that have C-UDP packets imbedded in them. The WLNP header is stripped off the front of the packets by the tunneler 430 for the wireless network. The original IP header and UDP header are reconstructed, and the packets are then forwarded to the proxy server 180 through a TCP connection. Because an unreliable network (LAN or Internet) is used between the wireless network tunneler 430 and the proxy server 180, TCP is used to guarantee that the packets get transferred reliably.

[0121] The TCP stream that the proxy server 180 receives from the tunneler 430 has the imbedded IP packets. The IP packets contain request message fragments. The reliable message layer (shown in FIG. 6 as reference number 635) on the proxy server 180 reconstructs the original request message from the message fragments in the packets using the information contained in the RMP header area of each packet. The requested information (web page or e-mail) is then be fetched as a data object from the Internet 190, re-formatted, and passed back to the reliable message layer 635. Proxy server 180 processing resources operating in the reliable message layer 635 break down the data object into separate packets for transmission to the wireless client 405, and send the packets to the tunneler 430 through the TCP connection. The tunneler 430 forwards the packets back over the wireless network to the wireless client 405.

[0122] FIG. 5 illustrates the wireless network topology including a wireless network interface 510, a wireless network leased line 520, and a dispatcher 530. FIG. 5 shows how the wireless client 405 and proxy server 180 communicate when the wireless client 405 is on a wireless network. Notice that the wireless client 405 is directly on the wireless network whereas the proxy server 180 is not. The wireless packets do not get sent directly to the proxy server 180. Instead, they first pass through the base station 170, a wireless access point 410, and tunneler 430 before they are sent to the proxy server 180 over a wireline LAN (Local Area Network) connection.

[0123] Wireless client 405 processing resources send messages through the reliable message layer 635. Since the wireless client 405 is on a wireless network, the reliable message layer 635 uses the RMP protocol to send the messages. The RMP protocol encapsulates the message fragments with an RMP header and sends them through a UDP socket in the network library (shown as 1110 in FIG. 11 and discussed below). The packets work their way through the IP stack on the wireless communications device 100, which adds UDP header and IP header. The packets are passed down to the wireless network interface 510 for transmission.

[0124] The wireless network interface 510 then compresses the IP header and UDP header of the packet into a C-UDP header, and adds the wireless network protocol (WLNP) header. FIG. 5 shows the wireless network interface 510 adding a WLNP header that is used on the wireless packet data network. Other networks will have similar headers. Much of the information in the IP and UDP headers is redundant with the WLNP header, so the C-UDP header can be significantly smaller than the sum of the IP header and UDP header.

[0125] The WLNP encapsulated packets are sent over the radio and are received by a base station 170. The base station 170 passes them to a wireless network access point 410. The wireless network access point 410 then passes the packets through a wireless network leased line X.25 link to the tunneler 430. The X.25 link can be a 56 Kbps leased line or a high speed frame relay connection. Although FIG. 5 shows only one tunneler 430, two tunnelers are typically used for the wireless packet data network. In one embodiment, the first tunneler is part of the wireless packet data network infrastructure and is referred to as the “Internet Access Server” or LAS. The IAS tunnels the WLNPs from the wireless network access point 410 into a TCP stream and sends this stream to a proxy server 180 specific tunneler. The proxy server 180 tunneler takes each WLNP from the IAS stream and converts its WLNP/C-UDP headers into normal IP/UDP packet headers. Thus, at this point in the chain of events, the packets look identical to the way they looked when the wireless client 405 first passed them to the wireless network interface 510 on the wireless communications device 100.

[0126] The tunneler 430 then sends its output stream to a dispatcher 530. The dispatcher's job is to load balance among multiple proxy servers 180. The dispatcher 530 distributes wireless client 405 requests that the dispatcher 530 receives from the tunneler 430 among a set of proxy servers 180. In order to do this, the dispatcher 530 checks the source IP address and UDP port number on each packet to determine whether the packet corresponds to a new transaction. If the packet corresponds to a new transaction, the dispatcher 530 selects the proxy server 180 with the lightest load and sends the packet to that proxy server 180. If the packet does not correspond to a new transaction (i.e. the 2^nd packet of a two packet request), the dispatcher 530 looks up the proxy server 180 used for the previous packet of this transaction and sends the packet to that same proxy server 180.

[0127] Finally, the packets are received by the proxy server 180. The proxy server 180 gathers the request packets from the dispatcher 530, reassembles them into the original CTP request message, processes the request, forms a response, breaks the response down into separate IP/UDP/RMP packets, and then sends the response packets back through the TCP socket to the dispatcher 530.

[0128] The proxy server 180 receives entire IP packets imbedded in the TCP stream that the proxy server 180 receives from the dispatcher 530. These packets are re-ordered and re-assembled into the original message before the request is processed. The IP, UDP, and RMP headers are stripped off and the information in the RMP and UDP headers used to re-construct the original request message. When a response message is formed, the response message is split into separate packets as necessary. IP, UDP and RMP headers (with source and destination machine addresses and port numbers swapped) are pre-pended to the packets before they are sent via TCP to the dispatcher 530 where the packet continues its journey back to the wireless client 405.

[0129] A few important points should be noted about this wireless setup. First, the only components that are specific to the wireless network are the wireless network interface 510 on the wireless client 405, and the tunneler 430 at the proxy server 180. The wireless client 405 application software, reliable message layer 635 and all of the software on the proxy server 180 are strictly IP based and do not have to change if a different wireless network is used.

[0130] Second, the tunneler 430 and the dispatcher 530 are not required to be placed on the same physical machine as the proxy server 180. If the tunneler 430 and the dispatcher 530 are on the same machine as the proxy server 180, the LAN link between the three system elements becomes a virtual TCP connection through the IP stack on the proxy server 180. This may seem to be preferable from a performance point of view, but, there are many more advantages to having the dispatcher 530 and proxy servers 180 on separate machines. If the dispatcher 530 is on a separate machine, the dispatcher 530 can distribute wireless client 405 transactions among multiple proxy servers 180, thereby providing both scalability and fault tolerance. If any one of the proxy servers 180 become inoperative, the dispatcher 530 can stop sending requests to the inoperative proxy server 180. Because the communications system has multiple proxy servers 180 the dispatcher 530 can distribute the load between them. The dispatcher 530 therefore becomes the most sensitive link in the chain from a fault tolerance point of view. But, from a performance point of view, the dispatcher 530 has very little work to do for each transaction compared to the proxy server 180 so it makes sense to have multiple proxy servers 180 per dispatcher 530 (and tunneler 430). If necessary, multiple tunnelers 430 and dispatchers 530 can be placed in parallel to provide even more fault tolerance and scalability.

[0131] A third important point is that the only unreliable link in the whole chain is over the wireless network, i.e., between the wireless network interface 510 on the wireless client 405 and the base station 170. In particular, the link between the base station 170 and the proxy server 180 is a reliable link all the way through. The RMP logic on both the wireless client 405 and proxy server 180 is simplified because the RMP logic only corrects for lost and unordered packets over the wireless network, not the wireline network between the base station 170 and the proxy server 180. This simplified RMP logic enables the timeout values used for re-transmission attempts to be tuned for just the wireless portion of the network.

Intranet Topology

[0132] A corporate wireless Intranet is setup in the same manner as the Internet solution just described. The only major difference is the physical location of the machines. For the Internet solution, the proxy server 180 is located at the wireless network access point 410 and has a connection to the global Internet. For a corporate Intranet solution, the proxy server 180 is located at the corporation's own private site with a leased line to the nearest wireless network access point 410. The leased line transports the WLNPs between the wireless network access point 410 and the corporation's own tunneler and proxy server 180. The proxy server 180 has a direct connection to the corporation's private Intranet.

Method and System Using Palm-Sized Computer for Data Network Management

[0133] Using a palm-sized computer, particularly via a wireless link, for data network management is an application of low bandwidth wireless communications.

Network Inventory

[0134] A Network Inventory application provided by some embodiments of the invention provides device inventory and detailed device sizing information on a handheld communications device 100 such as the Palm VII™ portable computer. This application provides network administrators an alternate and flexible method of accessing information about the devices in their network. Network Inventory provides an automated means to copy the inventory of network devices that have been discovered by the network management platform to the communications device 100. Network Inventory can view detailed information about the device as well as perform simple queries against the data. Network Inventory provides an aid to the network analyst in identifying where the devices are located, their configuration, etc.

[0135] With network administrators becoming more mobile, managing networks solely from the Network Management Station (NMS) can impose burdensome restrictions on the administrators. The Network Inventory application addresses this problem by providing the communications device 100 with information from a network management database. The network management database can be the Transcend Database™, a product of 3Com. With the help of the Network Inventory application, the network administrators have access to the information anytime on their handheld communications device 100. For example, in a wiring closet it is not necessary to have access to a console terminal or an NMS for the user of the Network Inventory application to find out what version of software a particular device is running.

[0136] The Network Inventory application is adapted to work with 3Com's Transcend Enterprise Manager (henceforth known as Transcend). In some embodiments, the Network Inventory application can be installed on the Network Management system running Transcend. In some embodiments, Network Inventory mimics Transcend Central the device Inventory tool, one of the Transcend suite of applications.

[0137] Key features in Network Inventory include,

1. Retrieving and processing the data from Transcend databases.

2. Uploading all or selected data from the Network Management System to the Pilot.

3. Presenting the data on the Pilot in a familiar and easy to understand and navigable format. Some embodiments of Network Inventory include data editing and two-way synchronization features.

[0138] Generally, a network inventory program is installed on the communications device 100, and the network management application, e.g., Transcend, is installed on the NMS along with a desktop version of the handheld communications device and a backend synchronization server.

[0139] The network inventory program has been designed with the following key goals in mind:

• [0140] 1. To be lightweight and robust to ensure minimal system requirements and memory usage, especially considering the capabilities of the handheld device.
• [0141] 2. To be compartmentalized so that data processing and transfer is independent of data presentation on the handheld communications device 100.
• [0142] 3. Provide control over the type and amount of data transferred to the handheld communications device 100.
• [0143] 4. Be easily integrated into the Transcend suite of network management applications for the handheld communications device 100.

[0144] The Network Inventory application is installed on the communications device 100 with an empty database. As shown in FIG. 5A, Transcend 534, communications device 100 desktop and the Backend Synchronization Server 536 are installed on the NMS 532. The HotSync Manager 538 and the Sync Server 536 need to be running on the NMS. When the communications device 100 is placed in the communication cradle connected to the NMS and the HotSync button is pressed, the HotSync Manager 538 on the NMS is activated and it in turn activates the Sync Server. The Sync Server then queries the Transcend Database for device information and then uploads this information to the Network Inventory application on the communications device 100, such as the Palm VII.

[0145] The application may be architecturally divided into two components, the Backend Synchronization Server (henceforth known as Sync Server 536), and the client user interface 540 component.

[0146] The Sync server 536 component resides on the Network Management Station 532. For some embodiments of the invention, the key functions of the Sync server 536 are,

• [0147] 1. Transfer data from Transcend database to a format that may be interpreted by the client on the hand held device.
• [0148] 2. Upload data to the client during a Synchronization process.

[0149] Transfer of data from Transcend database involves two distinct stages. Network device information is discovered and the information is stored and maintained by Transcend in a relational structured query language (SQL) database. Stage 1 involves extracting this information from the central database 540 and converting it into an intermediary format. As shown in FIG. 5B, this transformation of data is accomplished by using the ISQL database engine 542 provided by Transcend itself. The SQL statements required to transfer the data generated on the fly by the Sync server 536. The CSV format data generated is stored in flat CSV format files 544 in computer memory.

[0150] As shown in FIG. 5C, Stage 2 of the operation involves further transforming the output obtained in stage 1 (CSV format data 544) into a final format (DBF format 548) that is easily interpreted by the client on the handheld communications device 100. This transformation is accomplished by using Microsoft Access runtime version or a similar application. In some embodiments, Stage 2 includes importing CSV format data 544 into internal Microsoft Access database tables and Exporting data in internal tables to dBase 5.0 format data (DBF format 548) in flat files.

[0151] At this point the data is considered completely transformed and ready for upload to the handheld communications device 100. The definition of the data structures containing data on both platforms (desktop as well as handheld device) are, for the most part, purposefully kept exactly similar.

[0152] The second key function of the Sync server 536 is uploading the transformed data to the handheld communications device 100. This involves co-ordination between the handheld communications device 100, the HotSync Manager 538 software and the Sync server 536.

[0153] In some embodiments, as shown in FIG. 5D, the Sync server 536 component constantly executes on the desktop, waiting for a synchronization action to occur. A synchronization action occurs when the user presses the synchronize button on the handheld device cradle. During a synchronization action, the Hotsync manager 538 software calls upon the Sync server 536 to perform the required synchronization of data associated with the client 405 software on the handheld communications device 100. In some embodiments, the Sync server 536 in turn relies on an ActiveX control 536A (provided with Satellite forms, SoftMagic Corp) to perform the actual uploading of data to the handheld communications device 100. The DBF format data 548 output in Stage 2 previously is now uploaded into corresponding data tables on the handheld communications device 100.

[0154] Once data is uploaded into the handheld communications device 100, it becomes the responsibility of the Client 405 to extract data from the database, interpret the data and present it to the user in an easy to understand format. After data upload is complete, the Sync server 536 returns to its passive state and waits for the next sync request from the user.

[0155] In some embodiments, the Satellite Forms IDE from Puma Tech can be used to create the User Interface. All the device and group information can be stored as tables on the communications device 100.

[0156] As shown in FIG. 5E, the application can start by displaying the four default groups:

1. 3Com Products

2. Application Specific

3. By Device Type

4. User Defined

[0157] When one of the groups, say “3Com Products,” is selected all the groups that belong to “3Com Products” are displayed, as shown in FIG. 5F. If one of the groups, say “Super Stack II Devices,” is selected then all the devices belonging to this group is displayed, as shown in FIG. 5G. The “previous” button on all the forms takes you back to the previous form and the “To Main” button takes you back to the first main form with the default groups.

[0158] FIG. 5G shows the DeviceName and IPAddress of the devices belonging to “Super Stack II devices” group. If one of the devices is selected then detailed information about the device is displayed, as shown in FIG. 5H. This form has three tabs.

1. Details

2. Module

3. Port

[0159] The Details tab shows the MibII information of the device. Device Name, IPAddress, Device Type, Software Version, System Location, Contact, Read Community String and the Write Community String. Selecting the “Note” button displays a notes form in which the user can enter any notes or reminders about the device.

[0160] Selecting the Module Tab takes you to the Module Form as shown in FIG. 5I. The Module Form displays information about all the modules present in the device. The Mod# field is a dropdown list which lists all the modules available. Selecting any of the modules from the drop down list updates the Module Type, Software Version, Hardware Version, and status fields with the appropriate values of the selected module.

[0161] Selecting the Port Tab displays the Port Form, like the Module Form the Port Form displays all the Ports belonging to the device and their corresponding information, as shown in FIG. 5J.

[0162] Selecting the Find button displays the form shown in FIG. 5K. Here the user can search for a device on hostname, IP Address, device Type, Sys Location and Contact. A partial string can be used for the search. The result shows a list of devices that match the search and detailed information can be got on them.

[0163] The device and group data shown in the User Interface (UI) Forms can be stored in tables. There is a corresponding table for Device, Group, GroupMembers, Module and Port. Other than these tables, there are temporary tables used to store for example the resulting devices on a “Find” action.

[0164] Anytime a Group or a Device is selected from the form, the UI logic searches through the tables and figures out the devices belonging to that particular device, stores these results in a temporary table and displays them on to a Form.

[0165] For some embodiments, the following are considered requirements for the Sync server 536 software: (1) Transcend Network Management 534 software is installed and available on the computer on which Network Inventory is installed. This ensures the availability of the central database repository containing Inventory and sizing information. Transcend installation also ensures that the SQL engine required to transform data as in Stage 1 also exists. Note that Sync server 536 assumes that devices on the network have been previously discovered by Transcend 534. Transcend 534 is not expected to be running. (2) Palm desktop software for synchronization has been installed and is available on the desktop computer on which Network Inventory will be installed. This ensures availability of the Hotsync manager 538 software that invokes the Sync server 536 during a sync request by the user.

[0166] Some embodiments have the following characteristics: Only the changed row in the Transcend Database is updated to the communications device 100. The user can make changes to the Network Inventory app and sync those changes to the Transcend Database. The data sync'd from the NMS to the communications device 100 is compressed to improve the performance of the time taken to Hotsync. The Transcend Database can be accesses using a wireless sync.

Transcend Web

[0167] A suite of network management services, such as those referred to as “Transcend,” can be aimed to pro-actively deliver information from a regular HTTP web site to the customer's Palm VII, or other communications device 100, via wireless transmission. The HTTP web site in question can be 3Com's corporate web site, the customer's Transcend Network Management Station or some other web site related to managing the customer's network connected devices. One or more services can be installed on the communications device 100 depending on the need. These services are intended to enhance s web-management of a network from the communications device 100. By integrating a Network Manager program and provider, e.g., 3Com, Web Services, in the communications device 100, the user is “More Connected”. The integration allows access to management information in a timely, simple way that is independent of geographic location of your wireless the communications device 100.

[0168] Integrating the communications device 100 with Network Management provides the following key benefits:

Enhanced ease and simplicity of network management.

Alternate access mechanism to obtain Network Management information.

Geographic-independent Network Management, Remote Network Management (e.g., using a PalmNet Service.)

A real-time management tool (troubleshooting, status monitoring, etc.) that reduces the physical restrictions imposed by traditional access mechanisms.

A cost-effective solution for basic Network Management.

Placement of Network Management in a palm-sized computer.

Timely, speedy Access to information when you need it, where you need it.

Reduced cost of managing your network.

Network Management Mobility.

[0169] For information to be delivered quickly from the Internet and displayed readably on a handheld communications device 100, the information is preferably compatible with the equivalent of a 2K/bps link and a 160×160 display, incurs the smallest possible amount of airtime cost, and causes the least depletion of the battery. The Transcend Web applications: namely, Information Services Online and 3Com Case Tracker, have been designed with these preferences in mind. While accessing the information, you get only the clipping of the WebPages, the part you really need.

[0170] As shown in FIG. 5L, these wireless applications are partitioned in such a way that the query form of the application is stored locally on the handheld device. So, it can be retrieved instantaneously. The user can fill out the request without ever going online, and no bandwidth or time is spent getting to the query form. On submitting the query, the response clipping gives just the needed data. Less data transferred means lower cost of ownership, less latency and longer battery life.

[0171] Transcend Web provides many services. Some services can be accessed by everyone and are therefore outside the firewall. For example, “Information Services Online” allows users to access free agent software, release notes, bug lists, and many other documentation required to manage network. Access to other services, such as the information of Network Management station 532, requires penetrating the firewall. Services outside the firewall can be accessed directly.

[0172] A key component of wireless communication is the proxy server 180 that resides in Palm's data center 550, shown in FIG. 5M. The proxy server 180 is responsible for converting the Internet protocols and content into a form that's acceptable to a wireless network and a small device, and vice-versa. As shown in FIG. 5M, the server talks to the standard Internet protocols (TCP, HTTP, and SSL) to HTML servers to maintain compatibility. On the wireless side, however, the proxy server must adjust everything to support extremely low bandwidth and latency. Data coming from the Internet is compressed. UDP protocol is used to talk to the handheld. Use of UDP enables one packet up (the query) and one packet down (the clipping). This simple protocol greatly reduces latency and conserves battery consumption.

[0173] For Services behind the firewall, standard-based Secure Socket layer approach is used to protect data on the Internet. As shown in FIG. 5N, the solution involves supporting an SSL server outside the firewall, which communicates through a pinhole back to enterprise data. No special connectivity or device configurations are required for this solution. The next level of security involves closing access to all traffic except the trusted fixed IP address of the Palm.Net data center. This methodology ensures that only packets from the trusted 3Com data center are allowed through. As long as the Palm Web clipping Proxy can address a URL inside the corporate firewall, Palm VII device enterprise users can access that data. An additional password protection security will also be provided.

Application Design/Architecture

[0174] Following are key architectural requirements that need to be satisfied for some embodiments of the invention. The architecture should be lightweight and robust. The architecture must accommodate one or more Transcend suite of services to be optionally installed. The architecture must accommodate working via a proxy server without firewall and with the firewall of Transcend Network Manager. The application should require least administration from the user. The architecture should accommodate for day-one management architecture. The architecture should have an open interface, thus allowing new applications to integrate with minimal changes.

[0175] Any pqa-based Transcend application needs to be “Palm Friendly”. Contents that work with Palm VII organizers are known as “Palm friendly”. One needs a standard HTML editor, a Windows 95/NT utility that Palm provides called the Query Application Builder. The Query Application Builder is a software utility that is used to convert standard HTML content into a .pqa file on a PC. The query application contains static content and can only be updated by creating and installing another form.

[0176] Once the application is partitioned between which components reside on the device and which reside on the server, the Query Application Builder is used. The Query Application Builder will traverse the hyperlinks of all the pages and images included in query application and build a single Palm OS installable application—the .PQA. The application is installed on the user's device using the HotSync Manager, and appears in the Wireless category of the Application launcher, along with any other wireless application installed on the user's device.

Web Applications for the Palm

[0177] Historically, 3Com delivers management services via native services, Transcend Network Control Services, and 3Com's web site. Native services include telnet via TCP, CLI via serial connection, embedded Web server via an HTTP connection. Transcend Network Control Services are a management suite which is typically installed on a few selected management workstations, Unix or WinTel based machines. Recently, part of the capability the is distributed via the web. 3Com's web site provides access to release notes, software updates, knowledge base, etc.

[0178] Access to these services has different requirements. For instance, access to 3Com's web site requires access to the Internet. Access to CLI via serial requires a VT100 terminal. HTTP unifies access to the device natively (via the embedded web server), TNCS (via the embedded web server), and 3Com's web site. The Palm VII's wireless capability nicely extends this HTTP capability to any location where a wireless connection can be established.

[0179] With the proper setup, a mobile user can use the Palm VII to access important management information via HTTP. For instance, the palm-sized computer can be used with wireless communications to make urgent changes to a device's configuration via the device's embedded web server. It can access historical fault or performance data, view the audit log or trap log, for a device. This type of information is typically kept at the TNCS management station. It supports accessing release notes, known bugs, workarounds, software updates from 3Com's corporate web site. A user can access other pertinent information related to the day-to-day management of a network based on 3Com equipment. An example is viewing an RFC at the IETF's site.

[0180] Two types of access are described in further detail. First, accessing the wealth of release notes, known bugs, workarounds and software updates from 3Com's corporate web site. Second, accessing the detail case history of individual cases reported by customers to 3Com's CSO.

Information Services Online

[0181] The first type of access provides smooth delivery of new agent release information, delivery of network context sensitive information to customers, pro-active software maintenance and troubleshooting tips. Further, allows to access 3Com KnowledgeBase, Problem Tracking and User Documentation. All these services intend to have an efficient search tool to access the needed information in a speedy way with less airtime cost.

[0182] KnowledgeBase serves the purpose of accessing the information about the device from a wiring closet to anywhere independent of the geographic location. Thus, allows unbounded capability to manage the devices.

[0183] Problem Tracking is another service that allows a user to interactively track the issues for which he has asked 3Com support. The service gives detailed information about the issue he had filed and how far it has been taken care of. It also allows user to give his input in the form of extra information or comments.

[0184] User Documentation includes all the critical documentation a user would need to manage devices in his network. It also includes online help to be able to access customer support.

[0185] Release Notes Service allows accessing Release Notes of a device on Palm. Only the critical information is displayed in an organized and easy to access way.

[0186] Software Service is used to publish software releases and device support releases based on dates queried by the user.

Case Tracker

[0187] Case Tracker is an application that enables both the CSO and the customer to address the customer's Case. A CSO representative can attend to a pending case from anywhere and in an organized fashion, thus speeding up the time to attend to the cases listed by the customer. Similarly, the customer can search all the critical information about his case with his easiest search tool from anywhere. Thus it greatly eases managing of his network real-time without having to be near a terminal.

Components

[0188] Transcend web applications comply with any other Palm wireless application. It has a PQA file as local on Palm acting as a query application and Palm friendly web clippings on the server end. These web clipping could be put in a database on the server-end to enhance search efficiency. Queried web clipping can be outside the firewall or behind the firewall depending on the information queried. In case of firewall, PalmNet allows the authenticated user to penetrate the firewall with the pinhole approach. Thus, providing secured transfer.

[0189] In some embodiments, the Transcend suite of Services will provide enhanced services. A full-fledged Information Services Online application would enable smooth delivery of new agent release information, delivery of network context sensitive information to customers, pro-active software maintenance and troubleshooting tips complying with day-one management. A Case Tracker would have enhanced capabilities of search and getting detailed information. It would be adapted to configuring of devices with Palm. It would make all core Transcend applications talk to Palm. It would make Network Inventory wireless. It would take the advantage of infrared capability of Palm, to access data from Network devices in the wiring closet. And it would make the wireless connected Palm beep for traps and critical e-mails related to Network Management.

[0190] Content Layer

[0191] This section covers the implementation of the wireless communications device 100 content layer. The content layer deals with how web content and personal messages are formatted and rendered on the wireless client 405. In particular, this section discusses the Hypertext Markup Language (HTML) and Compact Markup Language (CML) page description languages.

[0192] When using the standard browser engine, the wireless client 405 web browser application renders HTML obtained directly from the web content server. When using the browser 104 however, the wireless client 405 renders CML which has been dynamically generated from HTML by the proxy server 180.

[0193] When the wireless client 405 e-mail application sends or receives personal messages with the proxy server 180, it also uses CML to format the messages. Sending and receiving graphically formatted messages is not a specified requirement of the wireless communications device 100, but CML is used for the message format because it also provides excellent raw text compression. An added benefit is that CML provides the framework required for graphically oriented messaging applications.

[0194] There are two basic challenges in the design of the browser 104. The first is effectively rendering existing web content on a very small screen. The second challenge is minimizing the amount of data that is sent over the wireless network when using the browser 104 engine. The HTML page description language works fine for answering the first challenge, but is not an appropriate choice for answering the second challenge. HTML was designed as an “ideal” language for creating content. HTML is human readable, human editable, and screen size and depth independent. This makes it a very good general purpose page description language, but also a very verbose language and too large to transmit wirelessly. CML answers both challenges because CML also minimizes the amount of data that is sent over the wireless network. In order to achieve its minimal size, CML sacrifices both human readability and editability.

[0195] As a further optimization, the CML is created dynamically at run-time by the proxy server 180 using knowledge of the screen size and depth of the wireless client 405. Thus, the wireless client's 405 very limited screen 101 functionality will enable the proxy server 180 to generate a much smaller CML representation than the proxy server 180 could otherwise. For example, elements that do not fit on the wireless client 405 screen 101 could be left out altogether and images that are too deep for the wireless client 405 screen 101 are depth converted before being transmitted.

[0196] Ideally, the user is not aware of whether CML or HTML is used to render content. Therefore, both page description languages provide the same feature set. However, the implementation of the two languages is significantly different because CML provides the necessary compression to accommodate the wireless network bandwidth. To accomplish these goals, CML is optimized for small wireless clients 405. However, alternate and larger forms of representation can be used to implement the full feature set of HTML when necessary.

[0197] This following provides a description CML, followed by descriptions of HTML features, how each HTML feature is displayed and used in the browser 104, and finally how that feature is represented using CML. Keep in mind that the appearance of a HTML feature is independent of whether or not it is sent to the wireless client 405 in raw HTML format or as CML.

[0198] Compact Markup Language (CML)

[0199] In order to send web content to the wireless client 405 in a minimal number of bytes, the proxy server 180 does not use the HTML standard generally used by Internet servers. In HTML, all the tags and attributes associated with text, tables, forms, etc are text based, typically take up from 3 to 10 bytes each, and are stored both at the beginning and end of the text that they modify. For example, to display emphasized text, a web document would have to contain the following HTML sequence: <STRONG>This is emphasized text</STRONG>.

[0200] The wireless client 405 and the proxy server 180 use a special format for transferring screen 101 contents from the proxy server 180 to the wireless client 405. This format, named Compact Markup Language (CML), emphasizes compactness over readability and generally uses variable length binary bit fields instead of text to represent options and formatting information. The differences do not end there however; CML will use a host of other methods for reducing the number of bytes that is sent between the proxy server 180 and the wireless client 405.

[0201] CML compresses all text. In one embodiment, the default CML compression scheme formats text using a form of a five-bit character alphabet with escapes. This default compression scheme works best with pages that have mainly lower case alpha letters in them, but does allow for a full range of characters including characters with ASCII values greater than 128.

[0202] CML also leverages the fact that the proxy server 180 knows the screen size and bit depth of the wireless client 405 when encoding the layout of the content. HTML was designed to be screen independent—neither the server nor the content creator knows ahead of time what size or depth screen upon which the document will eventually be rendered. Besides the obvious advantage of not sending content that wouldn't fit on the wireless client 405 screen 101, there are other cases where content can be encoded in a more compact form by the proxy server 180 because it knows the size of the wireless client 405 screen 101. Since the proxy server 180 also knows the bit depth of the wireless client 405, the proxy server 180 can also reduce the data sent to the wireless client 405 by not sending color attributes such as the background color, text colors, underline colors, etc.

[0203] The major emphasis of CML is that it is optimized for size. In other words, readability and flexibility are compromised for compactness. One major design philosophy difference between HTML and CML is that CML is not designed as a content creation language. CML is merely a temporary format used to represent content as it is being transferred between a proxy server 180 and a wireless client 405. As such, CML is algorithmically generated, much like object code is generated from a compiler. The analogy to compilers is even stronger when you take into account the fact that CML is generated with the screen size and attributes of the wireless client 405 taken into account. The same HTML content can produce different CML representations for two wireless clients 405 that have different screen sizes—much like compilers for different microprocessor produce different object code from the same source code.

[0204] Essentially, CML is a stream of text and image data with imbedded formatting commands (tags). The tags are imbedded as binary data and hence are very compact. Every tag is “sticky”; that is the tag continues to have an effect until explicitly changed by another tag of the same type. For example, a tag in the front of a document that specifies bold text makes the entire document bold, unless another tag later in the document turns off the bold formatting. This is in contrast with many HTML tags, such as paragraph formatting commands, that only affect the next paragraph.

[0205] Another important difference between CML and HTML is that white space and line breaks in the text are significant. For CML, the equivalent of the HTML line break tag (<BR>) is not required in CML since line breaks are imbedded directly into the text.

[0206] The default behavior of CML is to compress all text by encoding it using a special 5-bit character alphabet discussed below in the CML Structure section. This form of compression works best for documents that are mainly comprised of lower case roman characters. Other forms of text encoding, including 8 bit ASCII, unicode, etc. are used in CML only when necessary.

[0207] Using CML and the CML structure described below combined with CTP formatting of forms, some embodiments of the invention comprise a method for transmitting a message from a wireless client 405 to a proxy server 180. The method comprises transmitting a single message from the wireless client 405 to the proxy server 180. The single message comprises a single packet of data. The single packet of data having a base document uniform resource locator followed by compressed data. The compressed data comprises references to fields in a hyperlink document and an indication of use of the hyperlink document. The hyperlink document is in the base document. In some embodiments, the size of the single packet of data is less than one kilobyte.

[0208] In some embodiments, the references to fields comprise field values and field indices corresponding to fields in the hyperlink document. In some embodiments, the base uniform resource locator is expressed in a compact transfer protocol by a binary string. The binary string comprises a first field indicating the encoding scheme used for the single message.

[0209] Compact Data Structure Notation

[0210] Throughout the rest of this application, CML will be represented using a notation similar to that used in the C language for representing data structures. This notation will be called Compact Data Structure Notation (CDSN) and is also used later in this document when describing the CTP protocol. An example of this notation is:

• • [0211] Bit enabled=1
  • [0212] Bit[3] type=typeRound
  • [0213] Int16 length=0x1234
  • [0214] The above structure represents the following sequence of 20 bits:

[0215]

	1 010 0001001000110100

[0216] The first field, enabled, is a 1 bit field that has the value 1. The second field, type, is a 3 bit field that has the value typeRound which is a constant defined to be 2. The third field, length, is a 16 bit integer with the value 0x1234.

[0217] Fields in CDSN are never padded to fall on word, or even byte boundaries. That is, each field starts off on the next free bit after the previous field. All multi-bit values are stored most-significant-bit first.

Basic Compact Data Structure Types

[0218] A number of primitive data types are used in CDSN. The basic ones are:

[0219]

	Bit	a single bit
	UInt8, Int8	8 bit unsigned and signed integers
	UInt16, Int16	16 bit unsigned and signed integers
	UInt32, Int32	32 bit unsigned and signed integers

[0220] Other important types are the unsigned and signed variable length integer types: UIntV and IntV. These can be anywhere from 1 to 36 bits in length, depending on their value. The actual length can be determined by looking at the first 1 to 4 bits.

[0221] The types UIntV and IntV are defined as follows:

[0222]

UIntV:
0		The value 0
10	Bit[3]	The values 0 through 7 (0x07)
110	Bit[6]	The values 0 through 63 (0x3F)
1110	Bit[16]	The values 0 through 65535 (0xFFFF)
1111	Bit[32]	The values 0 through 4,294,967,295 (0xFFFFFFFF)
IntV:
0		The value 0
0	Bit[3]	The values −4 through 3
110	Bit[6]	The values −32 through 31
1110	Bit[16]	The values −32768 through 32767
1111	Bit[32]	The values −2,147,483,648 through 2,147,483,647

[0223] Using the UIntV, an integer of value 0 can be represented with just 1 bit, values 1 through 7 would require 5 bits, values 8 through 63 would require 9 bits, etc.

CML Structure

[0224] A CML data stream is by default a 5-bit character text stream. Until a special character (as discussed below) appears in the stream, each sequence of 5 bits is assumed to represent a single text character. The following table lists the possible 5-bit characters:

[0225] 5-bit Characters:

[0226]

Value	Special	Reset	Description
0	Yes	Yes	EndTag character. Used to terminate multi-para-
			meter tags and block elements
1	Yes	Yes	StartTag character, followed by 8 or 16 bit Tag
			ID.
2	Yes	No	Single character escape
3	No	No	Reserved
4	No	No	Line break
5	No	No	Space character
6-31	No	No	The lowercase letters: ‘a’ through ‘z’

[0227] As described later, there can be sections of CML where text is encoded using alternate text encoding modes such as 8 or 16 bits per character instead of 5 bits per character. Even in these sections with larger characters, the decimal character values 0 through 2 (labeled in above table as “special”) have special meaning. For example, if the endTag character (decimal 0) is encountered while an alternate text encoding mode is in effect, the text mode goes back to the default 5 bits per character.

[0228] Following is an example of how a simple section of text would be represented in CML. The text:

[0229]

	abc d
	ef
	is represented as:
	Bit[5]	char = 6	//‘a’
	Bit[5]	char = 7	//‘b’
	Bit[5]	char = 8	//‘c’
	Bit[5]	char = 5	//‘ ’
	Bit[5]	char = 9	//‘d’
	Bit[5]	char = 4	//line break
	Bit[5]	char = 10	//‘e’
	Bit[5]	char = 11	//‘f’

• • [0230] which, as a binary bit stream is:

[0231]

	00110 00111 01000 00101 01001 00100 01010 01011

[0232] When the text encoding mode is 5 bit characters, the single character escape (2), is followed by an 8 bit ASCII character. This single character escape then can be used to represent characters that are not present in the 5 bit alphabet. For example, the text:

• • [0233] a Cow
  • [0234] is represented in CML as the following sequence:

[0235]

	Bit[5]	char = 6	//‘a’
	Bit[5]	char = 5	//‘ ’
	Bit[5]	char = 2	//single character escape
	Bit[8]	char = 67	//‘C’
	Bit[5]	char = 20	//‘o’
	Bit[5]	char = 28	//‘w’

[0236] where the 67 is the 8 bit sequence 01000011 which represents the ASCII value for ‘C’ (67 decimal, 0x43 hexadecimal) and all other characters are 5 bits long.

[0237] Multiple sequences of non-lower case alpha or international characters can also be included in the stream by including the appropriate text encoding tag in the stream followed by the 8 or 16 bit (unicode) character text string. CML tags are described in the next section.

[0238] CML Tags

[0239] The tag start character (1) is included in a CML stream to indicate the presence of a CML tag. The tag start character is followed by an 8 or 16 bit Tag ID structure. The 8 or 16 bit Tag ID structure can be optionally followed by other variable length bit fields, depending on the specific tag. The 8-bit Tag ID structures have the first bit clear and can have the values 0 through 127 (0 through 0x7F hexadecimal). The 16-bit Tag ID structures have the first bit set and can have the values 32768 through 65535 (0x8000 through 0xFFFF hexadecimal).

[0240] Different tags have different functions. Some tags are followed by other variable length bit fields which specify parameters for that particular tag function. Other tags have no parameters at all. In any case, because the tag start character is a reset character, the text encoding mode is set back to 5-bit characters whenever a tag is encountered (unless the tag specifically changes the text encoding mode).

[0241] For example, the Tag textBold is used to turn on bold formatting. It has no parameters. The following text:

• • [0242] a cow
  • [0243] would be represented in CML as:

[0244]

	Bit[5]	char = 6	// ‘a’
	Bit[5]	char = 5	// ‘ ’
	Bit[5]	char = 1	// tag escape character
	Bit[8]	tagID = textBold	// constant value for textBold
	Bit[5]	char = 8	// ‘c’
	Bit[5]	char = 20	// ‘o’
	Bit[5]	char = 28	// ‘w’

[0245] An example of a tag which has parameters is the textSize tag. This tag is followed by a IntV specifying the actual text size to use. For example, the following text:

• • [0246] a dog
  • [0247] would be represented in CML as:

[0248]

Bit[5]	char = 6	// ‘a’
Bit[5]	char = 5	// ‘ ’
Bit[5]	char = 1	// tag escape character
Bit[8]	tagID = textSize	// constant value for textSize
UIntV	size = 4	// the value 4, as a UIntV is // 5 bits long:
		10100
Bit[5]	char = 9	// ‘d’
Bit[5]	char = 20	// ‘o’
Bit[5]	char = 12	// ‘g’

[0249] Since the size field in this case is 4, it takes 5 bits to represent as a UIntV.

[0250] Text Encoding Tags

[0251] Some CML tags are used to include strings of text that can not be encoded as 5-bit characters. Conceptually, text encoding tags are merely tags that have a variable number of parameters following them, where each “parameter” is another character in the text stream. The sequence of “parameters” ends as soon as a reset character is encountered (the endTag or startTag character).

[0252] For example, the textEncoding8 Bit tag indicates a string of 8 bit characters follows. The string of 8 bit characters is assumed to continue in the stream until a reset character is encountered. However, because the stream is now built up of 8 bit characters, all special characters (which includes the reset characters and single character escape) are also now 8 bits long. For example, the endTag character becomes the 8 bit sequence 0b00000000 and the startTag character becomes the 8 bit sequence 0b00000001.

[0253] In all cases of alternate text encodings, as soon as a reset character (0 or 1 decimal) is encountered in the stream, the text mode is switched back to 5 bit characters.

[0254] In the alternate text encoding schemes, the single character escape (3 decimal) can be used to include characters in the text which are normally special characters. For example, a 16-bit unicode character of decimal value 1 could be included in the stream by inserting the 16-bit single character escape (3 decimal) in front of it.

[0255] The following is an example of how the textEncoding8 Bit tag is used. The text: a BIG dog would be represented in CML as:

[0256]

	Bit[5] char = 6	// ‘a’
	Bit[5] char = 5	// ‘ ’
	Bit[5] char = 1	// tag escape character
	Bit[8] tagID =textEncoding8Bit
	Bit[8] char = ‘B’	// ‘B’
	Bit[8] char = ‘I’	// ‘I’
	Bit[8] char = ‘G’	// ‘G’
	Bit[8] char = 0	//endTag, switches text encoding
		//back to 5-bit mode
	Bit[5] char = 9	// ‘d’
	Bit[5] char = 20	// ‘o’
	Bit[5] char = 12	// ‘g’

[0257] An important thing to note is the interaction of alternate text encoding sections with the endTag character. Besides being used as a way to reset the text encoding mode, the endTag character is sometimes used in CML to separate two elements or to indicate the end of a block level element.

[0258] For example, when a list needs to be represented in CML, the list items are separated from each other by the endTag. In these instances, if a list item was represented using 8-bit encoded text, there would be 2 endTag characters in a row in the stream. The first endTag character, needed to end the 8-bit encoded text, would be 8 bits long. Then, to indicate the actual start of another list item, a 5-bit endTag character would be placed in the stream.

[0259] The Tag Data Type

[0260] Because the sequence of the tag escape character followed by Tag ID structure is used so often in the documentation, it is given it's own data type. It is defined as:

[0261]

	Tag	tagID:
	Char	startTag = 1
	Bit	longTag
	if	(longTag == 0)
	Bit[7]	tagID
	else
	Bit[15]	tagID

[0262] That is, it's a startTag character (decimal 1) followed by a single bit specifying the length of the tagID, followed by either a 7 or 15 bit tagID. The tag escape character is normally 5 bits long, except when an alternate text encoding mode is in effect, in which case it's length depends on the particular text encoding mode.

[0263] For example, the CML sequence:

[0264]

	Tag	tag = smallTag	// smallTag = 5

• • [0265] would look like this as a binary bit stream:

[0266]

	00001 0 0000101

[0267] Whereas the CML sequence:

[0268]

	Tag	tag = bigTag	// bigTag = 512

• • [0269] would look like this as a binary bit stream:

[0270]

	00001 1 000001000000000

[0271] The following CML sequence shows a tag after a section of 8 bit encoded text:

[0272]

	Tag	tag = textEncoding8Bit	// textEncoding8Bit = 6
	Bit[8]	char = ‘A’	// 0×41
	Tag	tag = smalTag	// smallTag = 5
	Bit[5]	char = 6	// ‘a’

• • [0273] it would look like this as a binary bit stream:

[0274]

00001	0	0000110	01000001	000000010	0000101	00110
tag Esc	textEncoding	8Bit	‘A’	tagEsc	smallTag	‘a’

[0275] CML Text & TextZ Types

[0276] Another common data type used in CML is the Text data type. This type is used to conveniently represent a string of characters. This type is a very powerful data type because it hides the complexity of escaping special characters and the actual number of bits required to represent each character.

• • [0277] For example, the CML sequence used above:

[0278]

	Bit[5]	char = 6	// ‘a’
	Bit[5]	char = 5	// ‘ ’
	Bit[5]	char = 1	// tag escape character
	Bit[8]	tagID =textEncoding8Bit
	Bit[8]	char = ‘B’	// ‘B’
	Bit[8]	char = ‘I’	// ‘I’
	Bit[8]	char = ‘G’	// ‘G’
	Bit[8]	char = 0	// endTag character
			// switches back to 5-bit mode
	Bit[5]	char = 9	// ‘d’
	Bit[5]	char = 20	// ‘o’
	Bit[5]	char = 12	// ‘g’

• • [0279] is represented using the Text data type as:

[0280]

	Text	string = “a BIG dog”

[0281] The Text data type hides the complexities of escaping non-lower case alpha characters as well as the endTag character used to switch the mode back from 8-bit to 5-bit ASCII.

[0282] The combination of the Tag and Text types makes representing combinations of formatting and text sequences much easier. For example, the sequence used above that showed how bold text would be represented was:

[0283]

	Bit[5]	char = 6	// ‘a’
	Bit[5]	char = 5	// ‘ ’
	Bit[5]	char = 1	// tag escape character
	Bit[8]	tagID = textBold	// constant value for
			textBold
	Bit[5]	char = 8	// ‘c’
	Bit[5]	char = 20	// ‘o’
	Bit[5]	char = 28	// ‘w’

• • [0284] Using the Tag and Text types, this sequence can be represented as:

[0285]

	Text	string = “a”
	Tag	tag = textBold
	Text	string = “cow”

[0286] TextZ Type

[0287] Another convenient type in CML is the TextZ type. This is basically a Text type with a terminating endTag character. This type is most often used in tag parameter lists. It can be defined simply as:

[0288] TextZ Text:

[0289]

	Text	text
	Char	end = endTag

[0290] As an example, the format of the meta tag is defined as:

[0291]

	Tag	tag = tagMeta
	TextZ	name
	TextZ	value

[0292] Where name and value are parameters of the meta tag and are delimited from each other and any text that might follow the tag by the endTag character at the end of each one. If a variable is defined as a TextZ type, the variable generally has an endTag character at the end of it, though the end could be implied by the presence of a following tag.

[0293] Tag Definitions

[0294] This section lists the various CML tags available. Each tag is described in detail along with its parameters, if any. This section refers to tags by name, but in the actual implementation a pre-defined constant is associated with each tag.

[0295]

Background Attributes
TagBGColor
Description:
Used to set the background color.
Parameters:
Byte  red
Byte  green
Byte  blue
Examples:
Tag  tag = tagBGColor
Byte  red = 0×FF
Byte  green = 0×80
Byte  blue = 0×80
TagBGImage
Description:
Used to set the background image. This image will be tiled to fill the
entire window.
Parameters:
Image img  // [still need to define image format]
Examples:
Tag  tag = tagBGImage
Image img = ...  // [still need to define image format]
Text Attributes
TagTextColor
Description:
Used to set the text color.
Parameters:
Byte  red
Byte  green
Byte  blue
Examples:
Tag  tag = tagTextColor
Byte  red = 0×FF
Byte  green = 0×80
Byte  blue = 0×80
Text  “This text is reddish”
TagLinkColor
Description:
Used to set the color used to display visited or unvisited links
Parameters:
Bit  visited
Byte  red
Byte  green
Byte  blue
Examples:
Tag  tag = tagLinkColor
Bit  visited = 1  // set color for visited
// links
Byte  red = 0×FF
Byte  green = 0×80
Byte  blue = 0×80
tagTextColor
Description:
Used to set the text color.
Parameters:
Byte  red
Byte  green
Byte  blue
Examples:
Tag  tag = tagTextColor
Byte  red = 0×FF
Byte  green = 0×80
Byte  blue = 0×80
Text  “This text is reddish”
tagTextSize
Description:
Used to set the text size.
Parameters:
Bit relative  // relative or absolute size
UIntV  // line height of text in pixels.
size
Examples:
Tag  tag = tagTextSize
Bit  relative = 0
UIntV size = 9
tagTextBold
Description:
Used to mark bold text style.
Parameters:
None
Examples:
// Start bold text
Tag  tag = tagTextBold
Text  “This is bold text”
// End bold text
Char  end = endTag
tagTextItalic
Description:
Used mark italic text style.
Parameters:
None
Examples:
// Start italic text
Tag  tag = tagTextItalic
Text  “This is italic text”
// End italic text
Char  end = endTag
tagTextUnderline
Description:
Used to mark underlined text style.
Parameters:
None
Examples:
// Start underlined text
Tag  tag = tagTextUnderline
Text  “This is underlined text”
// End underlined text
Char  end = endTag
tagTextFormat
Description:
Used to mark the font style and phrase elements.
Parameters:
Bit[4] format  // one of monoSpaced, strike,
// bigger, smaller, sub, sup,
// definition, code, sample,
// keyboard, variable, cite
Examples:
Tag  tag = tagTextFormat
Bit[4]  format = code
Text  “itemP = itemP->nextItemP;”
tag8BitEncoding
Description:
Used to mark the beginning of 8-bit encoded text.
Parameters:
None
Examples:
Tag  tag = tag8BitEncoding
Text  “THIS IS 8-BIT ENCODED TEXT”
// End 8-bit encoded text
Char  end = endTag
tagH1 . . . tagH6
Description:
Used to mark document headings.
Parameters:
Bit[3] align  // one of alignLeft, alignCenter,
// alignRight
Examples:
Tag  tag = tagH1
Bit[3]  align = alignCenter
Text  “This is a Heading”
Char endTag  // end heading tag
tagMeta
Description:
Used to mark name/ value pairs describing document properties.
Parameters:
TextZ  name
TextZ  content
Examples:
Tag  tag = tagMeta
TextZ  “History”
TextZ  “Quote Results”
tagDatePicker
Description:
Used to specify a date value. It takes either a valid date, or if 0 is
specified, the current date is assumed. The date is specified as the number
of seconds since midnight, Jan. 1, 1904 GMT. The dateLo field contains
low 32 bits of this value and the dateHi field contains the upper 32 bits
of this value (usually 0).
Parameters:
UIntV  dateHi
UIntV  dateLo
Examples:
Tag  tag = tagDatePicker
UIntV  dateHi = 0
UIntV  dateLo = 0×A1234000
tagTimePicker
Description:
Used to specify a time value. It takes either a valid time, or if 0 is
specified, the current time is assumed. The time is specified as the number
of seconds since midnight.
Parameters:
UIntV  seconds
Examples:
Tag  tag = tagTimePicker
UIntV seconds = 3600	//1:00 am.
Paragraph Attributes
tagParagraphAlign
Description:
Used to set paragraph alignment to either left, center, or right.
Parameters:
Bit[3] align // one of alignCenter, alignLeft, or
// alignRight.
Examples:
// Turn on center alignment
Tag  tag = tagParagraphAlign
Bit[3]align =alignCenter
Text   “\nThis paragraph is centered.”
// Turn off left alignment
Tag  tag = tagParagraphAlign
Bit[3]  align =alignLeft
Text   “\nThis paragraph is left aligned.“
tagMarginIndent
Description:
Used to set the indent amount of the margins. The indent parameter
specifies the number of pixels to indent on both the left and right margins
of the window. The indenting takes effect on the next line of text, whether
due to word wrap or line break.
Parameters:
UIntV indent // number of pixels to indent
Examples:
//Indent the next paragraph by 10 pixels
Tag   tag = tagMarginIndent
UIntV indent = 10
Text  “\nThis text is indented.”
// Restore indent
Tag tag = tagMarginIndent
UIntV indent = 0
tagBlockQuote
Description:
Used to mark the beginning of block quotations.
Parameters:
None
Examples:
Tag  tag = tagBlockQuote
Text “The whole problem with the world is that fools and
fanatics are always so certain of themselves, but
wiser people so full of doubts.“
Text   “- Bertrand Russell”
Lists
tagListOrdered
Description:
Used to mark the beginning of an ordered (numbered) list of items. Each
item in the list is ended either by a endTag character or a
tagListItemCustom tag with parameters. The end of the list is indicated by
the endTag character.
Parameters:
Bit[3] type   // one of listT1, listTa, listTA,
// listTi, or listTI
UIntV start   // starting sequence number minus 1
Bit  compact  // compact spacing
between items
Examples:
// The list header
Tag  tag = tagListOrdered
Bit[3]  type = listT1
UIntV   start = 0
Bit   compact = 0
// The list items.
Text   “First item”
Char   item Separator = endTag
Text   “Second item”
// ———  // itemSeparator not used here
Tag   tag = tagListItemCustom
Bit[3]  type listTa
UIntV   value = 4
Text   “Third item”
Char   end = endTag // end of 3rd item
// The end of the list
Char   end = endTag // end of list
tagListUnordered
Description:
Used to mark the beginning of an unordered list of items. Each item in the
list is ended either by a endTag character or a tagListItemCustom tag with
parameters. The end of the list is indicated by the endTag character.
Parameters:
Bit[3]  type // one of listTDisk, listTSquare, or
// listTCircle
Bit compact   // compact spacing between items
Examples:
// The list header
Tag  tag = tagListUnordered
Bit[3]  type =listTDisk
Bit  compact =0
// The list items.
Text   “First item”
Char  itemSeparator = endTag
Text “Second item”
//———  // itemSeparator not used here
Tag   tag = tagListItemCustom
Bit[3]  type listTSquare
UIntV   value 0
Text   “Third item”
Char   itemSeparator = endTag // end of 3rd item
// The end of the list
Char   endList = endTag
tagListItemCustom
Description:
Used to mark the beginning of a custom list item in either an ordered or
unordered list. Most items in lists are separated by endTag characters, but
if the bullet style, numbering style, or sequence number of an item is not
the default, the tagListItemCustom tag is used instead.
Parameters:
Bit[3]  type // The bullet or number style
UIntV value   // ignored for unordered lists.
Examples:
Tag   tag = tagListItemCustom
Bit[3]  type = listTSquare
UIntV   value = 0
Text   “Third item”
Char   item Separator endTag
tagListItemDefinition
Description:
Used to mark the beginning of a definition item in a definition list.
Parameters:
None
Examples:
Tag  tag = tagListItemDefinition
Text  “This is the definition of the first item”
Forms
tagForm
Description:
Used to mark the start of a form. A form encloses one or more input items
and ends with an endTag character.
There are essentially 2 classes of forms for the wireless communications
device 100 as described in the Forms Processing section below: standalone
forms (like in standard HTML) and server dependent forms. Server
dependent forms can be much smaller than standard forms and are
typically the only type of form received over a wireless link. Standard
forms on the other hand are designed to be pre-loaded onto the wireless
communications device 100 through other means (HotSync, built into
ROM, etc.).
A standalone form is indicated by a 1 in the standalone attribute of the
form tag. A 1 in this bit indicates that the form also has post and action
attributes and that each of it's input fields have the necessary attributes
(name and value) for submitting the form without making the proxy
reference the original HTML form off the internet first. The encoding
normal form submissions section below describes how to submit a
standalone form to the proxy server 180.
A server dependent form is indicated by a 0 in the standalone attribute. A
0 in this bit indicates that the form does not have post or action attributes
and that it's input fields do not have associated name or value attributes.
When this type of form is sent to the proxy server 180, the proxy server
180 first references the original HTML form off the internet before it can
actually submit the request to the CGI script. The Encoding Server
Dependent Form Submissions section below describes how to send a
server dependent form submission to the proxy server 180.
The form Index is assigned by the proxy and starts at 0 for the first form in
a document.
The post attribute is 0 if the form should be submitted to the CGJ script
using the HTTP GET method or 1 if the form should be submitted using
the HTTP POST method. Currently, only the GET method is supported.
The action attribute contains the URL of the CGI script on the server that
handles the form submission.
The secure bit is only present for server-dependent forms The secure bit is
set if the action URL for the form is for a secure site (i.e. uses the HTTPS
scheme). The secure bit is used by the wireless client 405 to determine if
the wireless client 405 should send the form submission to the proxy
server 180 encrypted or not. For standalone forms, the wireless client 405
checks the scheme that is in the action URL parameter to see if the
submission should be encrypted or not.
Parameters:
UIntV formindex  // assigned by proxy server
Bit  standalone
if (standalone)
Bit  post  //if 1, use POST instead of GET
TextZaction  // URL of the CGI-script
else
Bit  secure  //true if URL is HTTPS scheme
Examples:
Tag   tag = tagForm
UIntV   formIndex = 0
Bit  standalone = 1
Bit  post =
TextZ action = “http://www.server.com/cgi-bin/submit”
// The form input items
Text  “Age 0-12:”
Tag tag =   tagInputRadio
Bit checked = 0
UIntV  group = 0
Bit  hasName 1
Bit  has Value 1
TextZ  name “age”
TextZ  value = “0-12”
Text   “Age 13-17:”
Tag tag =  tagInputRadio
Bit checked = 1
UIntV   group = 0
Bit  hasName = 1
Bit  hasValue = 1
TextZ  name = “age”
TextZ value = “13-17”
Tag tag=   tagInputSubmit
Bit  hasName = 0
Bit  has Value = 1
TextZ  value = “OK”
Char  endForm endTag
TagInputRadio
Description:
Used to represent radio buttons in a form. The checked parameter indicates
the initial state of the control. The group parameter is assigned by the
proxy server 180 and allows the wireless client 405 to perform mutual
exclusion selecting.
The hasName and hasValue are normally only set in standalone forms and
indicate the presence of following text fields that contain the control's
name and value.
Parameters:
Bit checked
UIntV  group
Bit  hasName
Bit  hasValue
if (hasName)
TextZ name
if (hasValue)
TextZ value
Examples:
Tag  tag = tagInputRadio
Bit  checked = 0
UIntV  group = 0
Bit  hasName = 1
Bit  hasValue 1
TextZ  name = “age”
TextZ  value = “13-17”
Text   “Age 13-17:”
TagInputCheckbox
Description:
Used to represent checkboxes in a form. The checked parameter indicates
the initial state of the control.
The hasName and has Value parameters are normally only set in stand-
alone forms and indicate the presence of following text fields that con-
tain the control name and value.
Parameters:
Bit checked
Bit  hasName
Bit  hasValue
if (hasName)
TextZ name
if (hasValue)
TextZ value
Examples:
Tag  tag = tagForm
Tag  tag = tagInputCheckbox
Bit  checked = 0
Bit  hasName = 0
Bit  hasValue = 0
tagInputTextLine
Description:
Used to represent single line input text fields within a form. A maxLength
parameter of 0 means no limit on the number of characters entered.
The hasName parameter is normally only set in standalone forms. The
has Value parameter may be set in either type of form and indicates the
initial default text for the input item.
Parameters:
UIntV size  // visible width of field in
// characters
UIntV maxLength  // maximum number of allowed
// characters
Bit  hasName
Bit  hasValue
if (hasName)
TextZ name
if (hasValue)
TextZ value
Examples:
Tag tag =  tagForm
Text   “Enter Name:”
Tag tag =  tagInputTextLine
UIntV  size = 20
UIntV  maxLength = 0
Bit  hasName = 0
Bit  hasValue = 1
TextZ  value = “your name here...”
TagInputTextArea
Description:
Used to represent a multi-line input text field within a form. The text
element immediately following this tag is the initial text for the input field.
The end of the initial text is indicated by an endTag character.
The hasName parameter is normally only set in standalone forms. The
hasValue parameter may be set in either type of form and indicates the
initial default text for the input item.
Parameters:
UIntV rows  // number of rows
UIntV cols  // number of columns
Bit  hasName
Bit  hasValue
if (hasName)
TextZ name
if (hasValue)
TextZ value
Examples:
Text  “Enter Address:”
Tag  tag = tagInputTextArea
UIntV  rows = 2
UIntV  cols = 20
Bit  hasName = 1
Bit  hasValue = 1
TextZ  name =“address”
TextZ  value = “your address here ...”
tagInputPassword
Description:
Used to represent single line password input fields within a form. A
maxLength parameter of 0 means no limit on the number of characters
entered.
The hasName and hasValue parameters are normally only set in standalone
forms and indicate the presence of following text fields that contain the
field's name and value.
Parameters:
UIntV size // visible width of field in
// characters
UIntV maxLength // maximum number of allowed
// characters
Bit  hasName
Bit  hasValue
if (hasName)
TextZ name
if (hasValue)
TextZ value
Examples:
Text  “Enter Password:”
Tag tag = tagInputPassword
UIntV size = 20
UIntV maxLength = 0
Bit  hasName = 0
Bit  hasValue = 0
TagInputSubmit
Description:
Used to represent submit buttons in a form. The label parameter is the
button's label. An endTag character marks the end of the label.
The hasName parameter is normally only set in standalone forms. The
has Value parameter may be set in either type of form and indicates the
text that should appear inside the button. If the has Value parameter is
omitted, the default text of “submit” will be placed in the button.
Parameters:
Bit	hasName
Bit	hasValue
if (hasName)
TextZ name
if (hasValue)
TextZ value
Examples:
Tag	tag = tagInputSubmit
Bit	hasName = 0
Bit	hasValue = 1
TextZ	value = “OK”
tagInputSubmitImage
Description:
Used to represent graphical submit buttons in a form.
Parameters:
Bit[3] align	// one of alignTop, alignMiddle,
	// alignBottom, alignLeft,
	// alignRight'
Bit	hasName
if (hasName)
TextZ name
Image image	// [format TBD . . . ]
Examples:
Tag	tag = tagInputSubmitImage
Bit[3]	align = alignBottom
Bit	hasName = 1
TextZ	name = “map”
	Image [TBD ...]
tagInputReset
Description:
Used to represent reset buttons in a form.
The hasValue parameter may be set to indicate the text that should appear
inside the button. If the hasValue parameter is omitted, the default text of
“reset” will be placed in the button.
Parameters:
Bit	hasValue
if (has Value)
TextZ value;
Examples:
Tag	tag = tagInputReset
Bit	hasValue = 1
TextZ	value = “Reset”
Char	endTag
Text	“Some random text”
TagInputSelect
Description:
Used to represent select menus in a form. The multiple parameter should
be set if multiple items are allowed to be selected at once. If multiple is
set, then the size parameter indicates how many visible choices appear at
once in the menu.
The hasName parameters is normally only set in standalone forms.
This element is followed by 1 or more Text elements representing the
menu options that are separated by endTag characters or
tagSelectItemCustom tags. The tagSelectItemCustom tag only needs to be
used for pre-selected items. An additional endTag character follows the
last item and indicates the end of the select menu.
Parameters:
Bit    multiple    // set if multiple choices allowed
UIntV size  // number of visible items at once
Bit hasName
if (hasName)
TextZ name
Examples:
Tag  tag = tagInputSelect
Bit multiple = false
UIntV  size = 0
Bit  hasName = 1
TextZ  name = “choice”
// The select items.
Text  “First choice”
Char  itemSeparator = endTag
Text  “Second choice”
Char  itemS eparator = endTag
Text  “Third choice”
Char  itemSeparator = endTag
Char  endSelect = endTag
tagSelectItemCustom
Description:
Used to mark the beginning of a custom select item. Most items in select
lists are separated by endTag characters, but if an item is marked as pre-
selected, the tagSelectltemCustom tag is used instead.
The hasValue parameter is normally only set in standalone forms. It can be
used to indicate the text that should be included as the value of this item
during the form submission. If this parameter is omitted, then the text that
follows the tagSelectltemCustom tag is used instead.
Parameters:
Bit selected  // non-zero of pre-selected
Bit hasValue
if (has Value)
TextZ value
Examples:
Tag  tag = tagSelectItemCustom
Bit  selected = 1
Bit  hasValue = 1
TextZ  value = “3”
Text “Third item”
Char itemSeparator = endTag
Tables
TagTable
Description:
Used to mark the start of a table. If the width parameter is 0, the width of
the table will be calculated from the contents. The border parameter can be
0 to suppress the border. If cellspacing is non-zero, then borders will be
draw around every cell. The celtPadding sets the padding in pixels
between the border around each cell and the cell's contents - default is 0.
Each row in the table starts out with a tagTableRow tag that has optional
parameters for the horizontal and vertical alignment of the cells in that
row.
The cells within a table row are separated by endTag's, or
tagTableColumn tags. The tagTableColumn tags mark header cells, or
permit attributes to be set for the next cell. The first cell in each row can
have a tagTableColunm tag preceding it if necessary in order to change its
attributes.
Parameters:
Bit[3] hAlign // one of alignLeft, alignCenter,
// alignRight
UIntV width //table width in pixels
UIntV border // border width in pixels
UIntV cellSpacing // cell spacing in pixels
UIntV cellPadding // cell padding in pixels
Examples:
Bit[3] hAlign = alignCenter
UIntV width = 0
UIntVborder = 0
UIntV cellSpacing = 0
UIntV cellPadding = 0
Tag  tag = tagTableRow
Bit  hasAlign = 0
Text  “row1, col1”
Char  endTag
Text “row1, col2”
Char endTag
Tag tag = tagTableRow
Bit hasAlign = 0
Text “row2, col1”
Char endTag
Text “row2, col2”
Char endTag
Char endTag  // end of table
TagCaption
Description:
Used to mark the caption to be placed above the top or below the bottom
of a table.
Parameters:
Bit  captionAtTop  // if 0, caption at bottom
Text  caption  // table caption
Char  endCaption = endTag // end of caption
Examples:
Tag  tag = tagCaption
Bit  captionAtTop = 1
Text  “Table Title”
Char  endTag // end of caption
TagTableRow
Description:
Used to separate rows of a table. Has 2 optional parameters to set the
vertical and horizontal alignment of cells within the row.
Each row in the table starts out with a tagTableRow tag that has optional
parameters for the horizontal and vertical alignment of the cells in that
row.
Parameters:
Bit hasAlign
if (hasAlign == 1)
Bit[3] hAlign  // one of alignLeft, alignCenter,
// alignRight
Bit[3] vAlign // one of alignTop, alignMiddle,
// alignBottom
Examples:
Tag tag = tagTableRow
Bit hasAlign = 0
Text “row 1, col1”
Char endTag
Tag tag = tagTableRow
Bit hasAlign = 1
Bit[3] hAlign = alignRight
Bit[3] vAlign = alignTop
Text “row2, col1”
Char endTag
tagTableColumn
Description:
Used to mark a header or data cell in a table.
All cells within a table row are separated by either endTag's or
tagTableColumn tags. The tagTableColumn tags denote whether the next
cell is a header cell or a data cell. In addition, the tagTableColumn tags
permit attributes to be set for the next cell. The first cell in each row can
have a tagTableColurnn tag preceding it if necessary in order to change its
attributes.
The rowSpan and colSpan parameters are 0-based, which means that a
value of 0 in these fields means 1 row and 1 column respectively. The
width and height parameters can be 0 to make them automatically
determined by the cell contents.
Parameters:
Bit  headerCell  // 1 for header cell,
// 0 for data cell
Bit hasAttribute
if (hasAttribute ==1)
Bit  noWrap  // suppress word wrap
UIntV  rowSpan  // number of rows spanned by
// cell minus 1
UIntV  colSpan  // number of columns spanned
// by cell minus 1
Bit[3] hAlign  // horizontal alignment
Bit[3] vAlign  // vertical alignment
UIntV width  // width of cell in pixels
UIntV height  //height of cell in pixels.
Examples:
Tag  tag = tagTableColumn
Bit  headerCell = 0
Bit  hasAttribute = 1
Bit  noWrap = 0
UIntV rowSpan = 0
UIntV colSpan = 0
Bit[3] hAlign = alignRight
Bit[3] vAlign = alignTop
UIntV  width = 0
UIntV  height = 0
Text  “row2, col2”
Char  endTag
Hyperlinks
TagHyperlink
Description:
Used to represent hyperlinks. All text enclosed between the
tagAnchor tag and the terminating endTag are part of the
hyperlink.
Unlike the <a> tag in HTML which can be used to define
hyperlinks or local anchors (i.e. fragment identifiers), the
tagHyperlink tag is only used to define hyperlinks. The
tagAnchor tag, defined below, is used exclusively to define
local anchors.
The hasTitle bit can be set if a title is included. Normally,
documents sent wirelessly will not include a title in order to
conserve space.
If this hyperlink is to another location within the same
document (i.e. a link to a tagAnchor), then internal will be
set to 1 and the anchorlndex parameter indicates the index
of a local tagAnchor to jump to. The first tagAnchor in the
document is index 0, the next one is index 1, etc. The
recordindex parameter indicates which web resource to go
to, 0 means the current web resource. A non-zero value
represents the database record ID of the new web resource
and is only used for wireless communications device 100
PQP databases that have multiple web resources stored in
them - each in it's own record.
Otherwise, if this hyperlink is to another document, then
internal will be 0 and hasURef will be set if the URI of the
document is included. Normally documents obtained
wirelessly will not include href URLs and hyperlinks are
followed by sending an indirect hyperlink URL request to
the proxy server 180. Documents designed to be installed
onto the wireless communications device 100 through
HotSync or other wireline means however will generally
include an bref URL and these kinds of hyperlinks can be
jumped to by sending a normal URL request to the proxy
server 180.
Parameters:
Bit hasTitle
if (hasTitle)
TextZ  title
Bit internal
if  (internal)
UIntV recordindex
UIntV  anchorindex
else
Bit  hasHRef
if  (has HRef)
TextZ  bref
Examples:
Here is an example of an external explicit link which would
typically be used by a document designed to be loaded onto
a Handheld computer through HotSync or some
non-wireless means:
Tag  tag = tagHyperlink
Bit  hasTitle = 1
TextZ  title = “3Com home page”
Bit  internal = 0
Bit  hasHRef = 1
TextZ  href = http://www.3com.com/
Text  “Click on this text”
Char  endTag // terminates tagAnchor
Here is an example of an external indexed link that would typically be
used by a document that was obtained wirelessly. Notice that it does not
include a URL or a title in order to conserve space.
Tag  tag = tagHyperlink
Bit  hasTitle = 0
Bit  internal = 0
Bit  hasHRef 0
Text  “Click on this text”
Char endTag  // terminates tagAnchor
Here is an example of an internal link that is used to jump to another
location within the same document. It indicates to jump to anchor #4,
which is the 5th tagAnchor tag in the current document (the first tagAnchor
is given index #0).
Tag  tag = tagHyperlink
Bit  hasTitle = 0
Bit  internal = 1
UIntV recordlndex = 1  // stay in this current resource
UIntV anchorlndex = 4  // go to the 5th tagAnchor tag
Text “Click on this text”
Char endTag  // terminates tagAnchor
TagAnchor
Description:
Used to represent local document anchors, or fragment
identifiers within a document.
Unlike the <a> tag in HTML which can be used to define
hyperlinks or local anchors (i.e. fragment indentifiers), the
tagAnchor tag is only used to define local anchors. The
tagHyperlink tag, defined above, is used exclusively to
define hyperlinks.
Normally, tagAnchors don't need an associated name since
the tagHyperlink tag jumps to tagAnchors by index. The
first tagAnchor in a document is index #0, the second is
index #1, etc. However, documents designed to be installed
onto the Handheld computer through HotSync or wireline
means might include the anchor names so that other
documents could include hyperlinks that jump to that
location using a fragment identifier URL (something like
http://www.mine.com/#anchorName).
Parameters:
Bit  hasName
if (hasName)
TextZ name
Examples:
Tag  tag = tagAnchor
Bit  hasName = 0
Graphic Elements
TagImage
Description:
Used to represent inline images. Any of the UIntV
parameters to the taglimage tag can be set to nil to generate
default behavior.
Parameters:
Text	alternateText	// alternate text
Char	endTag	// marks end of alternate text
Bit[3]	align	// one of alignTop, alignMiddle,
		// alignBottom, alignLeft,
		alignRight
UIntV	height	// suggested height
UIntV	width	// suggested width
UIntV	border	// suggested border width
UIntV	hspace	// suggested horizontal gutter
UIntV	vspace	// suggested vertical gutter
Bit	ismap	// true if hyperlink
Image	imageData	// image data [TBD ...]
Examples:
Text “This is some text”
Tag tag = taglmage
Text	“This is an image of a PalmPilot”
Char	endTag
Bit[3]	align = alignBottom
UIntV	height = 0
UIntV	width = 0
UIntV	border = 0
UIntV	hspace = 0
UIntV	vspace = 0
Bit ismap = 1
Image	image = [TBD ...]
TagHorizontalRule
Description:
Used to place a horizontal rule graphic in the page. If the
custom parameter is 0, then no other parameters follow and
the rule is placed with a default width, height, and color.
Parameters:
Bit custom
if (custom == 1)
Bit[3] align // one of alignLeft, alignCenter, or
// alignRight
Bit noShade  // render in solid color
UIntV   size   // height in pixels
UIntV   width   // width in pixels
Examples:
// A default rule
Tag   tag = tagHorizontalRule
Bit  custom = 0
Text “Some random text”
// A custom rule
Tag  tag = tagHorizontalRule
Bit  custom = 1
Bit[3]   align = alignCenter
Bit  noShade = 0
UIntV  size = 3
UIntV  width = 50

[0296] Some embodiments of the invention include a method of converting an HTML message into a second message. The method comprises translating the HTML message into a compact markup language (CML). The HTML message comprises HTML constructs. CML representation of HTML constructs comprises a stream of data with embedded tags. The embedded tags comprise binary data corresponding to the HTML constructs. In some embodiments, the stream of data comprises text and image data. The text data comprises multibit character representation for selected characters, eight bit representations for a first set of unselected characters, and sixteen bit representations for a second set of unselected characters. The second message typically contains information requested by the wireless client 405. The second message is often referred to herein as the response message, but could be any message that requires formatting of an HTML message in CML prior to communication to a requesting host.

[0297] HTML Element Functionality

[0298] The following sections outline features of HTML version 3.2 and their level of functionality on the wireless client 405. When using the browser 104 engine, the data sent to the wireless client 405 from the proxy server 180 is in CML that is generated dynamically from the original HTML document. When the standard browser engine is used however, the wireless client 405 gets the HTML source directly from the web server.

[0299]

The Head Elements
HEAD
	Element	End Tag	Level
	HEAD	yes	N/A
Description:
The head start and end tags enclose the document head and are
optional.
Examples:
<HEAD>
CML Representation:
Not needed. Every CML document starts with a title string
terminated by an endTag character, which is the implied “head”
portion.
TITLE
	Element	End Tag	Level
	TITLE	yes	N/A
Description:
The title of the document. Usually displayed in the window's title
bar.
Examples:
<TITLE>A study of population dynamics</TITLE>
CML Representation:
No tag needed. Every CML document is defined to start with a title
string terminated by an endTag character.
STYLE
	Element	End Tag	Level
	STYLE	yes	N/A
Description:
A place holder for future versions of HTML which may support
style sheets.
Examples:
<STYLE>some random text</STYLE>
CML Representation:
The tagStyle tag and associated endTag character.
SCRIPT
	Element	End Tag	Level
	SCRIPT	yes	N/A
Description:
A place holder for future versions of HTML which may support
client-side scripts.
Examples:
<SCRIPT>some random text</SCRIPT>
CML Representation:
The tagScript tag and associated endTag character.
ISINDEX
	Element	End Tag	Level
	ISINDEX	no	N/A
ISINDEX Attributes:
	Attribute	Type
	Prompt	Text	The prompt string
Description:
The ISINDEX element is a simple way to implement a single line
text input field. The same behavior can be accomplished through
use of a single field FORM element in the body.
Examples:
<ISINDEX PROMPT=“Search Phrase”>
CML Representation:
ISINDEX elements are translated into CML representations for a
form in the body portion - there is no dedicated CML tag for
ISINDEX.
BASE
	Element	End Tag	Level
	BASE	No	N/A
BASE Attributes:
	Attribute	Type	Description
	Href	url	the base URL
Description:
The BASE element gives the base URL for dereferencing relative
URLs.
Examples:
<BASE HREF=“http://www.acme.com”>
CML Representation:
CML documents do not contain hotlink URLs so no equivalent to
this field is necessary. The wireless client 405 simply tells the
proxy server 180 when the user clicks on a hotlink by passing the
hotlink's index to the proxy server 180. The proxy server 180 then
looks up the appropriate URL using the original document.
META
	Element	End Tag	Level
	META	no	N/A
META Attributes:
Attribute	Type	Description
Http-equiv	Text	HTTP response header name
name	Text	Property name
Content	Text	Property value
Description:
The META element can be used to include name/value pairs
describing properties of a document such as author, expiration date,
etc. The NAME attribute specifies the property name while the
CONTENT attribute specifies the property value.
Examples:
<META NAME=“Author” CONTENT=“Dave Raggett”>
CML Representation:
META elements are represented by tagMeta CML tags.
LINK
	Element	End Tag	Level
	LINK	No	N/A
Attribute	Type	Description
href	url	A URL specifying the linked resource
rel	text	forward link typyes
rev	text	reverse link typyes
title	text	advisory title string
Description:
The LINK element provides a media independent method for
defining relationships with other documents and resources. Very
few browsers take advantage of it.
Examples:
<LINK REL=Contents HREF=toc.html>
<LINK REL=Previous HREF=doc32.html>
<LINK REL=Next HREF=doc33.html>
CML Representation:
None.
The Body
BODY
	Element	End Tag	Level
	BODY	Yes	N/A
Body Attributes:
Attribute	Type	Description
Bgcolor	color	The background color for the document.
Text	color	The text color.
Link	color	The color to use for unvisited hypertext links.
Vlink	color	The color to use for visited hypertext links
Background	url	The URL for an image to tile the background with
Description:
The body start and end tags enclose the document body and may be
omitted.
Examples:
<BODY BGCOLOR=white TEXT=black LINK=red
VLINK=“#C0FFC0”>
CML Representation:
The body section starts immediately after the endTag-character
terminated title in a CML document and does not have an
associated tag. The TEXT, BGCOLOR, LINK, VLINK, and
BACKGROUND attributes are represented by the standalone CML
tags tagTextColor, tagBGColor, tagLinkColor, tagLinkColor, and
tagBGImage respectively.
Headings
H1, H2, H3, H4, H5, H6
	Element	End Tag	Level
	H1	yes	Block
	H2	yes	Block
	H3	yes	Block
	H4	yes	Block
	H5	yes	Block
	H6	yes	Block
H1, H2, H3, H4, H5, H6 Attributes:
Attribute	Type	Description
Align	enum	Can be any one of LEFT, CENTER, or RIGHT
Description:
The H1 through H6 tags are used for document headings. Start and
end tags are required. H1 elements are more important than H2
elements, and so on.
Examples:
<H1 ALIGN=CENTER>This is the Heading Text</H1>
CML Representation:
Heading elements are represented by the corresponding
tagH1 . . . tagH6 CML tags.
Paragraph Breaks and Formatting
BR
	Element	End Tag	Level
	BR	No	Text
BR Attributes:
Attribute	Type	Description
clear	enum	Used to move down past floating images on either
		margin.
Description:
The BR element forces a line break. The CLEAR attribute can be
used to move down past floating images on either margin.
Examples:
<BR CLEAR=ALL>
CML Representation:
BR elements are represented in CML as 1 or more imbedded line-
break characters in the text.
P
	Element	End Tag	Level
	P	Optional	Block
P Attributes:
Attribute	Type	Description
Align	enum	Can be an one of LEFT, CENTER, or RIGHT
Description:
The P tag signifies a paragraph break and is typically rendered as a
line break followed by a blank line (i.e. another line break). The
end tag is optional because it can be inferred by the parser.
Examples:
<P>This is the first paragraph.
<P>This is the second paragraph.
CML Representation:
The P tag will be replaced with 1 or more imbedded linebreak
characters in the text. If the align attribute is specified, then a
tagParagraphAlign CML tag will also be placed at the beginning
(and possibly end) of the paragraph.
DIV, CENTER
	Element	End Tag	Level
	DIV	Yes	Block
	CENTER	Yes	Block
DIV Attributes:
Attribute	Type	Description
align	Enum	Can be any one of LEFT, CENTER, or RIGHT
Description:
The DIV element can be used to structure an HTML document as a
hierarchy of divisions. The CENTER element is equivalent to DIV
with an ALIGN attribute of CENTER. This element differs from
the P element in that it doesn't generate 2 line breaks (with the
accompanying blank line).
Examples:
<DIV ALIGN=CENTER>
This section of text is centered.
</DIV>
CML Representation:
The DIV or CENTER section will be replaced with a linebreak
character in the text and the appropriate imbedded
tagParagraphAlign CML tag.
HR
	Element	End Tag	Level
	HR	No	Block
Attribute	Type	Description
Align	enum	One of LEFT, CENTER, or RIGHT
Noshade	void	Render as solid color instead of a 2 color groove
Size	number	Height of the rule in pixels
Width	number	Width of the rule in pixels (WIDTH=100) or as a
		percentage (WIDTH=“50%”)
Description:
The HR element renders a horizontal line across the page and is
used to indicate a change in topic.
Examples:
<HR ALIGN=center>
CML Representation:
This element is represented by the tagHorizontalRule CML tag.
Lists
UL
	Element	End Tag	Level
	UL	Yes	Block
UL Attributes:
Attribute	Type	Description
type	enum	Can be any one of DISC, SQUARE, or CIRCLE
compact	void	Render list in a more compact style
Description:
The UL tag is used for unordered lists. The LI element is used for
individual list items within the list.
Examples:
<UL>
<LI>The first item
<LI>The second item
</UL>
CML Representation:
The UL tag will be replaced with the tagListUnordered CML tag.
List items are separated from each other by endTag characters and
the entire list is terminated by an endTag character. For example:
Tag	tag=tagListUnordered
Bit[3]	type = listTCircle
Bit	compact = 0
Text	item=“The first item”
Char	itemSeparator = endTag
Text	item=“The second item”
Char	itemS eparator = endTag
Char	endList = endTag
OL
	Element	End Tag	Level
	OL	Yes	Block
Attribute	Type	Description
Type	enum	Can be any one of 1, a, A, I, or I
Start	number	Specifies the starting sequence number
Compact	void	Render list in a more compact style
Description:
The OL tag is used for ordered (numbered) lists. The LI element is
used for individual list items.
Examples:
<OL START=4>
<LI>The first item
<LI>The second item
<OL>
CML Representation:
The OL tag will be replaced with the tagListOrdered CML tag. List
items are separated from each other by endTag characters and the
entire list is terminated by an endTag character. For example:
Tag tag=tagListOrdered
Bit[3]	type = listT1
UIntV	start = 0
Bit compact = 0
Text	item=“The first item”
Char	itemSeparator = endTag
Text	item=“The second item”
Char	itemSeparator = endTag
Char	endList = endTag
MENU, DIR
	Element	End Tag	Level
	MENU	Yes	Block
	DIR	Yes	Block
Attribute	Type	Description
Compact	void	Render list in a more compact style
Description:
The MENU and DIR elements are essentially the same as UL
elements.
Examples:
<MENU>
<LI>The first choice
<LI>The second choice
</MENU>
CML Representation:
See the UL tag description.
LI
	Element	End Tag	Level
	LI	No	Block
LI Attributes within UL:
Attribute	Type	Description
Type	enum	Can be an one of DISC, SQUARE, or CIRCLE
LI Attributes within OL:
Attribute	Type	Description
Type	enum	Can be any one of 1, a, A, I, or I
Value	number	Sequence number for this list item
Description:
The LI element is used within ordered (OL) or unorder (UL) lists.
Examples:
<OL START=4>
<LI>The first item
<LI>The second item
</OL>
CML Representation:
By default, list items are separated from each other by the endTag
character. List items which do not have default attributes start with
the tagListItemCustom tag which allows the TYPE and VALUE
attributes to be specified.
For example:
Text	item=“The first item”
Char	itemSeparator = endTag
Text	item=“The second item”
// - item separator not used here
Tag	tag = tagListItemCustom
Bit[3]	type = listTSquare
UIntV	value = 0
Text	“Third item”
Char	itemSeparator = endTag
DL, DT, DD
	Element	End Tag	Level
	DL	Yes	Block
	DT	Yes	Block
	DD	Yes	Block
DL Attributes:
Attribute	Type	Description
Compact	Void	Render list in a more compact style
Description:
The DL element is used to enclose 1 or more DT (definition term)
and DD (definition) elements.
Examples:
<DL>
<DT>PalmPilot<DD>A killer PDA
<DT>WinCE<DD>Ouch!
</DL>
CML Representation:
The required formatting for displaying the definition list is
accomplished by replacing the DL and DT tags with linebreaks.
The DD tags are represented by tagListItemDefinition CML tags.
Formatted Blocks
ADDRESS
	Element	End Tag	Level
	ADDRESS	yes	Block
Description:
The ADDRESS start and end tags can be used to enclose
authorship and contact details for the current document.
Examples:
<ADDRESS>
Newsletter editor<BR>
J. R. Brown<BR>
8723 Buena Vista, Smallville, CT 01234<BR>
Tel: +1(123) 456 7890
</ADDRESS>
CML Representation:
The ADDRESS start tag will be replaced with the appropriate
tagTextSize, tagTextFont, etc. CML tags as necessary in order to
represent the address section in a proportional, normal size, italic
font.
PRE, XMP, LISTING
	Element	End Tag	Level
	PRE	Yes	Block
	XMP	Yes	Block
	LISTING	Yes	Block
	PLAINTEXT	Yes	Block
PRE Attributes:
Attribute	Type	Description
Width	Number	Hint of required width in characters
Description:
The PRE element can be used to include pre-formatted text. Text
within this element is rendered in a fixed pitch font preserving
white space. The PLAINTEXT, XMP and LISTING elements are
obsolete tags that behave the same as PRE.
Examples:
<PRE>
Higher still and higher
From the earth thou springest
</PRE>
CML Representation:
The text enclosed by PRE elements will be prepended with the
CML tagTextFont, tagTextSize etc. elements as needed in order to
render it in a normal size, fixed pitch font. The WIDTH attribute is
only used by the proxy server 180 (to pick an appropriate font size)
and is not present in the CML.
BLOCKQUOTE
	Element	End Tag	Level
	BLOCKQUOTE	Yes	Block
Description:
The BLOCKQUOTE element is typically rendered as an indented
paragraph.
Examples:
<BLOCKQUOTE>They went in single file</BLOCKQUOTE>
CML Representation:
The BLOCKQUOTE start and end tags will be represented by the
tagBlockQuote CML tag.
Forms
FORM
	Element	End Tag	Level
	FORM	Yes	Block
FORM Attributes:
Attribute	Type	Description
Action	Url	Which URL to submit the form results to
Method	Enum	Either “GET” or “POST”
Enctype	MIME	Typically “application/x-www-forrn-urlencoded”
Description:
The FORM element is used to enclose a set of form input elements
where users can enter information, select check boxes and radio
buttons, select choices, etc.
Examples:
<FORM METHOD=POST
ACTION=“http://www.cc.ukans.edu/cgi-bin/post-query”>
Please help us by filling this out:
<P>organization: <INPUT NAME=“org” TYPE=TEXT
SIZE=“48”>
<P>Commercial? <INPUT NAME=“commerce”
TYPE=checkbox>
How many users? <INPUT NAME=“users” TYPE=int>
<P><INPUT TYPE=submit> <INPUT TYPE=reset>
</FORM>
CML Representation:
This element is represented by the tagForm CML tag. The
attributes of the FORM element (action, method, enctype} are not
applicable on the client and hence are not included in the CML
representation. When the user hits the submit button for a form, the
wireless client 405 tells the proxy server 180 which form's submit
button was pressed along with the values of the various input
fields, and relies on the proxy server 180 to take the appropriate
action using the FORM information from the original HTML
document.
INPUT
	Element	End Tag	Level
	INPUT	No	Text
INPUT Attributes:
Attribute	Type	Description
Type	enum	One of TEXT, PASSWORD, CHECKBOX,
		RADIO, SUBMIT, RESET, FILE, HIDDEN, or
		IMAGE.
name	text	The property name that this input represents
value	text	The initial property value, or the label for submit
		and reset buttons
checked	void	Used to initialize checkboxes and radio buttons to
		their checked state
size	number	Used to set the visible size of text fields to the
		given number of characters
maxlength	number	Used to set the maximum number of characters
		permitted in a text field
src	url	Specifies a URL for the image to associate with a
		graphical submit button
align	enum	Used to specify image alignment for graphical
		submit buttons. Can be any one of TOP,
		MIDDLE, BOTTOM, LEFT, or RIGHT. Default
		is bottom.
Description:
The INPUT element is used within FORM elements to specify
input fields within a form.
Examples:
<INPUT TYPE=radio NAME=age VALUE=“0-12”>
<INPUT TYPE=submit VALUE=“Party on . . . ”>
<INPUT TYPE=image NAME=point src=“map.gif”>
<INPUT TYPE=reset vaIue=“Start over . . . ”>
CML Representation:
Each of the various input element types is represented by one of the
following CML tags: tagInputTextLine, tagInputPassword,
tagInputCheckbox, tagInputRadio, tagInputSubmit, tagInputSubmitImage,
and tagInputReset.
In the CML representation, the NAME attribute is not required for
any of the input tags. Instead, the client references input items by
index where the first input item in a form is item number 0. The
proxy server 180 is responsible for formatting the correct FORM
“GET” or “POST” command using the input item names from the
original HTML document.
Also, the CHECKBOX and RADIO elements do not have
associated VALUE attributes in CML. Instead, when the user hits
the submit button, the wireless client 405 tells the proxy server 180
whether radio and checkbox controls were checked or not. The
proxy server 180 then uses the VALUE parameters from the
original HTML when submitting the actual request to the web
server.
For radio input items, the CML representation will also associate a
group number for each radio input. The group number enables the
wireless client 405 to automatically de-select the appropriate radio
buttons in mutually exclusive groups.
The tagInputSubmitImage does not have the equivalent to the SRC
attribute. Instead, the image data is included as part of the
parameters to the tag.
For example, the HTML sequence:
<P>Age 0-12: <INPUT TYPE=radio NAME=age CHECKED
VALUE=“0-12”>
<P>Age 13-17: <INPUT TYPE=radio NAME=age VALUE=“13-17”>
is represented in CML as:
Text	text=“\r\rAge 0-12:”
Tag	tag = inputRadio
Bit	checked = 1
UIntV	group = 0
Text	text = \r\rAge 13-17:”
Tag	tag = inputRadio
Bit	checked = 0
UintV	group = 0
TEXTAREA
	Element	End Tag	Level
	TEXTAREA	Yes	Text
Attribute	Type	Description
name	Text	The property name that this input represents
rows	number	The number of visible text lines
cols	number	The visible width in average character widths
Description:
The TEXTAREA element represents a multi-line input text field
for forms.
Examples:
<TEXTAREA NAME=address ROWS=4 COLS=40>
Your address here . . .
</TEXTAREA>
CML Representation:
This entity is represented by the CML tagInputTextArea tag. This tag
is followed by two UintV's that specify the width and height of the
text area along with the initial text terminated by an endTag
character. The NAME attribute is not included in the CML
representation since all input elements in forms on the wireless
client 405 are referenced by index.
SELECT, OPTION
	Element	End Tag	Level
	SELECT	Yes	Text
	OPTION	Yes	Text
Select Attributes:
Attribute	Type	Description
name	Text	The property name that this select choice
		represents
size	Number	The number of visible choices at once
multiple	Void	Enables user to select more than 1 choice
Option Attributes:
Attribute	Type	Description
selected	void	If present, this option is initially selected
value	text	The property value to use when submitting the
		form.
Description:
The SELECT element is used to represent multiple choice
selections within a form. This usually gets rendered on the screen
as a pop-up menu. The items in the menu are each represented by
the OPTION element.
Examples:
<SELECT NAME=“flavor”>
<OPTION VALUE=a> Vanilla
<OPTION VALUE=b SELECTED> Strawberry
<OPTION VALUE=c> Chocolate
</SELECT>
CML Representation:
The SELECT element is represented by the tagInputSelect CML
tag. There is no associated NAME attribute since the wireless
client 405 references all input elements in a form by index. The
tagInputSelect tag is followed by a single bit which specifies
whether multiple selections are allowed followed by a UIntV
containing the value of the SIZE attribute.
The select items are separated from each other by endTag
characters or by selectItemCustom tags that specify pre-selected
items.
There is no equivalent to the VALUE attribute because the wireless
client 405 simply tells the proxy server 180 which items were
selected by index and relies on the proxy server 180 to format the
correct FORM submission from the original HTML document info.
For example, the above HTML would be represented in CML as:
Tag	tag = inputSelect
Bit	multiple = 0
UIntV	size = 0   // default
Text	option = “Vanilla”
Tag	tag = tagSelectItemCustom
Bit	selected = 1
Text	option = “Strawberry”
Char	itemSeparator = endTag
Text	option = “Chocolate”
Char	endSelect = endTag
Tables
TABLE, TR, TD
	Element	End Tag	Level
	TABLE	Yes	Block
	TR	Yes	Block
	TD	Yes	Block
	TH	Yes	Block
TABLE attributes:
Attribute	Type	Description
Align	enum	One of LEFT, CENTER, or RIGHT
Width	int	Table width relative to window
Border	number	Width of border around table in pixels
Cellspacing	number	Spacing between cells
Cellpadding	number	Spacing within cells
TR attributes:
Attribute	Type	Description
Align	Enum	One of LEFT, CENTER, or RIGHT
Valign	Enum	One of TOP, MIDDLE, or BOTTOM
TH/TD attributes:
Attribute	Type	Description
Align	enum	One of LEFT, CENTER, or RIGHT
Valign	enum	One of TOP, MIDDLE, or BOTTOM
Nowrap	void	suppress word wrap
Rowspan	number	number of rows spanned by cell
Colspan	number	number of columns spanned by cell
Width	number	suggested width of cell in pixels
Height	number	suggested height of cell in pixels
Description:
By default, tables are rendered without a surrounding border. The table is
generally sized automatically to fit the contents, but you can also set the
table width using the WIDTH attribute. The BORDER, CELLSPAC1NG,
and CELLPADDING attributes provide further control over the table's
appearance. A caption can be placed at the top or bottom of a table by
following the TABLE element with a CAPTION element.
The TR element is used to delineate rows of the table. The TD element is
used to mark data cells. The TH element is used to mark header cells,
which may be rendered in a different font than data cells.
Examples:
<TABLE BORDER=3 CELLSPACNG=2 CELLPADDING=2
WIDTH=“80%”>
<CAPTION>Table title</CAPTION>
<TR><TH>first cell<TD> second cell
<TR><TH>2nd row, first cell<TD>2nd row, second cell
</TABLE>
CML Representation:
Tables are represented by the tagTable CML tag. It has the following
format in CML. Notice that the tagTableColumn tag is only placed in
front of header cells, and in front of data cells that do not have default
attributes.
Tag	tag = tagTable
Bit[2]	hAlign = alignCenter
UIntV	width = 0
UIntV	border = 0
UIntV	cellSpacing = 0
UIntV	cellPadding = 0
Tag	tag = tagCaption
Bit	captionAtTop = 1
Text	caption = “Table Title”
Char	endCaption = endTag
Tag	tag = tagTableRow
Bit	hasAlign = 0
Tag	tag = tagTableColumn
Bit	headerCell = 1
Bit	hasAttribute = 0
Text	“row1, col1”
Char	endTag
Text	“row1, col2”
Char	endTag
Tag	tag = tagTableRow
Bit	hasAlign = 0
Tag	tag = tagTableColumn
Bit	headerCell = 1
Bit	hasAttribute = 0
Text	“row2, col1”
// endTag not used here
// Custom cell attributes
Tag	tag = tagTableColumn
Bit	headerCell = 0
Bit	hasAttribute = 1
Bit	noWrap = 0
UIntV	rowSpan = 0
UIntV	colSpan = 0
Bit[2]	hAlign = alignRight
Bit[2]	vAlign = alignTop
UIntV	width = 0
UIntV	height = 0
Text	“row2, col2”
Char	endTag
Char	endTag  // end of table
As seen, the table tag is followed by the table attributes.
If a row is too long to fit in the window, the client is responsible for
performing row wrapping. For example, a table with 4 rows and 3
columns might be drawn as 4 rows of 2 columns, then 4 more rows of 2
columns where the second set of 4 rows would have a copy of the first
column. The following diagram illustrates this:
An HTML table with 4 rows and 3 columns:
A1	B1	C1
A2	B2	C2
A3	B3	C3
A4	B4	C4
Gets rendered on the client as:
	A1	B1
	A2	B2
	A3	A4
	A4	B4
	A1	C1
	A2	C2
	A3	C3
	A4	C4
Text Formatting
TT, I, B, U, STRIKE, BIG, SMALL, SUB, SUP
	Element	End Tag	Level
	TT	Yes	Text
	I	Yes	Text
	B	Yes	Text
	U	Yes	Text
	STRIKE	Yes	Text
	BIG	Yes	Text
	SMALL	Yes	Text
	SUB	Yes	Text
	SUP	Yes	Text
Description:
These text level elements affect the text font and style used to display text.
They all require start and end tags:
	TT	monospaced text
	I	italic text style
	B	bold text style
	U	underlined text style
	STRIKE	strike-through text style
	BIG	larger font size
	SMALL	smaller font size
	SUB	subscript text
	SUP	superscript text.
Examples:
This has some <B>bold and <I>italic text</I></B>.
CML Representation:
The I tag is represented by the tagTextItalic tag. The B tag is represented
by the tagTextBold tag. The U tag is represented by the tagTextUnderline
tag. The TT, STRIKE, BIG, SMALL, SUB and SUP tags are represented
by the tagTextFormat tag.
EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE
	Element	End Tag	Level
	EM	Yes	Text
	STRONG	Yes	Text
	DFN	Yes	Text
	CODE	Yes	Text
	SAMP	Yes	Text
	KBD	Yes	Text
	VAR	Yes	Text
	CITE	Yes	Text
Description:
These text level elements affect the text font and style used to display text.
They all require start and end tags:
EM	emphasis, typically in italic font
STRONG	strong emphasis, typically in bold font
DFN	definition
CODE	used for extracts of program code
SAMP	used for sample output from programs
KBD	used for text to be typed by the user
VAR	used for variables or arguments to commands
CITE	used for citations or references to other sources.
Examples:
<EM> This is emphasized text </EM>.
CML Representation:
The EM tag is represented by the tagTextItalic tag. The STRONG tag is
represented by the tagTextBold tag. The DFN, CODE, SAMP, KBD,
VAR, and CITE tags are represented by the tagTextFormat tag.
FONT
	Element	End Tag	Level
	FONT	Yes	Text
FONT Attributes:
Attribute	Type	Description
Size	Text	Font size. Can be specified as an integer ranging from
		1 to 7 or as a signed integer relative to the current base
		font size as set by the BASEFONT element
Color	Text	Use to set the color of the text. Given as RGB in
		hexadecimal notation or as one of 16 widely
		understood color names.
Description:
The FONT element can be used to specify a specific font size and color
for the enclosed text.
Examples:
<FONT SIZE=“+1”>
This is size +1
</FONT>
<FONT SIZE=4>
This is absolute size 4
</FONT>
CML Representation:
The FONT tag does not have a corresponding CML representation. The
attributes of the FONT tag are represented using the tagTextSize and
tagTextColor CML tags.
BASEFONT
	Element	End Tag	Level
	BASEFONT	No	Text
BASEFONT Attributes:
Attribute	Type	Description
Size	number	Used to set the base font size for use with the FONT
		element.
Description:
The BASEFONT element is used to specify the base font size for a
document. The FONT element can then reference font sizes relative to the
BASEFONT.
Examples:
<BASEFONT SIZE=4>
CML Representation:
Not required. Each FONT element in the original source will be converted
to the appropriate absolute font size in the CML representation.
Hyperlinks
A
	Element	End Tag	Level
	A	Yes	Text
A Attributes:
Attribute	Type	Description
Name	text	Used to indicated named links within a document
Href	url	URL for linked resource
Rel	text	The forward relationship, also known as the
		“link type”.
rev	text	The reverse relationship.
title	text	The advisory title for the linked resource.
Description:
The A (anchor) element represents a hyperlink.
Examples:
<A HREF=“hands-on.html”> happiness </a>
<A NAME=mit> 545 Tech Square - Hacker's Paradise </a>
CML Representation:
This element is represented by the tagAnchor CML tag. There is no need
for any of the attributes in the CML form because the wireless client 405
refers to links by index. Hence, it simply has to tell the proxy server 180
the index of which hyperlink was pressed and rely on the proxy server 180
to fetch the correct URL.
IMG
	Element	End Tag	Level
	IMG	No	Text
Attribute	Type	Description
src	url	URL of the image
alt	text	Text to display in place of image
align	enum	Alignment of image, either TOP, MIDDLE,
		BOTTOM, LEFT, or RIGHT
height	number	suggested height of image
width	number	suggested width of image
border	number	suggested border width
hspace	number	suggested horizontal gutter
vspace	number	suggested vertical gutter
usemap	url	use client side image map
ismap	void	use server image map
Description:
The IMG element is used to insert images into a document.
Examples:
<IMG SRC=“canyon.gif” ALT=“Grand Canyon”>
CML Representation:
Unlike in HTML, where images are fetched independently of the source
document, CML imbeds image data directly inline with the rest of the
document using tagImage tags.
MAP, AREA
	Element	End Tag	Level
	MAP	Yes	Text
	AREA	No	Text
MAP attributes:
Attribute	Type	Description
Name	text	Used to associate a name with a map
AREA attributes:
Attribute	Type	Description
shape	enum	One of RECT, CIRCLE, or POLY
coords	text	Comma separated list of coordinates.
bref	url	The URL to jump to when this region is selected
Nohref	void	This region has to action
Alt	text	Alternate text to display if no image.
Description:
The MAP element is used in conjunction with the IMG element to specify
wireless client 405 side image maps. The NAME attribute of the MAP is
used by the USEMAP attribute on the IMG element to reference the MAP.
Examples:
<IMG SRC=“navbar.gif” BORDER=0 USEMAP=“#map1”>
<MAP NAME=“map1”>
<AREA HREF=guide.html alt=“Access Guide” SHAPE=RECT
coords=“0,0,118,28”>
<AREA HREF=search.html alt=“Search” SHAPE=RECT
coords=“184,0,276,28”>
</MAP>
CML Representation:
The proxy server 180 is responsible for mapping user actions into URLs,
so the MAP element is not represented in CML. The wireless client 405
just tells the proxy server 180 when the user clicks on an active image
(tagImage tag with the ismap parameter set to 1) and passes the x-y
coordinates of the hit to the proxy server 180. The proxy server 180 will
then look up the appropriate URL using the original document's IMG and
MAP elements.
Applets
APPLET, PARAM
	Element	End Tag	Level
	APPLET	Yes	Text
	PARAM	Yes	Text
APPLET Attributes:
Attribute	Type	Description
codebase	url	code base
code	text	class file
alt	text	for display in place of applet
name	text	applet name
width	number	suggested width in pixels
height	number	suggested height in pixels
align	enum	Vertical or horizontal alignment. One of TOP,
		MIDDLE, BOTTOM, LEFT or RIGHT.
Hspace	number	Suggested horizontal gutter
Vspace	number	Suggested vertical gutter
Ismap	void	Use server image map
PARAM Attributes:
	Attribute	Type	Description
	Name	text	the name of the parameter
	Value	text	the value of the parameter
Description:
The APPLET element is used to enclose a Java applet.
Examples:
<APPLET CODE=“AudioItem” WIDTH=15 HEIGHT=15”>
<PARAM NAME=snd VALUE=“Hello.au|Welcome.au”>
Java applet that plays a welcoming sound.
</APPLET>
CML Representation:
None
PalmOS HTML Extensions
DATEPICKER
		End
	Element	Tag	Level
	DATEPICKR	No	Text
DATEPICKER Attributes:
	Attribute	Type	Description
	Value	Text	the value of the parameter
Description:
The DATEPICKER element takes a value of a valid date in MM/DD/YY
format. If no value is specified, the current date is displayed.
Examples:
DATEPICKER VALUE=“11/15/96”>
CML Representation:
This element is represented by the tagDatePicker CML tag.
TIMEPICKER
		End
	Element	Tag	Level
	TIMEPICKER	No	Text
TIMEPICKER Attributes:
	Attribute	Type	Description
	Value	Text	the value of the parameter
Description:
The TIMEPICKER element takes a value of a valid time in hh:mm:ss
format. If no value is specified, the current time is displayed.
Examples:
<TIMEPICKER VALUE=“11:45:30”>
CML Representation:
This element is represented by the tagTimePicker CML tag.

[0300] Wireless Client Software Block Diagram

[0301] FIG. 6 shows a wireless client 405 processing resources (software) flow diagram 600. The boxes shown with solid lines are the actual software layers present on the wireless client 405. The annotated boxes shown in dotted lines indicate the format of the data passed between each of the software layers.

[0302] The content user interface 605 and e-mail application user interface 610 layers are part of the browser 104.

[0303] The content rendering layer 615 and message formatting layer 620 are also wireless client 405 processing resources. The content rendering layer 615 converts CML into the wireless communications device 100 operating system 102 drawing commands. The message formatting layer 620 converts CML messages from the network into a format compatible with the wireless communications device 100 e-mail application. The CML language is discussed in depth above including the binary format of CML, how it is created from HTML, and how it should be rendered on the wireless client 405.

[0304] The content request layer 625 and the message request layer 630 are responsible for fetching CML content from the proxy server 180. The content request layer 625 and the message request layer 630 use the compact transfer protocol (CTP) described below. These layers format request messages and accept response messages using the reliable message layer 635.

[0305] The reliable message layer 635 is responsible for reliably delivering request and response messages between the wireless client 405 and the proxy server 180. When operating over a wireless network, the reliable message layer 635 breaks up large messages into datagrams that fit into the wireless network. The reliable message layer 635 also guarantees order of delivery. When operating over a wireline network, the reliable message layer 635 passes control directly to the TCP stack of the network library (shown in FIG. 11 as the “Net Library”, reference number 1110). The reliable message layer 635 is described in greater detail below.

[0306] Some embodiments of the invention include a method of using a computer for receiving an HTML data object (otherwise referred to as an HTML message) from a source of data. The receiving method comprises fetching the HTML data object, compressing the HTML data object, passing representations of the data object to a content rendering layer 615, and rendering the representations for viewing. These embodiments combine the standard browser engine with CML and CTP to enable a wireless client 405 to fetch HTML data objects using a wireline connection to the Internet 190. Fetching, compressing, passing, and rendering are performed by processing resources. The processing resources can be located at the wireless client 405 or elsewhere in the wireline network. The HTML data object is compressed by representing selected portions of the HTML data object in CML. In some embodiments, CML embeds image data directly in line with the rest of the HTML data object.

[0307] Some embodiments of the invention comprise a method for receiving a first message (otherwise referred to as a data object) from a source of data. These embodiments employ the thin browser engine, and use the proxy server 180 and the wireless packet data network to fetch data objects from the Internet 190. The method comprises the six steps discussed below. A proxy server 180 fetches the data object from the source of data. The proxy server 180 converts the data object into a second message comprising data in CML. The proxy server 180 transmits the second message to the wireless client 405. The wireless client 405 extracts CML data from the second message. The wireless client 405 passes CML data to a content rendering layer 615. The wireless client 405 renders CML data for viewing on a wireless communications device 100 screen 101. The second message comprises packets of data. In some embodiments, only a single packet is required and the packet is smaller than five hundred fifty bytes.