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 http://www.arsdigita.com community web site, using the http://www.arsdigita.com/developer 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 http://www.nttdocomo.com/ser2.htmNTT Docomo (English) Supported
Tags and Specs.
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.
<HTML>
<HEAD>
<TITLE>Main MENU</TITLE>
</HEAD>
<BODY>
<FONT COLOR=RED>Main MENU</FONT>
<BR>
<IMG SRC=ad_small.gif ALIGN=RIGHT>
<A HREF=new.tcl ACCESSKEY="1">News</a>
<BR>
<A HREF=addr.tcl ACCESSKEY="2">Directory</a>
</BODY>
</HTML>
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
<FORM ACTION=addr-2.tcl METHOD=POST>
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>
<INPUT TYPE=SUBMIT NAME=search>
</FORM>
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>
<br>
1. <a href="one-user.tcl?uuid=41" accesskey="1">Miller, Mark</a>
<a href="mailto:mark@yahoo.com">mark@yahoo.com</a>
<br>
2. <a href="one-user.tcl?uuid=22" accesskey="2">Minsky, Henry</a>
<a href="mailto:hqm@ai.mit.edu">hqm@ai.mit.edu</a>
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
<br>
<a href="mailto:hqm@ai.mit.edu">hqm@ai.mit.edu</a>
<br>
1. home phone: <a href=tel:81357173259 accesskey=1>+813 5717 3259</a>
<br>
2. work phone: <a href=tel: accesskey=2></a><br>3. cell phone: <a href=tel: accesskey=3></a><br>pager:
<br>fax:
<br>
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 http://www.arsdigita.com/doc/news ACS news module, and produces
a compact listing of recent events:
<b>News</b>
<br>
Jul 27, 2000:
<a href="one-news-item?news_item_id=100020">ArsDigita provides new services</a>
<br>
Jul 26, 2000:
<a href="one-news-item?news_item_id=100000">i-Mode now on imode.arsdigita.com</a>
A single news item is formatted in as compact a manner as possible, using one-news-item.adp this script.
| one-news-item.adp |
|---|
|
iMode now on imode.arsdigita.com
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 (http://www.arsdigita.com/doc/core-arch-guide/security-and-sessions)
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:
Host: hqm.arsdigita.com
User-Agent: DoCoMo/1.0/D209i/c10
BASIC HTTP Authentication
i-Mode phones do however support http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA
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"
ad_script_abort
} 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"
ad_script_abort
}
}
}
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.
[ns/server/yourserver/acs/imode]
GroupPassword=31415
MaxPageSize=5000
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 http://www.nttdocomo.co.jp/i/tag/emoji/index.html pre-defined icons in ROM, which can
be accessed by HTML numeric entity references.
For example  is an icon of a sun shining.
Links
Example i-Mode Site Tokyo-Q http://202.221.249.3/lifestyle/tq/e/m0.html
http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/
Compact HTML
for Small Information Appliances
W3C NOTE 09-Feb-1998
http://anima.editthispage.com/resources/technology Mobile Interface Development Links
http://www.webreview.com/wr/pub/98/08/21/feature/index.html HTML for Information Appliances
http://www.nttdocomo.com/ser2.htmNTT Docomo (English) Supported Tags and Specs
http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA HTTP 1.0 Spec
http://www.w3.org/Protocols/rfc2616/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1
ACS toolkit http://www.arsdigita.com/doc/
Demonstration i-Mode web site http://imode.arsdigita.com/imode
(use login=imode, pwd=31415)
