- From: Chris Lilley <chris@w3.org>
- Date: Tue, 11 May 2004 05:09:50 +0200
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: 'www-tag@w3.org' <www-tag@w3.org>
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