| Version | 1.0 |
| Revision | 1 |
| Status | External Draft |
| Date | 25-September-2006 |
| Editors | Ronan Cremin |
This document has the status "External Draft". The lifecycle of the dotMobi Switch On! Guide is discussed in [Lifecycle]
There are no time limits associated with compliance to this document.
This is the first draft of this document. The document will be updated from time to time. DotMobi registrars will be notified when the document is updated.
The latest version of this document is available at: http://mtld.mobi/
This version can be found at http://mtld.mobi/
This document contains information proprietary to Mobile Top Level Domain Limited ("mTLD" or "dotMobi"). You may not modify, copy, reproduce, republish, upload, post, transmit, or distribute in any way any material from this document including code and software without the express, written consent of mTLD.
This document as a whole is copyrighted as a collective work, and individual works appearing on or accessible through this document are likewise subject to copyright protection. You agree to honor the copyrights in this document (including the selection, coordination and arrangement of the contents of this document) and in the works available on or through this document. In addition, trademarks and tradedress belonging to us or to third parties appear on this site or are accessible through this site. The fact that we have permitted you access to this site does not constitute authorization to reproduce such trademarks for any other purpose.
Copyright © 2006 Mobile Top Level Domain Limited
DotMobi Switch On! Guides are a set of guides governing certain technical protocols and services in the ".mobi" (dotMobi) domain. These guides are a combination of mandatory rules and optional best practices that, when applied to content and services associated with the domain, ensure a good user experience for users interacting with the domain and associated services via a mobile device. The rules mentioned in Switch On! Guide documents are specifically designed to be:
DotMobi Switch On! Guides are primarily oriented at domain registrants, since registrants are the owner of and content and services hosted at any domain, but are also useful for tool vendors and solution providers whose products and services may be involved with dotMobi.
DotMobi domain name registrants agree to implement the mandatory registrant rules listed in this document whenever they publish a web site linked to a dotMobi name on the internet. It is strongly recommended that registrants also ensure that their applications also comply with the Highly Recommended Best Practices to improve the end-user experience.
Registrars are obliged to make registrants aware of all Switch On! Guides associated with the dotMobi domain in advance of any registration taking place. Registrars must either make a copy of these documents available to the registrant or point them to the authoritative versions on the mtld.mobi web site.
The dotMobi domain is intended as a sign to users that email services associated with the domain are especially suitable for use on mobile devices. Service providers are expected to make sure that their dotMobi email service works well with mobile devices. Following the guidelines in this document will assist them in doing this.
This document is the authoritative source of rules governing public email services hosted on a dotMobi domain. A public email service is an email service that offers email accounts to the general public either as a free or paid-for service. These rules are designed to ensure a good user experience for users using dotMobi email services on their mobile devices.
The provisions in this guide apply to email systems that support RFC-822 in their interaction with other email systems where a .mobi email address is either the originator or recipient or both of an email. These best practices do not make any statement about the mailbox protocol used between the email user agent and server.
The Switch On! Email Guide covers the use case of interacting with a dotMobi email service from a mobile phone, PDA or other hand-held device. This guide specifically does not cover use cases involving desktop PCs or other device types, nor does it cover other Internet-based applications such as browsing or instant messaging.
DotMobi-specific best practices are identified as follows:
The text of a dotMobi rule or best practice.
Best practices are ranked in order of desirability.
Service providers running publicly available services on a dotMobi domain, either as a free or paid service, must make a declaration of their supported email functions in a form on the mTLD website.
In order to help users find appropriate email services to fit their needs, mTLD will provide a directory of dotMobi-compliant public email services on the mTLD website. For each service provider listed, the claimed features from the Registrant Best Practices supported by the service will be enumerated in a searchable directory. Service providers that are found not to live up to the claimed features may be removed from this directory.
Users of a dotMobi email service should be able to send email to, and receive email from any other internet email service that supports RFC-822 in its interaction with external mail systems, subject to the other best practices mentioned in this document. RFC-822 is supported by a very large number of open source and commercial email servers. Furthermore, most proprietary email systems can be configured to communicate with RFC-822 compatible email systems via a gateway.
Services should support a means for delivering a configurable selection of new emails to the user's mobile device in a timely and automated manner.
There are several techniques by which this can be achieved including push email and regular polling. In the polling paradigm, the client contacts the message store on a regular basis to find out if new emails have arraved and, if so, retrieve them to the mobile device. In the push paradigm the mail server will indicate to the mobile device the arrival or availability of new messages, and subsequently initiate delivery of these emails to the mobile device.
When choosing a technique, service providers should have a regard to the timeliness, cost and use of network bandwidth.
Services should support a means for alerting the user of the arrival at the server of all or a subset of incoming emails.
New email notification means that there is some method in place by which the email service can notify the user's mobile device that there are new emails waiting on the server. New email notification is especially valuable in the mobile context where people are likely to be on the move, and not actively monitoring their inboxes. Furthermore, this event-driven use of mobile email fits the established pattern for existing mobile messaging systems such as SMS and MMS.
When choosing a technique, service providers should have a regard to the timeliness, cost and use of network bandwidth. Service providers should also ensure that the email notification algorithm is sensitive to whether or not an email has already been pushed to the mobile device.
Services should offer a method for marking spam.
Unsolicited bulk email is serious problem with existing desktop-email services and is even more acute and intrusive on a mobile-oriented email service due to personal nature of mobile devices, and their ability to interrupt you. For this reason, services should offer spam protection tools to reduce the impact of this problem.
Services should support the configuration of criteria that support selective delivery of messages to the mobile device.
Delivery configuration allows users of the email service to configure rules to ensure that only the most relevant emails are delivered to their mobile devices, to make the best use of the mobility premium offered by a mobile email service. Delivery configuration should offer the ability to selectively restrict emails delivered to the mobile device based on attributes within messages. The following criteria should be supported:
Services should individually authenticate the senders of emails from their domain(s) and ensure that originator addresses of emails from their domain(s) match the authenticated sender.
Sending user authentication means putting in place practices to ensure that the originator of an email can be trusted. Sending user authentication has two distinct components:
Services should provide a means to allow themselves to validated as an email server for their domain(s) and should validate that the originating server for email is a valid originating server for the domain of the sender.
Sending server authentication means that a trusted party has validated that the originating server for an email message is the correct originating email server for that domain, as opposed to another server masquerading as such. Sending server authentication allows for large volumes of spam messages to be filtered without further processing, since spam messages often falsely claim to originate from legitimate email addresses but sent from a non-authoritative email server.
Services should provide alternative modes of access to mailboxes.
Services should provide a means for users to access their email in a way that does not require the mobile device. This allows users to view their email when they are unable or unwilling to use their mobile device, and also allows users to view emails that they have chosen not to have delivered to their mobile device and manage other aspects of the mobile email service.
Services should offer the option to adapt incoming emails before delivery to the mobile device in such a way as to make them work better on these devices.
Email messages that are delivered to the mobile device should be formatted such that they work well in this context. There are a number of ways in which this can be done including reformatting or removal of attachments and dividing large emails into smaller pieces.