The ".mobi" Proposal is Inconsistent with Device Independence
Principles

Author: Dr. Rotan Hanrahan, on behalf of W3C
Device Independence Working Group [4]

ICANN has received a proposal to introduce a Top Level Domain (TLD)
specifically to identify, and possibly restrict, the type of user agent that
can access the resources identified within this domain. The W3C Device
Independence Working Group (DIWG) views the proposal as flawed: being counter
to key principles of device independence and ignoring alternative technical
strategies to achieve its stated aims.

It is the goal of this document to outline the objections of the DIWG to
the proposal.

Device Independence Principles

One of the key principles of the Web is the uniqueness of resource
identifiers, and the expectation of being able to access identified resources
using any reasonable agent. [1] The purpose of the
identifier is to distinguish it from other resources. It can be passed from
user to user, advertised globally, stored for later use, and yet always
facilitate access to the resource it identifies.

It is this principle that makes it possible to share bookmarks between
your PC and your PDA, send bookmarks to your friends and colleagues (without
knowing what they use to access the Web) and advertise your services through
a single URL.

Implementations on the Web do not yet fully adhere to this principle, but
the technology to support it is gradually appearing. The time will come when
the same URL will give me a textual weather forecast on my PC screen, a small
weather chart on my pager and a spoken summary through the voice synthesizer
in my automobile.

Another principle relates to the communication of contextual information.
[2] This is necessary to ensure that the identified
resource can be delivered in a form that suits the delivery context. An audio
version for audio devices, textual form for text devices, low-resolution for
important information under low-bandwidth situations, and so on.

These principles have motivated the DIWG to pursue solutions that
distinguish resources from representations (adaptations) of resources, that
retain single identifiers for resources while using contextual information to
select or create representations.

The DIWG is responsible for CC/PP [3] as a technology to
convey contextual information, and is actively pursuing selection/adaptation
techniques. We view the proposal of device-specific domain names as
undermining the principles outlined above. Such names would introduce
multiple identifiers for essentially the same resources, and would embed
contextual information in the identifier effectively making it
non-portable.

Problems with the ICANN Proposal

The proposal suggests that ".mobi" would indicate a mobile (or tailored)
Web site, suitable for mobile devices. The capabilities of a mobile device
cover a very wide spectrum. Such devices include mobile notebooks with
effectively the same capabilities as fixed PCs. Thus ".mobi" sites would have
to provide tailored content for a wide variety of devices, and would still
require sufficient contextual information to tailor the responses to mobile
requests. It would be unreasonable to expect the domain name (or path) to
contain this information, so it will be necessary to adopt other approaches
such as CC/PP. Having then adopted an approach such as CC/PP, it becomes
unreasonable and unnecessary to use ".mobi".

If the purpose of ".mobi" is merely to identify sites that offer tailored
content and these sites are employing technology such as CC/PP with
adaptation, then this would be an unnecessary exclusion of non-".mobi" sites
employing the same technologies.

It is likely that there would be an ill-founded perception that ".mobi"
sites should only link to other ".mobi" sites, to ensure that only tailored
content is offered to mobile devices. This would create a web within the Web,
potentially fragmenting the Web and thereby harming it.

It is reasonable to use the domain name as a means of identifying and
categorizing the provider of the resources accessed through that domain. For
example, the ".gov" domain is associated with content and services from
government bodies, and one could reasonably assume that ".org" domains offer
content from "organizations". However, by categorizing the access mechanism
rather than the provider, the proposal subverts the domain name for a
completely different purpose unrelated to the existing use. This is not
reconcilable with current practice. Other content-describing domain name
proposals have occurred in the past, and while far from consistent in their
use, they do not threaten the nature of the Web. The ".mobi" proposal would,
in effect, be categorizing the access mechanism rather than the content. In
addition, broadening the use of the domain in this way means either that the
organizational distinctions must be lost from URLs or that some combination
must be used, such as ".gov.mobi".

Because of the nature of DNS management, there is no guarantee that
existing non-mobile domains will be able to acquire ".mobi" equivalents to
ensure a consistent translation from existing domain names to their mobile
versions. This makes it not just very difficult, but impossible, to share Web
bookmarks across fixed, mobile and other specific contexts.

Similar, though less disruptive, techniques have been used in the past to
suggest client properties in the URL. The use of wap.example.com,
example.com/wap, example.com/mobile and similar constructs is commonplace.
With advances in client technology and the growing presence of adapting or
adaptable sites these diverse and inconsistent approaches are being left
behind. It is highly unlikely that the more disruptive ".mobi", which merely
adds further inconsistency, would succeed where the old approaches have
failed.

Alternative Solutions

The DIWG has illustrated through its publications [4]
that it is possible, even with current technology, to provide tailored
content to a wide variety of user agents, and subject to varying user
needs.

Ensuring compatibility of content and access mechanism is fundamental to
providing a good user experience, and must be managed while underlying
technologies and standards evolve to address wider capabilities. Introducing
a ".mobi" domain cannot guarantee any greater standards conformance. There is
a need to encourage both content providers and implementors of user agents to
adhere to standards, and for more visible indication of standards adherence
both on websites and on devices.

Much of the user experience of the mobile web could be improved by better
matching of website selection to device capabilities. Even without explicit
content negotiation, this could be achieved through search engines
recognizing website attributes that indicated mobile-profile compatibility.
Then users could optionally invoke searches that would return only sites
compatible with the desired profile.

Delivery context compatibility could be determined at various levels.
There is already the capability to do HTTP content negotiation at the level
of the individual web page. This could be augmented by further page-level
embedded metadata (as will be discussed at our forthcoming workshop [5]). Alternatively, site-level metadata could be used by
search engines (q.v. robots.txt).

Mobile-specific (or desktop-specific, or audio-specific, etc.) websites
may still be developed, which would only be found by those with compatible
devices. However, the providers of such sites may find it economically
attractive, or legally necessary for accessibility, to expand their range of
compatibility. This range should not be constrained by the domain name of the
website.

It would be far less disruptive to the Web if sites using this technology
could be independently validated (much as they can be validated for XHTML
compliance today) and their validity recorded in the popular search engines.
This would provide Web users with an easy way to find Web sites that offer
accessible resources, or of checking (in advance if necessary) that a given
URL is suitable to the requesting device. Such an approach would be in
keeping with Device Independence principles.

HTTP headers, or increasingly CC/PP metadata, are the recommended way to
communicate delivery context information. Embedding such information, even a
small part of it, in the URL merely confuses the purpose of the URL. The
purpose of a URL is to identify a resource. Having identified the resource,
the agent may request access to the resource, and as part of that request may
provide whatever information is needed to enable such access. This is the
purpose of technologies like CC/PP.

Other aspects of the proposal

The ".mobi" proposal also suggests DNS-related ways of managing mobile
users and businesses. Other commentators have made strong arguments against
such suggestions, and these comments are a matter of public record in the
ICANN lists. The DIWG does not feel the need to further comment.

Appeal

The DIWG appeals to ICANN to reject the ".mobi" proposal because of the
detrimental effect on the Web that will result. The mobile community has
better technical solutions to the problems raised, and the DIWG aims to
promote such solutions.