Re: Thoughts on top-level domains, esp. .mobi

On Wednesday, May 5, 2004, 10:20:57 PM, Tim wrote:


TBL> In writing up some problems as I see them with the proposed .mobi top
TBL> level domain, I found i had half the document full of general reasons
TBL> why new domains are a bad idea, which would apply to many if not all of
TBL> the new proposals, and the other half specific problems with .mobi.

TBL> The writeup is at http://www.w3.org/DesignIssues/TLD

TBL> Comments welcome -- I intend to send it to the formal comment list next
TBL> week.
TBL> This is a personal view only.  It is not a W3c view.  I would recommend
TBL> that others also send their feelings to the official list.


I have a few comments:

Comments on TLD in general

>> In practice, for most domain name owners, the part between the
>> "www" and the top level domain is their brand, or their name. It is
>> something they need to protect.

This is very true, and in addition is a positive motivator for IRIs
since the brand name is not, worldwide, limited only to ascii
characters.

Although trademark name clashes also exist - would apple.music go to
the record company or the computer manufacturer, to take a topical
example?

In an international setting there is greater potential for collision -
someone wanting a tld for magazines, .maga, might find that a French
organization had already claimed it for shops (magasin)

>> The market for second-level domains is a market for a limited
>> resource. After an unstable period when the first come first served
>> system was in play and greedy squatters grabbed domains simply for
>> speculation, it has now settled down.

As you have made the point earlier about the free for all, speculation
and holding to ransom caused by unallocated names being first-come
first-served, it is tempting to echo that argument here in that new
tld are carving off chunks of new space to speculate on.

You sort of say this in

>> The first effect is a little like printing more money. The value of
>> one's original registration drops.

but perhaps it could be more explicit.

We have already seen the speculation on Tuvalu (.tv, used for
television related sites) and, in some Scandinavian countries, on
Nunavut (.nu, which has the same value as .new would have in English).
So far there has been no speculation on Turkemenistan (.tm)

These new tld create a similar hostage-taking, speculation-producing
environment. Maybe I can get rich quickly by creating .drink, pre
registering coca-cola.drink and pepsi-cola.drink and selling these to
the 'natural' owners while auctioning cola.drink to the highest bidder.

Others have made this 'print money' point also, see
http://forum.icann.org/lists/stld-rfp-mobi/msg00024.html


Comments on .mobi in particular

>> The .mobi domain is described as being for the use of a community.
>> To quote the proposal, the target community for the .mobi TLD is:

>>    * Individual and business consumers of mobile devices,services
>>      and applications
>>    * Mobile content and service providers
>>    * Mobile operators
>>    * Mobile device manufacturers and vendors
>>    * IT technology and software vendors who serve the mobile
>>      community

>> This is in fact a mixture of reasons. It sounds as though there is
>> a use for ".mobi" when the provider of a service intends it to be
>> for the benefit of mobile users. There appears to be a desire to
>> limit the use of ".mobi" to companies -- perhaps those in the
>> group.

I agree that this is not a single community; one might read it as
"Individual (in theory) and (large, corporate) business consumers
of ... "

Others have noticed this also:
http://forum.icann.org/lists/stld-rfp-mobi/msg00021.html
http://forum.icann.org/lists/stld-rfp-mobi/msg00008.html

with the perceptive comment:

> The whole purpose of an sTLD is defeated with this proposal because
> the real community to be served is not represented at all.

> It would make much more sense for Mobi JV to apply for .GSMA since
> its sole community is the GSM Association.

>> This domain will have a drastically detrimental effect on the Web.
>> By partitioning the HTTP information space into parts designed for
>> access from mobile access and parts designed (presumably) not for
>> such access, an essential property of the Web is destroyed.

No comment beyond strong agreement.

>> For a time, many Web site designers did not see the necessity for
>> such device independence, and indicated that their site was "best
>> viewed using screen set to 800x600". Theose Web sites now look
>> terrible on a phone or, for that matter, on a much larger screen.

This is well put.  Suggest in the next section clearly distinguishing
between client-side and server-side styling.

>> By contrast, many Web sites which use style sheets appropriately
>> can look very good on a very wide range of screen sizes.

Good, but implies that a single "one size fits all (equally badly)"
presentation is the only possible result of client-side styling (see
below for possible fixes).


>> It is true that to to optimize the use of any device, an awareness
>> on the part of the server allows it to customize the content and
>> the whole layout of a site. However, the domain name is perhaps the
>> worst possible way of communicating information about the device.
>> Devices vary in many ways, including:

The first sentence is good and looks as if it is going to lead on
from 'one stylesheet for all' to 'customization is possible, here is
how". But instead it goes off into ".mobi does not define a device
profile" and only comes back to flexible styling after a few
paragraphs. I feel that this should be rearranged to keep all the
styling-related arguments together.

I strongly suggest adding, either here or right after the paragraph
about CC/PP,

  Use of the CSS @media construct allows different styles suitable for
  desktops (@media screen) and mobile handheld devices (@media
  handheld). CSS media queries, the client-side complement to
  server-side CC/PP, gives finer grained stylistic control.

CC/PP allows a client to give a server delivery context information to help with
server-side styling and content filtering; CSS @media and media
queries is the necessary client-side component of that where the
content author can specify a range of stylings appropriate to
different devices. These two approaches can of course be used
together. The client-side approach is sometimes the only one possible,
for example in p2p or messaging applications when there is no server,
or the server is a micro-server on a phone and not capable of content
transformation and filtering.

I do suggest that the term 'delivery context', as defined in Device
Independence Principles, be used in the discussion of server-side
styling.

The string 'WAP' is not found on the page. Did you consider adding this
example of the failure of a partitioned information space? I
appreciate that this might not have been called out because of a worry
it would do more harm than good to the argument. i mention it here in
case the omission was accidental.

References to the various technologies mentioned should be added at
the end. Here are the ones I mentioned:

CSS2 Specification,
W3C Recommendation 12 May 1998
chapter 7 Media types
http://www.w3.org/TR/CSS2/media.html

Device Independence Principles,
W3C Working Group Note 01 September 2003
http://www.w3.org/TR/di-princ/

Media Queries,
W3C Candidate Recommendation  8 July 2002
http://www.w3.org/TR/css3-mediaqueries
  
-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Monday, 10 May 2004 23:10:36 UTC