WHY THE .MOBI WILL FAIL: A COMPREHENSIVE ANALYSIS

["Larry Boston" <lboston617@xxxxxxxxx>]

.Mobi Analysis

ORGANISATIONAL AND GENERAL MATTERS
1. Proposed Organisational Structure does not Reflect its Users
2. Structure is not Neutral and may not Achieve a Representative Constituency
3. Proposed Organisational Structure does not Engender Innovation

DISADVANTAGES OF THE .MOBI STLD
1. Proposal Conflates Network Connectivity with the Domain Name System
2. Use of an sTLD to Indicate 'Tailored' Content is Inappropriate
3. sTLD User Identification is Unclear, Restrictive and Conflicts with Other Proposals
4. The Benefit of Domain Registration in the Proposed sTLD is Unclear
5. sTLD Financial Justification and Registration Projections are Unproven

-------------------------------------------------------------------------


ORGANISATIONAL AND GENERAL MATTERS

1. The Proposed Organisational Structure does not Reflect its Users
-------------------------------------------------------------------

The Organisational Constituency is:
-  Investors in Mobi-JV,
-  MAG (Limited to commercial mobile content & service providers), plus
-  PAG (designated MAG members plus co-opted end user representatives).

The Served Community consists of the set of Eligible Registrants:
-  End users (Mobile content consumers and data service customers), plus
-  Mobile Content & Service Providers acting in their own right.

If this sTLD is to support only mobile Content and Service Providers acting
in their own right, then the Constituency reflects the served Community and
can be expected to respond to its needs.

However, if registrations from mobile end users are to be provided by this
Organisation, then there is a mismatch between the Constituency (providers)
and the Served Community (their customers - the End users, as well as the
providers acting in their own right).

Whilst the constituency reflects the providers, it does not reflect their
customers. In terms of influence, end user representatives are only invited
by the JV to be part of the PAG. Given that the PAG is not specified to
require unanimity in its decisions (and MAG members designate their own
members to the PAG) it would appear that any end user who registers a domain
in this sTLD has no effective Representation over the policies applied,
other than in those unspecified situations in which public comment is
elicited.


2. Structure is not Neutral and may not Achieve a Representative Constituency
-----------------------------------------------------------------------------

Mobi-JV is designed as an investment vehicle that is not neutral as it
includes three powerful Founding Members, presumably with a controlling
stake, and non-Founding Members with likely much smaller equity holdings. It
is not clear whether or not the proposed organisational design will work
successfully in practice.

For example, it is unclear what are the benefits to a Mobile Service
Provider (or Mobile Content Provider) of becoming a member of the MAG if
they cannot achieve Founding Member status in the Mobi-JV, other than
protecting their interests in setting policy guidelines.

They will have very little stake in the sTLD and yet they will have to
provide technical support in their network infrastructure and apply changes
to their content sites and applications. They may view with suspicion the
proposals and decisions of their direct competitors, who are the three
Founding Members of Mobi-JV.


3. The Proposed Organisational Structure does not Engender Innovation
---------------------------------------------------------------------

The organisational structure leaves the impression that this proposal is
intended to protect existing market positions rather than provide true
innovations, given that (for example) two of the founders of the JV are
vendors who provide operating systems for the vast majority of 'high end'
mobile phones. There is insufficient technical or operational detail in the
publicly available portion of the proposal to contradict this suspicion.


DISADVANTAGES OF THE .MOBI STLD

1. Proposal Conflates Network Connectivity with the Domain Name System
----------------------------------------------------------------------

There are many technical features that are specific to Internet devices
connected via wireless technology. Similarly, there are many technical
features of portable devices that should be considered when providing
applications and content. However, neither of these conditions is cohesive.

For example, a wide range of data rates is available depending on the
particular wireless technology used (WLAN, 3G, Bluetooth, GPRS, GSM/TDMA
'dial up' circuit-switched data). Similarly, the user's end system may be a
WLAN-connected PC, a PDA, a 'high end' or 'low end' cell phone, or even a PC
that uses a cell phone as a modem. Thus screen size or capabilities are
similarly variable.

The domain name system has traditionally not reflected network connectivity
(as to do so would conflate different levels of the network architecture).
This sTLD proposal contradicts this, and so a definite case that the sTLD is
needed must be made before such a change can be reasonably accepted.

Given that user terminals may connect to the Internet using different
technologies (sometimes concurrently), even defining what constitutes a
mobile terminal is not trivial.

There is a trend towards convergence between fixed and mobile networks, and
many people have both fixed and mobile service. It will be increasingly hard
to define an individual as a mobile or fixed user; they will be both. Thus
any mobile-specific scheme that tries to control eligibility of a user to
register a domain in terms of the kind of service they are provided will be
hard to police or even define. One could reasonably argue that the future is
network-neutral; how a correspondent is connected to the Internet does not,
directly, matter, as long as they can transfer data.


2. Use of an sTLD to Indicate 'Tailored' Content is Inappropriate
-----------------------------------------------------------------

What is Tailored Content?

Indicating availability of 'Tailored' Content is an obvious goal of this
proposal, but it is not clear what exactly the tailoring involves.

The proposal indicates that this will involve 'style guidelines' that are
mandatory on some second-level domains, a policing function with conflict
resolution procedures and enforcement. As just mentioned, there are a wide
range of devices that could be considered mobile, and these will have very
different capabilities. Choosing which one is to be specified as the
'target' to be used in the style guidelines is thus not trivial.

As the proposal concentrates on cellular data services and access to digital
content (as evidenced by the list of suggested potential Mobi-JV and MAG
members), it seems reasonable to  focus on the 'smart' cell phone segment
(digital-capable but low data rate, small screen, limited capability
terminal).

This is certainly a growing market, but is currently much smaller than
suggested in the proposal. Canalys reports that the smartphone
('voice-centric mobile device') market in the EMEA region grew between 2003
and 2004 by 83% year on year. However, the total number of these units
shipped per quarter went from 890,000 Q12003 to 1.62 million Q12004. This
just indicates that the vast majority of cell phones in use globally are
'low end' units that have restrictions to their capabilities driven purely
by price.

Whether or not 'smart' cell phone will be a user's preferred terminal for
advanced data services in the future remains an open question. As indicated
in the proposal, whilst mobile Content exists already, data service usage
(as opposed to ARPU) is low in most Countries. Growth in the 'smart' cell
phone market is higher than that of the data service usage, as some
customers buy them for other reasons (such as greater 'ease of use').

However, even with this definition of the target for which content should be
tailored, specification work is needed in order for a style guideline to be
completed. Just considering screen size alone, this varies between models fr
om a single vendor, so agreeing an appropriate style guideline for content
will be challenging, if laudable.

As each Operator currently has its own guideline based on the particular
cell phones it supports, finding a common global standard acceptable to all
providers may be protracted.

Such a style guideline is not available yet, so it would appear that
registrations for Content providers cannot go ahead until this is ready.

Options of How to Indicate Mobile Content

The goal of the proposal is to have a clear identifier that a domain name is
associated with 'tailored' content.

Within application protocols there are already mechanisms for a server to
identify a client's terminal type. For example, in HTTP requests, the query
includes a User Agent string that identifies the kind of client. This allows
the web service to tailor its content based on that string.

In detail, the web server can act on this either by using PHP/XSLT and
server side dynamic processing, or using XHTML-coded data and selecting the
style sheet to be sent based on the passed User Agent string, so triggering
the client to request appropriate content. Thus it is possible for a server
to adapt its content based on the client request; the client won't even know
this has happened.

This does not, of course, deal with a mobile user who would like to know
whether a particular web site has tailored content before making the
request.

If there is a desire to indicate mobile-tailored content by using the domain
name, then this can be done by adding a domain label that indicates such
content is available. Whilst the proposal states that having a mobile sTLD
provides such a label, this is by no means the only approach based on domain
names.

Any label could be chosen to indicate tailored content. For example, many
web sites use the left domain label 'www' to indicate that this domain name
supports a web service. It would be equally possible to use 'mobile' as the
leftmost label for any domain name associated with mobile content.

This approach could have been used already, and yet there is no clear
coordination amongst Content providers. Some sites that have dedicated
support for mobile-tailored content use 'wap' as their leftmost label,
whilst others have a separate part of their site for dedicated content, so a
URL for mobile-specific content is 'http://www.example.com/wap'. Different
Operators use different methods for their Content sites, so there is no
clear coordination within this group either.

Thus it is unclear why having an sTLD will change this situation, other than
by excluding registration of domain names for those sites that do not
conform to specified style guidelines.

There is one technical drawback with the sTLD approach to labelling domain
names associated with tailored content.

Given that cell phones have limited keyboards, auto-completion of partially
entered Content-associated domain names is likely to be common. If a typical
mobile device attempts to find tailored content associated with <site> by
first sending a DNS query for the IP address of '<site>.mobi', then given
that most web sites will not be registered in the sTLD, there may be a high
volume of failed DNS response. It is assumed that the device will then 'fall
back' to sending a DNS query for 'www.<site>.com'.

If, however, the left most domain label 'mobile' were to be used to indicate
such tailored content, then the failed DNS response would include the
enclosing domain, authoritative server name and network address. This would
allow a rapid query of other sub-domains within the same domain (for
example, one with 'www' as its left most label), with a much reduced load on
the global DNS infrastructure.

In summary, there is no obvious reason why providing an sTLD is the best
approach to indicate tailored content within domain names, and there is a
technical reason to discourage use of an sTLD for this purpose.


3. sTLD User Identification is Unclear, Restrictive and Conflicts with Other Proposals
--------------------------------------------------------------------------------------


It would seem that the goal is to identify a mobile user (or their terminal)
by use of a domain name. Note that the proposal implies that mobile end
users would be Registrants, and have domain names registered at the second
level. This is taken to mean that such registrations would be independent of
their Service Providers rather than being sub-domains of the Service
Providers.

In summary, there is no technical reason why an end user's mobility status
needs be indicated via a domain name. Existing services (such as SIP and
HTTP) already include methods for capability discovery, so there seems to be
no need to identify someone as a mobile user purely by their domain name; it
shouldn't matter to their correspondents, as the applications will handle
this automatically.

If it is considered absolutely necessary to provide indication of mobility
status (for non-technical reasons), then email or sip addresses may include
a label in the domain part of the address to indicate that it belongs to a
mobile user (for example, sip:12125551234(at)mobile.vodafone.com).

Disregarding the fact that indicating that an end user is connected to the
Internet using mobile technology is not needed, what is unclear from the
proposal is whether end user registration aims to have an Address Resource
Record within the zone for each registered domain, or is an attempt to copy
the Telname approach (from the .tel-Telnic proposal) but dedicate it only to
mobile users.

If a domain name registration were to be used, then in the former case
(using a domain name with A records) is unwise. Cellular networks use a
DHCP-like approach to IP address allocation, with some networks re-assigning
IP addresses when a cell phone loses coverage temporarily. This will require
dynamic DNS updates to keep the authoritative DNS servers for a domain
synchronised with the IP address currently assigned to the Registrant's cell
phone. As the Registrant would (under normal ICANN guidelines) be free to
select their own DNS service provider, this would generate considerable
update traffic across the Internet. It is also unclear which application
protocol would operate purely using domain names rather than specific
application layer identities (such as email addresses or SIP 'Addresses of
Record'). In summary, this use of domain names is unnecessary and
infeasible.

If the latter case (copying the Telname approach) is intended, then the
structure of the JV and MAG organizations radically under-represent the
goals of the individual Registrants, and over-emphasise the Service
Providers, who (at most) act as agents for the end user in the registration
process (as implied in the final paragraph of section A of the .mobi
proposal). If, however, the unspecified intention is that the Mobile Service
Provider would validate their Customers' registrations rather than just act
as their agent, then this will suffer from exactly the same operational
issues as the ENUM system; service provider validation can be a complex
business, and may exclude whole groups of potential Registrants if their
Service Provider does not want to be involved.

Also, the proposal does not specify that number strings will be excluded
from Registration. Not requiring such a prohibition would allow someone to
register a telephone number (such as +12125551234) as 12125551234.mobi, so
causing confusion unless the Registrant of this domain was also provided
telephone service via this E.164 number. This leaves the impression that the
proposal has not considered this scheme in detail; given that end user
registrations form a significant pool of potential domain names, this is
worrying.

As a general point, the restriction of the Telname approach to mobile users
introduces a connectivity-specific aspect to a general, network-neutral
scheme. It is unclear why such a restriction is beneficial.

If it is intended to be in competition to the proposed .tel-Telnic Registry,
then doing so would defeat the aim of having a single authoritative Telname
Registry, regardless of the (current) connectivity of the Registrants. If a
client wanted to find the contacts for someone, they would have to look in
both Registries.

In addition, given the Served Community is restricted to mobile use, it
would seem that this would force fragmentation of the information stored, as
the Registrant would (one assumes) be allowed only to put their mobile
contacts into the .mobi Registry, so their fixed contacts would have to go
into the .tel Registry. It will be increasingly hard to define a Registrant
as a mobile or fixed user; they will be both, so the restriction, when
applied to end users, will be hard to define or police.

Most importantly, if .mobi proposes to replace the .tel-Telnic system
entirely, then it will automatically exclude all non-mobile users from
registering a domain and storing their contact information there.
Technically, there is no need for such exclusion, as the Telname scheme is
designed to use standard Internet protocols; this makes no sense.

Also, with increasing Fixed/Mobile Network convergence, there is no
commercial benefit to the mobile-only restriction, and, as mentioned, it
will be difficult to decide if a potential Registrant is or is not eligible
for a .mobi domain.

The question of whether or not an sTLD is required for end user registration
remains. If the intention is to copy the Telname system from the .tel-Telnic
proposal, then the answer is yes, but it should be .tel, not .mobi, as
introducing a connectivity-based restriction makes no sense when the future
is network-neutral.


4. The Benefit of Domain Registration in the Proposed sTLD is Unclear
---------------------------------------------------------------------

The proposal suggests that the sTLD addresses potential crowding of the
domain name space. However, this assumes that there is a sizeable pool of
potential registrations that would be made in the proposed sTLD.

As mentioned above, there seems little reason for using an sTLD to identify
sites that provide 'tailored' content; using a dedicated leftmost domain
label is more appropriate, and will allow Content providers to re-use their
existing domain registrations. Thus Content Providers do not seems to
provide a large pool of potential registrations.

Mobile Operators also have existing domains in other Registries, and the
proposal does not clarify why they would need further registrations. If it
is proposed to identify 'mobile-specific' data services such as email
service, then (as for Content providers), these Operators can agree to use a
common label to indicate these services on the Internet.

Of course, the Operators are free to use any domain name on networks that
are not connected to the Internet. Thus, on purely 'internal' or 'private,
inter-operator' networks they could choose any TLD label as it would not
have an impact on the Internet.

Again, existing Operator registrations can be re-used Internet-visible
services, so there is little drive for them to register new domains under
this sTLD.

If end user registrations are to be included (by copying the Telname
approach of the .tel-Telnic proposal), then the question remains; why is
such registration needed, when there is a proposal for a network-neutral
Telname registry and personal communication information includes both mobile
and fixed contact addresses?

In summary, there seems little benefit in registering a domain in the mobile
sTLD given the justifications given in the proposal.


5. sTLD Financial Justification and Registration Projections are Unproven
-------------------------------------------------------------------------

 From the above, it is not clear that there is a sustainable business case
for the sTLD, unless Service Providers mandate that Data services and
Content must be provided by domains registered under the .mobi sTLD.

Service Providers and Content Providers could reasonably use a TLD for their
own purposes, but the number of registrations seems unlikely to reach the
estimates given in the proposal unless the financial model assumes a higher
registration charge than for most other Registries.

It might also be that registrations are not the primary motive for this
sTLD, but rather to enable mobile operators to register their subscribers at
the third level, thus ringfencing them.