ArsDigita Archives

i-Mode Mobile Browser Support in ACS

by Henry Minksy (

Submitted on: 2000-07-24
Last updated: 2000-09-02

ArsDigita : ArsDigita Systems Journal : One article

In Japan, NTT has created a protocol called i-Mode for displaying web content on small mobile browsers such as cell phones. The i-Mode phones support a subset of HTML called compactHTML, with a small number of extensions for the mobile phone environment. compactHTML is compatible with HTML 1.0 and parts of HTML 2.0.

In Japan there are an estimated 52 million cell phones users. As of March 15, 2000 there were 5 million i-Mode enabled phones in use. Over 10 million i-Mode subscribers are projected for the end of this year.

Because of the backward compatibility of compactHTML with newer versions of HTML, supporting i-Mode from an existing web server is very easy. In this article we describe a simple application for serving news and address book information to users of a community web site, using the ACS toolkit and platform.

Character Set Support

i-Mode is primarily deployed in Japan,so it supports Japanese language web pages. i-Mode phones support the ShiftJIS character set, which fortunately is backward compatible with 7-bit ASCII. Most standard English text will display without difficulty on an i-Mode terminal.

How can I tell i-Mode browsers from other browsers?

The HTTP User-Agent: header identifies an i-Mode browser with a string something like DoCoMo/1.0/F50i for the older 501 models, and something like DoCoMo/2.0/F502i/c10 for the newer models. The first part of the string says DoCoMo indicating that it is an i-Mode client. The next part indicates the supported HTML version number. The third part indicates the device model number, such as "F501i" and "F502i".

The fourth part, only available on certain 502 models, indicates the current cache size. As with WAP devices, an i-Mode device can only accept a certain amount of data in one go. The number is in kilobytes, and the default size is 5KB.

How do I author in compactHTML?

compactHTML is very straightforward to use. It is a small subset of modern HTML, mostly compatible with HTML 1.0 and a small number of HTML 2.0 tags. [CHTML] Compact HTML for Small Information Appliances W3C NOTE 09-Feb-1998 contains an official list of supported tags and features for an i-Mode terminal. There are some extensions which NTT implements in some of their handsets as well, such as animated GIFs, predefined icons, the MARQUEE tag, and the auto-dial TEL: URL prefix. These are documented in Docomo (English) Supported Tags and Specs.

D209i Creating an i-Mode application is very similar to creating a regular HTTP/HTML web site application. The biggest constraints are the small screen real-estate and slow connection speed. Screen size is very small, usually no more than 16 (English) characters by 6-8 lines. Phone displays have been black-and-white, but are more commonly now being sold in color.

HTML Page Flow and Forms

Ordinary URL hyperlinks can be used in pages and work as expected. Many web applications make use of HTML forms. Basic HTML forms are supported, including the familiar INPUT, SELECT, and TEXTAREA fields. INPUT fields support types of TEXT, CHECKBOX, RADIO, PASSWORD, HIDDEN, SUBMIT, and RESET.

A guideline of design metrics is available from NTT, a copy is in guidelines.adp Outline of i-Mode compatible HTML.

Sample ACS i-Mode Application

Below we have put together an implementation of a small ACS application for i-Mode terminals. The application consists of a main menu with two links, one link to a News page, similar to the standard ACS /news module, and the other link to a user directory lookup form.

Here is a simple HTML page that is the main menu of our application.

<IMG SRC=ad_small.gif ALIGN=RIGHT>
<A HREF=new.tcl ACCESSKEY="1">News</a>
<A HREF=addr.tcl ACCESSKEY="2">Directory</a>


Note the use of an IMG tag. GIF images are supported by i-Mode terminals. In fact color and animated GIF images are now supported. The older recommendations for maximum compatibility were

  • Black and white 2-bit GIF files are used.
  • Only images in GIF 87, 87a and 89a formats can be used.
  • The maximum size of a GIF image should be 94 x 72 dots.
However, phones with color and grayscale displays are rapidly becoming more prevalent. GIF images larger than 94 x 72 pixels will be scaled by the phone, but the entire image is still sent to the phone, so it cannot exceed the 5kb or 10kb memory limit, and it is thus wasteful to send images which will be scaled down. Also, the autoscaling can make GIF images hard to read.

The Address Book Function

We want to provide a way to look up users from the users table from a quick input form. The following form can be used on an i-Mode terminal.

<TITLE>Address Book</TITLE>
Address Book
Last Name: <INPUT TYPE=TEXT NAME=last_name><br>
First Name: <INPUT TYPE=TEXT NAME=first_name><br>
Email: <INPUT TYPE=TEXT NAME=email><br>

Address Book
Last Name:
First Name:

We handle the submitted form with a script which accesses the users table in the database and produces an output cHTML page. The script could be modified to restrict the search to only users in a specific group, such as the employees of a company, or only members who share same the group as the user. The output of the search script looks like this

<title>i-Mode Address Book</title>
1. <a href="one-user.tcl?uuid=41" accesskey="1">Miller, Mark</a> 
<a href=""></a>
2. <a href="one-user.tcl?uuid=22" accesskey="2">Minsky, Henry</a> 
<a href=""></a>


1. Miller, Mark
2. Minsky, Henry

The ACCESSKEY attribute of a hyperlink provides one-key access to select and follow the URL, from the phone's numeric keypad.

We also define a suggested maximum page size configuration parameter, so that pages which can potentially generate a lot of data, such as a search results page, can have an idea of when to truncate their results. Sending more data in a page than the phone can support results in an error message and possibly unreadable page. Even if a phone supports a 10KB cache size, it is still desirable to limit the amount of text on a single page as much as possible, since scrolling through 10KB on a tiny slow browser is not much fun.

Display One User

We display a single user's information using a script that produces output like this:
<title>Minsky, Henry</title>
Minsky, Henry
<a href=""></a>
1. home phone: <a href=tel:81357173259 accesskey=1>+813 5717 3259</a>
2. work phone: <a href=tel: accesskey=2></a><br>3. cell phone: <a href=tel: accesskey=3></a><br>pager:
Minsky, Henry
1. home phone: +813 5717 3259
2. work phone:
3. cell phone:

The tel: protocol prefix for a URL tells the phone (browser) that the link is a phone number which can be dialed. If the user selects the link, a phone call is placed.

The What's New Page

The News page links to a script which calls the ACS news module, and produces a compact listing of recent events:
Jul 27, 2000:
<a href="one-news-item?news_item_id=100020">ArsDigita provides new services</a>
Jul 26, 2000:
<a href="one-news-item?news_item_id=100000">i-Mode now on</a>
Jul 27, 2000: ArsDigita provides new services
Jul 26, 2000: i-Mode now on

A single news item is formatted in as compact a manner as possible, using one-news-item.adp this script.

iMode now on

Think of all the great things you can do with imode support!

Contributed by Henry Minsky

User Authentication Without Cookies

For an application which needs to provide some form of user authentication or access control, we need to implement some kind of security mechanism.

The i-Mode phone terminals do not support HTTP Cookies at this time. This means that the standard ACS authentication mechanism ( will not work. But Cookies are merely one way to store a small amount of state on a browser and have it returned to the server with subsequent requests. We can also pass state in the URL path or query string. So it is possible to augment the ACS security system to store its authentication tokens in the URLs, although this requires some modification to the ACS request processor in order to work transparently.

i-Mode phones can under certain circumstances transmit their phone number to the web server, but currently this information is only sent to web servers which are registered by NTT, and presumably pay a fee for this information. If you are running a for-pay service and want to use NTT to do billing of customer phone accounts, then this is something you need to do. But otherwise, you get no unique identifying information in the HTTP headers from the phone. The only headers you get from an i-Mode browser are Host: and User-Agent:

User-Agent: DoCoMo/1.0/D209i/c10

BASIC HTTP Authentication

i-Mode phones do however support HTTP Basic Authentication. This is a simple challenge-response authentication system where the user is prompted to enter a username and password in dialog in the browser terminal, and these credentials are sent to the server in the headers with each HTTP request. Note that on i-Mode phones, the password field in the HTTP authentication dialog box which pops up only supports entry of numeric passwords. Normal alphanumeric ACS user passwords cannot be entered this way.

For applications which do not require high security (perhaps the company phone book directory lookup), HTTP Basic authentication is quite sufficient.

Remember that if you are really concerned about keeping your password secret, you should not be logging in to any web sites at all over a standard HTTP connection. This applies equally to users of desktop browsers. Anyone logging into a web site over a non-encrypted HTTP connection is sending their username and password in the clear.

For this application, I decided to use HTTP Authentication. The ACS does not currently have explicit support for this protocol, so I defined a utility function imode_basic_auth which takes a user name and password, and compares these against the credentials sent by the browser.

imode_basic_auth first checks the headers to see if an Authorization header is present. If not, it issues a WWW-Authenticate challenge and aborts further script processing. If the Authorization header is present, it compares username and password in the header with those passed into the function.

ad_proc imode_basic_auth {
  { -uname "" -pwd "" }
} "Compares HTTP BASIC credentials from connection with uname, pwd. You can leave uname or pwd as emptying
string for wildcard match. If they don't match, issues
a HTTP  WWW-Authenticate challenge and aborts script with ad_script_abort. " {
    set credentials [ns_set iget [ns_conn headers] "Authorization"]
    if {[empty_string_p $credentials]} {
	ns_set put [ns_conn outputheaders] "WWW-Authenticate" "Basic realm=\"ACS_iMode\""
	ns_return 401 "text/html; charset=shift_jis" "please login"	
    } else {
	set creds [split [ns_uudecode [lindex [split $credentials " "] 1]] ":"]
	set cname [lindex $creds 0]
	set cpass [lindex $creds 1]

	set ok 1

	if {![empty_string_p $uname]} {
	    if {[string compare $uname $cname] != 0} {
		set ok 0

	if {![empty_string_p $pwd]} {
	    if {[string compare $pwd $cpass] != 0} {
		set ok 0

	if {!$ok} {
	    ns_set put [ns_conn outputheaders] "WWW-Authenticate" "Basic realm=\"ACS_iMode\""
	    ns_return 401 "text/html; charset=shift_jis" "incorrect login"


To use this function, we put the following call on every page which requires authentication

imode_basic_auth -uname ""  -pwd [ad_parameter "GroupPassword" imode]

For simplicity, since this is a group application, we defined a single password for all users of this application and left the user name blank. The group password is set in the [ns/server/yourserver/acs/imode] parameters section of the site .ini file.


For an application which requires customization for each user, a variant of the imode_basic_auth function would need to be modified to lookup and verify the user's password in the database for each invocation. The user would have entered a user name when the first Authentication dialog popped up in their browser.

There are two ways to deal with the fact that users can only enter numeric passwords in the phone's authentication form: implement a "lenient" password compare, allowing 1 to match "A,B,C," 2 to match "D,E,F," etc.; or require users to have a separate "mobile" password which is all numeric. The first solution requires that we store the user passwords unencrypted in the database so we can do the comparison. If neither way is acceptable, we could provide a standard HTML form which allows the user to enter their user name and an alphanumeric password in normal TEXT INPUT fields. If we wanted to use the normal ACS authentication mechanism (security tokens), then that is what we would need to do.

More notes on supporting ACS user authentication without Cookies

To support security tokens in URL query args, the request processor would need to be modified to scan the URL path or query args for security tokens, in addition to looking for them in Cookies.

Putting tokens in the path has the advantage that if relative URLs are used then they will persist from page to page without the application needing to explicitly re-insert them. But some mechanism similar to the subcommunities proposal would be needed in the request processor to transparently grab this information.

Other Goodies

The i-Mode phones have a number of pre-defined icons in ROM, which can be accessed by HTML numeric entity references.

For example &#63647; is an icon of a sun shining.


Example i-Mode Site Tokyo-Q Compact HTML for Small Information Appliances W3C NOTE 09-Feb-1998 Mobile Interface Development Links HTML for Information Appliances Docomo (English) Supported Tags and Specs HTTP 1.0 Spec Hypertext Transfer Protocol -- HTTP/1.1

ACS toolkit

Demonstration i-Mode web site
(use login=imode, pwd=31415)

Reader's Comments

It has just been pointed out to me that the main web site for Jim Breen's WWWJDIC server has now added direct i-Mode support, see the links at the bottom of (note, i-mode is only enabled on the Australia and Canada mirror, not the other mirrors yet).

-- Henry Minsky, September 14, 2000
It was also just pointed out to me that NTT passed the 10-million subscriber mark for i-Mode phones already this summer, well ahead of projections.

-- Henry Minsky, September 14, 2000
Sorry, there is no Nokia service center in Akihabara, Tokyo. My American friend asked me to repair his mobile phone. Here in Japan is I-mode capital of the world. Just for three years, over 10 million people using it. If you can buy mobile phone ZERO Yen, so even elementary pupil using it. I-Mode connection to Web is the most demanding technology. Great Henry sensei work.
Attachment: salesbootcamp question.htm

-- Henry Minsky, December 20, 2000
FYI, i-mode just passed the 20,000,000 mark on March 4th 2001 in Japan only.

-- Christian Peper, March 15, 2001

Related Links

  • iMode Eye- The Independent Resource on Japan's mCommerce and I-Mode News, Hardware, etc... in English for a professional audience.   (contributed by vince luna)

  • Imode-FAQ- Frequently asked questions (FAQ) about imode   (contributed by Gerhard Fasol)

  • i-mode font for desktops- Enfour Media Laboratory Japanese TrueType font with extensions to the character set specifically for NTT DoCoMo's i-mode service.    (contributed by Tracey Northcott)

  • Bill Day's Web Site- A great source of links on embedded Java resources, including Java Imode emulators.   (contributed by Henry Minsky)

  • Notes on Java iMode development- I am going to be working on an NTT research project at Keio over the next semester, and will be developing some Java iMode applications for the new iAppi phones. I will keep some notes here on my experiences.   (contributed by Henry Minsky)

  • Fixed Point Java Library for IAppli (CLDC)- I wrote a simple fixed-point arithmetic library for use on the IAppli (CLDC/MIDP) devices which do not support floating point.    (contributed by Henry Minsky)

  • Picobrowser MIDP/IAppli Browser for Embedded Devices- I have ported my PicoBrowser to JAVA MIDP. This browser can parse and display cHTML (i-mode) and runs in the IAppli and MIDP environment.    (contributed by Henry Minsky)

  • i-mode and iappli development information site- A site with good development resources and links for the J2ME platform with focus on imode Java environment.    (contributed by Manish Prabhune)