.mobi or .com for new mobile paysites?
 

I'm building some mobile paysites. Looking for some advice on whether there is any benefit on using .mobi rather than .com? Any opinions?

for mobile go with mobi, in a few years .mobi will be the one for mobile

That's what I've been thinking as well.

Domain wise I would make sure to always have the .com extension as no matter what becomes popular a percentage of people will always type in .com ....so ideally get the .mobi and .com

The one for mobile... You think so?

Still, it seems to me .com is the most popular one.

Not really sure where your pulling that info from?:helpme

Searching google for iphone porn I don't get any .mobi domains showing up :(

Fuck .mobi

.mobi is not getting alot of SE love, even thru mobile browsers. It can be done, but its alot more challenging then .com. If you were going to brand the hell out of the .mobi, it will have type in potential, but word of mouth is going to end up getting repeated as .com and loose its effectiveness.

just using my brain

cfnm.mobi for sale

if interested email admin (@) modesltube.com

I never understood why they picked .mobi for mobile. It is longer than .com for one. It should be .m or .mo

Unless you put your mobile site on a m.domain.com setup, .mobi is what you want.

And you brain is most certainly correct on this on. This is step one for mobile sites, and it's pretty amazing at the number of webmasters and even programs who don't seem to understan this.

It is getting expensive protecting site names, I just had to pay $14.99 a domain plus privacy of $8.99 (before 20% coupon) to renew a couple of .mobi names I am not using but I am scared to let go of.

I had to renew them at godaddy cos namecheap say they can't whois guard .mobi names. No idea why godaddy can but maybe renewals are ok and it's just new ones can't have privacy?

Do you know if Moniker has whois guard on mobi domains? I've searched their site and can't any info. Worst case I'll ask them :upsidedow

you should get both .com and .mobi

I still don't see .mobi going anywhere, mobile devices now can bring up any website on the internet on any domain extension. If I remember correctly wasn't .mobi only domains were supposed to do this? basically useless...just another extension they want you to purchase to protect your trademarks. :2 cents:

.mobi is pointless.

they would be only some use if mobiles were set for them.

as they are not, they make no difference.

I can't see mobile devices bringing up .mobi sites for searches. Should work almost the same as your computer.

Get and use both, so you don´t have to worry :thumbsup

Both will do :)

I got a few .mobi domain, it not popular as it less popular than .com and one character longer. I would go with .com if I were you.

I would also go with .com anyway.

Was my buying PornPad.mobi a waste of money? (of course the .com was long gone :)

.mobi seemed like a great idea back when it was released. It made a lot of sense to have name.mobi instead of telling surfers to "click here for the mobile version" at name.com/mobile. But webmasters ultimately decided on browser detection and redirected mobile traffic to m.name.com.

.mobi is unnecessary, even obsolete.

That is interesting since the biggest sites in the world are all doing detect & redirect using only their .com.

So how is this .mobi revolution going to happen?

Yea. The .mobi seems pretty retarded, when you can just do an "m.cnn.com" proper sub-domain for a mobile browser, while also lookup HTTP headers coming in to sniff for a mobile browser and redirect if they come to your ".com" domain.

I've never thought once of typing "something.mobi" on my phone.

** Edit: For that matter, people are still typing "www" in front of domains. I have a Nokia cell phone and when I go to try and access a web address, the fucker starts with "http://www".... WTF?

That's because domains with www. are not that same as those without. If you dont use www. but the actual domain is www. then you are redirected automatically.

Google explains it pretty well.

What do you mean by "m.domain.com" being the proper sub-domain for a mobile browser? I've been reading a lot about mobile stuff and haven't heard about that. I was intending to redirect mobile traffic on my paysites to something like domain.com/mobtour/ and then put the members area at domain.com/mobmembers/

Would that not work ok?

Thanks to everyone who has replied in this thread :thumbsup

Bump for my question above :upsidedow

Quoted for truth.:thumbsup

.com :thumbsup

http://wurfl.sourceforge.net/manifesto/

Consequences of the Introduction of a Reformatting Proxy

Symptoms of a network that has deployed a reformatting proxy are:

* Service is not receiving a device User-Agent string. In its place, one can typically find the User-Agent string of a web browser with the name of the proxy vendor somewhere.
* The UAprof x-wap-profile header is removed.
* The carefully designed appearance of a mobile site is disrupted.
* Mobile users receive a chopped-up version of a web site, instead of the mobile-optimised site originally meant for them by the site owner.
* Extra icons and/or links are added to headers and/or footers injected at the top/bottom of the content.
* Advertisement of unknown origin may be added to pages.
* Images are converted into lower quality versions of the original versions.
* Revenues drop and, upon further investigation, the reason is determined to be the introduction of a transcoding proxy.
* It is impossible to determine which version of ringtone, wallpaper, local application (such as J2ME, Symbian, etc) or other downloadable content should be provided.
* Detecting a successful download and installation of a midlet may not be possible, making it difficult to manage J2ME midlet downloads.

What can be done?

While this document represents the viewpoint of mobile developers, it is not meant to be hostile to proxy vendors and Mobile Network Operators who recognize the importance of the ecosystem and the disruption that the introduction of aggressively configured reformatters can cause to existing mobile sites and services.

To this end, developers have established guidelines that a reformatting proxy should respect, in order to avoid reformatting mobile-optimized sites.

Vendors of reformatting proxies can subscribe to the manifesto when the following two situations are verified:

* The default configuration of the vendor's proxy respects all of the rules illustrated in the Manifesto.
* Vendor will notify customers and prospective customers of the existence of this document and explain the consequences of not respecting mobile-optimised sites.

The first rule is meant to make sure that a reformatting proxy can effectively be configured to respect mobile websites. The second rule is meant to pre-empt carriers' attempts to blame proxy vendors for failure to respect mobile-optimized sites.

The recommended way to endorse the Manifesto is to add the following sentence prominently in the documentation and in the configuration files of the proxy:

"[Vendor] supports the rules established by the Mobile Developer Manifesto for Responsible Reformatting (available at: http://wurfl.sourceforge.net/manifesto/) for its default configuration."

This sentence is meant to remind MNOs of the existence of a mobile ecosystem and the necessity to respect it, a fact which may be unknown to MNO employees at different levels in the respective organizations.

Mobile Network Operators are also invited to subscribe to the Manifesto in order to express their acknowledgment of the rules contained in this manifesto.

Vendors and MNOs who sign the Manifesto will be entitled to a short statement to better qualify their position with regards to the Manifesto.
How to Avoid Reformatting Mobile-Optimised Sites

As a general rule, transcoders should err on the side of non-reformatting, meaning that a reformatting proxy should refrain from reformatting in all of those cases when a site might already be suitable for mobile.
In particular, developers request that the following rules are observed:

No USER AGENT Spoofing: under no circumstances should the original User-Agent string be removed, modified or moved to a different header.

Note: It is considered acceptable for a transcoder to perform a second HTTP fetch of site content with a spoofed HTTP request, as long as the first request has been performed with the original headers and the proxy has positively identified that the website is NOT mobile optmised

Preserve headers: under no circumstances should a transcoder modify or delete existing HTTP headers. The addition of extra x-* headers is admissible.

Recognize Mobile-Specific MIME-types and Document Type Declarations (DTDs): documents served with the following MIME types:

application/xhtml+xml,

text/vnd.wap.wml,

application/vnd.wap.xhtml+xml

and documents served with the XHTML-Basic 1.0 or XHTML-MP 1.1 DTD:

<!DOCTYPE html PUBLIC "-//OMA//DTD XHTML Mobile 1.2//EN"
"http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">

<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.1//EN"
"http://www.wapforum.org/DTD/xhtml-mobile11.dtd">

<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
"http://www.wapforum.org/DTD/xhtml-mobile10.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">


MUST be considered mobile-optimised and no transcoding should be applied

Do Not Adapt pictures of mobile-optimized sites: mobile-optimized sites should not have their graphics adapted.

30Kb Limit: pages that have a total weight of 30 kilobytes or less MUST not be adapted.

Note: An exception can be made in those cases when none of the other rules apply AND the reformatting proxy is able to positively identify devices which cannot handle 30kb of content through a Device Description Repository (DDR).
In this case a lower threshold for reformatting may be adopted. The limit cannot be lower than 15 kilobytes under any circumstances.
A further exception can be made in those cases when the reformatting proxy can positively identify the web-only nature of the site by using more sophisticated techniques, such as: detecting the use of IFRAMES and other "web-only" tags and scripting. The limit cannot be lower than 15 kilobytes under any circumstances.

Do not reformat pages that return the following HTTP header:

Cache-Control: no-transform

This also applies to the case when the header is specified through the <meta> HTTP-Equiv tag

Do not reformat pages which contain the following meta tag:

<link rel="alternate" type="text/html" media="handheld" href="[url]" title="[title]" />

The proxy should redirect the user to the [url] contained in the href attribute.

Transcoders MUST not reformat sites with URLs matching one of the following patterns:

m.*
mobile.*
wap.*
*.mobi
pda.*
avantgo.*
iphone.*
wml.*
wireless.*
xhtml.*

Note: In the spirit of erring on the side of non-reformatting, vendors are also welcome to support the following exclusion patterns, where "/" represents the first slash in the url PATH:

*/mobile/
*/iphone/
*/wireless/

Support for these extra exclusion patterns is only recommended

Whitelists are acceptable only as inclusion list to inform the reformatter of sites which would normally escape reformatting, but which are marked as reformattable through human intervention. Use of exclusion whitelists is not acceptable.

Transcoders must identify themselves using the Via header as enforced by the HTTP protocol, RFC 2616
( See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.45 )

Transcoders must send along the IP address of the device/gateway and other proxies using the X-Forwarded-For header, a de-facto standard, http://en.wikipedia.org/wiki/X-Forwarded-For

Reformatter vendors who abide by the rules above for their products' standard configuration and who agree to notify their customers of the importance of behaving sympathetically in the ecosystem are invited to sign the Manifesto.

Operators who need to deploy content reformatting solutions on their network are welcome to read this document and to derive the requirements for their systems from it.

Mobile developers are welcome to sign the Manifesto by sending an email to the editor and requesting that their signature is added.