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.
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.
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.
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.
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.
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.
[1] http://www.w3.org/TR/2003/NOTE-di-princ-20030901/#DIP-2
[2] http://www.w3.org/TR/2003/NOTE-di-princ-20030901/#section-DeliveryPrinciples
[3] http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/