Websites/Taskforce/Proposals/Domain Name Strategy

Domain Name Strategy

This strategy applies only to websites and does not intend to cover anything to do with email addresses.

Working Group

John Slater, Janet Swisher, and David Boswell

Problem

We are currently using our organizational structure as a way to set up domain names and this is presenting irrelevant information to people and diverting our message away from more important things, such as what we do and why we do it.

For example, the following are some of the organizational domains currently in use:

• mozilla.com
• mozillamessaging.com
• mozilla-europe.org*
• mozillaonline.com*
• mozilla.jp*

Note that mozilla.org is not an organizational domain -- it is the community's domain that was set up and used long before there was any Mozilla organization. It isn't the Foundation's organizational domain -- that is mozillafoundation.org that was in use briefly but has been retired.

*Affiliate URLs act as both an organization site and a local site, so there is no need to move away from using those domains. The more important issue with affiliate sites is making the content as relevant as possible by de-emphasizing the organizational information and highlighting the locale specific information.

Solution

To be able to stop using organizations as a basis for our domain name strategy, we need to develop an alternative that uses something else for its structure. There seem to be two main options:

• Structure a strategy based on product/activity: firefox.com, thunderbird.com, drumbeat.org, etc.

• Structure a strategy based on everything being a part of Mozilla: www.mozilla.org, addons.mozilla.org, foo.mozilla.org

Both options have advantages and disadvantages, but they are mutually exclusive so we need to pick one (although we can certainly maintain redirects for any URLs we want).

"One Mozilla" Strategy

To create a "One Mozilla" strategy for domain names, we propose using sub-domains for functional areas and sub-directories for products and programs (programs in the initiative sense) with some exceptions. So:

• service.mozilla.org/product

The following breaks out how this general rule applies to different types of sites.

Product and Program Sites

Sites related to the major activities backed by Mozilla organizations should use sub-directories on www.mozilla.org. The service being offered here is delivery of web pages (compared with delivery of a web app providing specific functionality).

Examples:

• www.mozilla.org/firefox
• www.mozilla.org/thunderbird
• www.mozilla.org/drumbeat

Note: Other community-backed projects such as seamonkey-project.org can show affiliation with Mozilla on their site in a number of other ways without having to change their URL structure.

Product Services Sites

Sites that exist to host services related to our products and programs should have sub-domains based on the service offered and sub-directories based on products or programs. This is the existing addons.mozilla.org model.

Examples:

• addons.mozilla.org/firefox, addons.mozilla.org/mobile, addons.mozilla.org/thunderbird, etc.

• support.mozilla.org/firefox, support.mozilla.org/mobile, support.mozilla.org/thunderbird, etc.

• nightly.mozilla.org/firefox, nightly.mozilla.org/mobile, nightly.mozilla.org/thunderbird, etc.

To help with discoverability and consistency each of these sites should have the same 'Other Application' widget in roughly the same location.

Community-wide Sites

Sites that exist to serve Mozilla as a whole and not any particular product or program should simply use a mozilla.org sub-domain.

Examples:

• air.mozilla.org
• developer.mozilla.org
• feeds.mozilla.org

Campaign Sites

Mini-sites set up for a specific campaign should be able to use whatever URL makes sense. Because these sites are usually relevant to a specific time, an archiving plan should be put in place so this content isn't abandoned.

Examples:

• firefoxflicks.com
• opentochoice.org
• operationfirefox.com

This also includes URLs that are used for redirects to other sites, such as getfirefox.com, firefox.com or firefoxcup.com. Note how firefoxcup.com now points to a blog post wrapping up the campaign.

Local Sites

There are two main URL styles being used today by local sites.

Examples:

• mozilla.country: mozilla.jp, mozilla.ro, etc.
• mozilla-country.org: mozilla-mexico.org, mozilla-russia.org, etc.

There are also a variety of other URLs in use such as bgzilla.org and mozilla.org.ua. It may make sense to make these more consistent, but there is no plan to do that now. On the other hand, having flexibility with local site URLs allows us to deal with issues relevant to different locales.

Mobile Sites

Ideally each site would have one URL which would present its content in a form optimized for any device. For complex sites though, the functionality available on mobile versions may differ greatly and switching style sheets alone may not be sufficient.

When it isn't possible to maintain a single URL for a site, we recommend adding a "m." at the beginning of the domain, such as m.foo.mozilla.org.

In the cases when we do choose to go with separate mobile URLs, once we take the time to do things the ideal way we can just redirect mobile URLs to their desktop equivalents for a seamless transition.

Other Sites

Mozilla is a big community with many people doing many things and there's no benefit to making every site fit in some structure. It is fine for sites to have unique URLs as long as they avoid organization specific domains or trademark violations.

Examples:

• accessfirefox.org
• geckozone.org
• mozillamemory.org

Localization Issues

The best practices around how to use locale codes in URLs shouldn't need to be changed due to this proposal. Sites can still use the following scheme (with the example here of Mozilla Europe's German Firefox page):

http://www.mozilla-europe.org/de/firefox/

The bigger issue with the l10n process is how will this proposal change how localizers determine what to work on? If sites are aggregated into fewer domains will more content need to be localized or would we create less cohesive experiences with partially localized sites?

Security

Moving from multiple unique domains to subdomains of a single domain, and in some cases subdirectories within that subdomain, will require changes to the security requirements that are imposed upon these websites. Specifically, all websites that are grouped within the same subdomain will be subject to the highest security requirements of any site within that subdomain.

In some cases this may mean that a site that was previously not hosting or performing critical operations, and thus had more lenient security controls, would be required to significantly enhance the security controls before it could be added as a subdirectory of a more security restrictive subdomain.

In addition, depending upon the criticality of a given group of websites within a subdomain this may result in a more strictly controlled security review process including requirements to review any new code before it is pushed live to the site.

Proposed URL Changes

Using the principles of the "One Mozilla" strategy, we suggest the following URL changes (this is just an initial batch and not comprehensive of all possible URL changes).

Existing URL	Proposed URL	Comment
mozilla.com	mozilla.org/firefox
mozillamessaging.com	mozilla.org/thunderbird
support.mozilla.com	support.mozilla.org
mobile.support.mozilla.com	support.mozilla.org/mobile
support.mozillamessaging.com	support.mozilla.org/thunderbird
air.mozilla.com	air.mozilla.org
feeds.mozilla.com	feeds.mozilla.org
input.mozilla.com	input.mozilla.org

Implementation

Once we've agreed on the plan we want to roll out these changes incrementally. Doing everything at once would be too big a project and we expect there will be things to learn about the process as we start making changes.

Technical Considerations

Webtrends Tracking: From Webtrends - You should be fine changing over from the .com domain to the .org domain, as long as the primary domain designated in the Webtrends JavaScript tag points to what you consider the primary domain. Additionally, if you plan on having both domains concurrently available, you may want to modify the JavaScript tag to include mozilla.com at a value for the this.onsitedoms=""; entry in the JavaScript include. This would then consider all traffic from mozilla.com to be considered part of the traffic on the primary domain and would not prefix entries in reports with "Offsite:"

First Round

This a proposed list of the first set of URLs to change. These should be relatively straight-forward:

• air.mozilla.com
• blog.mozilla.com
• byob.mozilla.com
• crash-stats.mozilla.com
• feeds.mozilla.com
• input.mozilla.com
• krakenbenchmark.mozilla.com
• tools.mozilla.com