Should a mobile website have its own sub domain?

I'm thinking about doing a mobile version of our website. Some people says开发者_运维知识库 it's a good idea to let mobile websites have their own domain name (ie m.domainname.com) as oppose to the same app handling both mobile and desktop requests. What are some pros and cons of these two approaches?

My technology stack is ASP.NET MVC2 + MySQL.

This is more a strategic issue for your business. A lot of the larger vendors seem to use a suffix because it allows the end browser to be sure it is viewing the correct version of the site.

So for example, if I am using my smartphone to view a site - sometimes I will be redirected to the subdomain because there is code that determines through the session exactly what browser (and version) I am running. The redirect will then cause me to go to the new site. A problem arises when a situation arises that the code wasn't written to deal with. If I connected with a bespoke browser - how would the site determine that I was on a smartphone? Sure there is additional metadata that can be gathered - but what happens if my bespoke browse purposefully conceals that information (perhaps because it is not designed to view general web pages)?

The subdomain prefix gives the consumer a choice. They can view the normal site in their smartphone - and risk that the web pages may render incorrectly, etc.. Or alternatively they can enter the subdomain and view the site using the correct CSS for a smaller screen, alternatives to flash, and other technologies that smartphones require to view a site correctly.

If you want to play it safe - use the subdomain approach like we do. The big companies all seem to adapt this approach so why try to go against the grain. Remember - 99.99% of development is just doing something someone else has done before you (more or less) so learn from their mistakes.