homepage Welcome to WebmasterWorld Guest from 184.73.87.85
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor
Home / Forums Index / WebmasterWorld / Domain Names
Forum Library, Charter, Moderators: buckworks & webwork

Domain Names Forum

This 140 message thread spans 5 pages: < < 140 ( 1 2 3 [4] 5 > >     
Is "www" redundant?
Wai_Wai




msg:686678
 3:29 am on Sep 24, 2005 (gmt 0)

Hi.
Usually when we type a URL, it is in form of www.{doamin-name}.com
Why do we need to have "www"?
Do you feel "www" is redundant?
Should "www" be abolished?
Any opinion?

[edited by: Webwork at 4:22 am (utc) on Sep. 24, 2005]
[edit reason] Edited hotlink. Please read the Charter. [/edit]

 

Wai_Wai




msg:686768
 8:47 pm on Sep 30, 2005 (gmt 0)

If your site is large enough that you might ever need to use multiple-server load-sharing, then do not drop the www from your Web site's domain name. The root domain will need to be left free for use as the 'distribution' domain for the load-balancer.

Isn't it true "www." is just 1 of the subdomain?
So this implies we don't really need "www." even for this reason.
"www." itself will not make the load-sharing more successfully.

As long as we use some others, that's ok, like:

1.example.com
2.example.com
and so on

I know it is not standard, but just a strange thought to share.

microcars




msg:686769
 2:47 pm on Oct 1, 2005 (gmt 0)

has anyone else run across sites that work "fine" when you use www.example.com to get to the main page and then browse around and use their shopping cart, but if you go to the Same Site without www (just example.com) and try to do the Same Things, the shopping cart does not work and some other features, accessing some database stuff, does NOT work.

I believe this would be a case where the webmaster should have redirected all requests for EXAMPLE.COM to resolve to WWW.EXAMPLE.COM

There is a site that offers some Asian products for US purchase that I first noticed this on, the first time I went there, it was because I clicked on a LINK that had WWW in it. The next time I went there, I just typed the domain name from memory and everything seemed fine until I tried to purchase something and then it just went all wonky. I started over adding WWW and everything was fine. I sent the webmaster an email pointing this out this problem and they replied that
"it shouldn't be a problem, it should work either way".

Except of course, it didn't.

larryhatch




msg:686770
 3:09 pm on Oct 1, 2005 (gmt 0)

Aaah what a wonderful response to a potential buyer.

Slap him/her on the face with "the problem must be on your end."

Thanks for the word 'wonky' BTW, I will try to work that into my California patois.

If there is something wonky here, its the idiot who thinks he/she is running a biz
and blames customers for stuff they can't be expected to fix themselves. -Larry

webdoctor




msg:686771
 7:33 pm on Oct 1, 2005 (gmt 0)

One type of TLDs (which I think is good and should be kept) are country TLDs like .uk . However it seems a bad idea to restrict all countries to two-word only. This causes quite a few confusions (eg do you know .us is not really intended to mean United States? In fact, there's no country code for United States. A ".com" for exmaple witohut country code is intended to mean United States' websites. But it is no longer true.)

It seems that IANA disagree with you over this
[iana.org...]

gpmgroup




msg:686772
 3:57 pm on Oct 2, 2005 (gmt 0)

Theoretically where is the best place to put a 301 redirect for say domain.info to www.domain.info?

On the server hosting the www.domain.info or on a third party server with just a list of redirects?

Does it make a difference?

wormsitesAdmin




msg:686773
 4:08 pm on Oct 2, 2005 (gmt 0)

What a myopic point of view. your domain name does not refer to a host. it refers to your domain. (A collection of hosts) #*$!.domain.com refers to your server called xxx. and so on. Just because you see web servers as the center of the universe, doesn'nt mean that it is ok to drop the accepted nomenclature.

Should we drop mail.domain.com too? when I make an smtp connection my server, it knows based on my protocol right? oh yea.. i forgot. I need an MX record to do proper DNS resolution, and that requres a HOST NAME.

The purpose of the host portion of the FQDN is to properly distinguish multiple hosts. dropping it is not only stupid, but defeats a valuable orginizational unit within the DNS system.

Don't suffer from www myopia... contrary to what you may think, the internet is WAY larger than just web sites. and is used in numerous other ways, and we all want the host identifier to remain part of the FQDN.

It is considered VERY bad form not to identify your host through a FQDN by defaulting your server to your domain name alone. why not default your ftp server to it? or your soap service, or perhaps your dns server, hey while we are at it, lets just dump the hole DNS thing anyway, and go back to IPs... that will solve it...

NOT....

gpmgroup




msg:686774
 4:22 pm on Oct 2, 2005 (gmt 0)

It is considered VERY bad form not to identify your host through a FQDN by defaulting your server to your domain name alone. why not default your ftp server to it? or your soap service, or perhaps your dns server, hey while we are at it, lets just dump the hole DNS thing anyway, and go back to IPs... that will solve it...

NOT....


So when somebody [A customer perhaps] types domain.com rather than www.domain.com into their browser what should happen?

webdoctor




msg:686775
 5:34 pm on Oct 2, 2005 (gmt 0)

So when somebody [A customer perhaps] types domain.com rather than www.domain.com into their browser what should happen?

If they point their web browser at example.com (i.e. they try http://example.com/ ) then send them a 301 redirect ("moved permanently") to http://www.example.com/

Nothing wrong with that :-)

webdoctor




msg:686776
 5:40 pm on Oct 2, 2005 (gmt 0)

Theoretically where is the best place to put a 301 redirect for say domain.info to www.domain.info?
On the server hosting the www.domain.info or on a third party server with just a list of redirects?
Does it make a difference?

Are you intending to point links at http://example.com/? If not (and why would you?), you'll just be catching type-in traffic, so there's nothing to stop you having a http://example.com/robots.txt which bans all bots. Google and co will fetch the http://example.com/robots.txt file before they fetch any URIs under http://example.com/

BTW: you are not allowed to have a CNAME record at the domain level (i.e. example.com can't actually be a CNAME to somehost.anyisp.com ) - it has to resolve to an ip address. This could cause problems for those with dynamic ips.

[edited by: Webwork at 7:00 pm (utc) on Oct. 2, 2005]
[edit reason] Please stick to Example.com, which avoids hotlinking to active sites [/edit]

webdoctor




msg:686777
 5:45 pm on Oct 2, 2005 (gmt 0)

What a myopic point of view. your domain name does not refer to a host. it refers to your domain. (A collection of hosts)

Not sure this really holds water - there's nothing to stop you defining an A record in your DNS for example.com (and thereby defining a host at the domain level), but personally I'd always use this for sending a 301 redirect to visitors so they end up at www.example.com - or www2.example.com, or whichever host(s) I decide I want my webserver(s) to be...

It's a bit like those people who don't define MX records on their domains - it might just work without an MX record (many MTAs look for A records if they can't find any MXs) but that doesn't mean it's a good idea to leave MX records out of your DNS :-)

Oh, and MX records should point to a hostname (mail.example.com) not an ip address - that's another thing that people seem to screw up on...

claus




msg:686778
 5:53 pm on Oct 2, 2005 (gmt 0)

It is considered VERY bad form not to identify your host through a FQDN by defaulting your server to your domain name alone.

Perhaps by you, but not all people think alike. I personally tend to view the opposite (using only the www subdomain for the main web site) as VERY bad form.

So, people and preferences tend to differ.

I take my view from a usability viewpoint alone. All the tech of this world don't matter much relative to usability, as without users, techies would not be techies in the first place.

Besides, there are no (no) technical reasons that your website must be on the www subdomain. It does not have to be, for any of the reasons listed in this thread whatsoever.

All that is pure BS. The website can be on any host including none, and that does not stop you from having FTP / mail on other hosts, or indeed from running load balancing.

Anything you can do on a subdomain named "www" you can do on the main domain, or on a subdomain named "xyz".

webdoctor




msg:686779
 6:05 pm on Oct 2, 2005 (gmt 0)

Besides, there are no (no) technical reasons that your website must be on the www subdomain. It does not have to be, for any of the reasons listed in this thread whatsoever.
All that is pure BS. The website can be on any host including none, and that does not stop you from having FTP / mail on other hosts, or indeed from running load balancing.
Anything you can do on a subdomain named "www" you can do on the main domain, or on a subdomain named "xyz".

Sorry, but that's not true.

If you need to point www.example.com to a CNAME (i.e. example.dyndns.org - perhaps you're using a dynamic ip address) then you simply cannot do this if you want to use http://example.com as you aren't allow to define a CNAME at the domain level of your DNS

claus




msg:686780
 6:15 pm on Oct 2, 2005 (gmt 0)

No of course not, domains are not aliases, they're domains so why would you do that in the first place? On second thought - well, I guess somebody might like to do that, for some odd reason...

Anyway, you just proved me wrong. Thanks.

---

I think I have to explain why that does not change my view:

We've got a case where we can't do the same with a domain as we can with a subdomain. You can't make your domain an alias to another. Well, you can, but not with a CNAME.

Now, that is what you can't do with a domain, but it you can with a subdomain. Any subdomain. That's because a subdomain is "less important" than the main domain, so to speak.

You can have "xyz.example.com", or "www.example.com" (, or "zzz..." ) both pointing to the same content, hosted at any random place. That kind of flexibility is precisely what subdomains are for, and that's why people originally used them for different types of servers, like "ftp.example.com" or "mail.example.com"

Your main domain is your most important thing, and it should be used for your most important activity. If that activity is FTP, so be it; put a FTP server up. If it's chat, put a chat server up. If it's email; well ...

wormsitesAdmin




msg:686781
 7:29 pm on Oct 2, 2005 (gmt 0)

"Besides, there are no (no) technical reasons that your website must be on the www subdomain. It does not have to be, for any of the reasons listed in this thread whatsoever."

Notice I did not say that you had to use www. I said that not Identifying your host was very bad form. In my example, I used '#*$!' as the host name not www.

gpmgroup




msg:686782
 7:33 pm on Oct 2, 2005 (gmt 0)

Are you intending to point links at http//domain.info/? If not (and why would you?), you'll just be catching type-in traffic, so there's nothing to stop you having a http//domain.info/robots.txt which bans all bots. Google and co will fetch the http//domain.info/robots.txt file before they fetch any URIs under http//domain.info/

I want to have www.domain.info and domain.info resolve. But because Google indexes part of each under separate entries and supplemental s some entries for duplicate content (perhaps?) and after studying this thread and others I decided to redirect the domain.info to www.domain.info rather than using IIS multiple identities.

I have quite a lot of domains to do this for on an IIS server. Under IIS I have to treat (permanent) redirect(s) as a separate site in the Management Console.

I can do multiple redirects under one entry

www.longname.info
longname.info
name.info

but www.name.info the site pointing physically to the files in the directory on the server has to be in a separate entry.

This means hundreds of extra entries :( Now I can place these redirects on the server together with the files or I can place the redirects on a different server to point back to the server with the files on.

I was wondering if there were any advantages or implications by choosing one way over the other?

[edited by: Webwork at 11:36 pm (utc) on Oct. 2, 2005]
[edit reason] Delinked to active site [/edit]

webdoctor




msg:686783
 9:07 pm on Oct 2, 2005 (gmt 0)

This means hundreds of extra entries :( Now I can place these redirects on the server together with the files or I can place the redirects on a different server to point back to the server with the files on.

I was wondering if there were any advantages or implications by choosing one way over the other?

Err... how about you save yourself time and money by arranging some cheap linux hosting for your example.com (leave your www.example.com where it is), you'd simply stick this in your .htaccess:

RewriteEngine On
RewriteBase /
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301]

<opinion type="outspoken"> BTW the kind of inflexibility you describe is why I hate IIS :-) </opinion>

Heck, stickymail me and I'll host your example.com -> www.example.com redirections for you ;-)

webdoctor




msg:686784
 9:19 pm on Oct 2, 2005 (gmt 0)

No of course not, domains are not aliases, they're domains so why would you do that in the first place? On second thought - well, I guess somebody might like to do that, for some odd reason...

Well this "rule" actually seems completely arbitrary to me. IMHO some of these things got written into RFCs way before DDNS was even on the radar.

Anyway, you just proved me wrong. Thanks.

Ouch. Can I buy you a beer to make up? :-)

john_k




msg:686785
 2:04 am on Oct 3, 2005 (gmt 0)

Is "www" redundant? ... Should "www" be abolished?

Even with the followup statements/questions in the opening post of this thread, this is a question fragment (redundant with what?) that also lacks any context. The result is a rambling thread whereby every poster is filling in the missing parts according to their experience and frame of reference and then answering a slightly different question. This is being compounded when posts are debated because they were answering a different interpretation of the question.

So, here are a few of the possible versions of this question:
- Is "www" redundant when you are typing a URL into a browser address bar?
- Is "www" redundant when you are coding a link from one web page to another?
- Is "www" redundant when you also specify "http://"? Did you mean when you type it in, when you print it in an ad, when you code a link, or when you say in a radio spot?
- Is "www" redundant if the print ad labels it as a web address?
- Is "www" redundant when your DNS server is responding to lookup requests?
- Is "www" redundant because you are using the internet and everyone knows that Internet and World Wide Web are the exact same thing? (just kidding)
- Is "www" redundant ... in several other variations that I've likely missed?

And one (apparently) popular interpretation of the question fragment is:
Should we entirely abolish the use of hostnames and push websites that still use them into second class status?

And one other interpretation I see is that the question is asking whether or not "www.example.com" should resolve to a page when you really want people going to "example.com".

Now, add in the fact that there are three specific and critical points at which a hostname comes into play. They are:
- At the browser (by typing or clicking)
- At the DNS server
- At the web server (and related load-balancing or other supporting systems)

Throw in the issues with SERPs, and we have a mess.

These are just some observations. (I'll add other comments in a separate post)

john_k




msg:686786
 2:07 am on Oct 3, 2005 (gmt 0)

In this post, I am talking about the relevancy of hostnames in general and not about the specific hostname of "www". And in case it is not clear, by hostname I am talking about the highest level that can refer to a specific server (host). Example: hostname.example.com

Here is a snippet from RFC 1736 ( [ietf.org...] ) which is titled "Functional Recommendations for Internet Resource Locators:"
2.2.2 (last paragraph of the section)
Users are major producers of resource locators. A user constructing
one to share with others is responsible for conformance with locator
standards. Sometimes a user composes a resource locator based on an
educated guess and submits it to client software with the intent of
establishing access. Such a user is a producer in a sense, but if
the locator is purely for personal consumption the user is not bound
by the requirements. In fact, some client software may offer as a
service to translate abbreviated, non-conformant locators entered by
users into successful access instructions or into conformant locators
(e.g., by adding a domain name to an unqualified hostname)

So this RFC supports the posts clamoring for browsers to allow you to type in a URL without wasting all of your keyboard's limited supply of "w"s.

However, here is a snippet from RFC 1738 ( [ietf.org...] ) which is titled "Uniform Resource Locators (URL)". In fairly straight forward language (for an RFC anyway) it states that an HTTP URL must include the name of a host that resolves to a specific IP address. In fact, it is the only part of a URL that is not optional:
3.1. Common Internet Scheme Syntax

While the syntax for the rest of the URL may vary depending on the
particular scheme selected, URL schemes that involve the direct use
of an IP-based protocol to a specified host on the Internet use a
common syntax for the scheme-specific data:

//<user>:<password>@<host>:<port>/<url-path>

Some or all of the parts "<user>:<password>@", ":<password>",
":<port>", and "/<url-path>" may be excluded.

<snip>

host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by
".". Fully qualified domain names take the form as described
in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
[5]: a sequence of domain labels separated by ".", each domain
label starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses.

3.2. FTP
<snip>

3.3. HTTP

The HTTP URL scheme is used to designate Internet resources
accessible using HTTP (HyperText Transfer Protocol).

The HTTP protocol is specified elsewhere. This specification only
describes the syntax of HTTP URLs.

An HTTP URL takes the form:

[<host>:<port>...]

where <host> and <port> are as described in Section 3.1. If :<port>
is omitted, the port defaults to 80. No user name or password is
allowed. <path> is an HTTP selector, and <searchpart> is a query
string. The <path> is optional, as is the <searchpart> and its
preceding "?". If neither <path> nor <searchpart> is present, the "/"
may also be omitted.

Within the <path> and <searchpart> components, "/", ";", "?" are
reserved. The "/" character may be used within HTTP to designate a
hierarchical structure.

The thing to take away from that is that <host> MUST RESOLVE TO AN IP address. Now, as has been repeatedly pointed out in this thread, and as is commonly done by many websites, you can utilize your DNS to indicate a default host server.

What is not being said is that when you do this, you are relying on a DNS A record that indicates the default host IP address for the domain, regardless of the protocol.

So not indicating a specific hostname with your URL makes this a possible future point of failure.

Do you feel lucky?

Digital Freelancer




msg:686787
 2:58 am on Oct 3, 2005 (gmt 0)

I think "www" is important. For linking especially. Many users always link to "www" version.

Non-net savy users think "www" is mandatory. They think
it has to go with anything net related.

Matt Ermatix




msg:686788
 6:43 am on Oct 3, 2005 (gmt 0)

From a purely commercial point of view, I think it is important to remember who you are targeting your site at. In particular if you are trying to make money and your users donít have a huge knowledge of the web (but you use it to deliver your products), then stick the most recognized method (and at the moment that is www)

I agree it is redundant in a lot of ways, but I wonít be trying to set a trend at the expense of business income.

If your site is mainly aimed at IT personnel, web masters or regular internet users then dropping the www could keep you current and with-the-times.

The only other time to think about keeping the www is if you donít use .com. Eg. example.za may not be recognised as a website as easily as www.example.za

Hester




msg:686789
 9:04 am on Oct 3, 2005 (gmt 0)

OK, some great points here in this fascinating thread. I'd like to ask the following questions from a user's point of view:

1) Which is easier to type in?

a) www.really-long-example-up-to-64-characters-are-allowed-i-believe.com

b) really-long-example-up-to-64-characters-are-allowed-i-believe.com

2) Which looks like a website and which doesn't?

a) www.example.com
b) example.com
c) www.example.org, .net etc.

3) If you heard an announcer say the following, which would appear to reference a website?

a) "Go to double-u double-u double-u example dot com for more information"

b) "Go to example dot com for more information"

c) "Visit our website - just enter example into the browser's address bar."

Here's my take on the possible answers:

1) B is always going to be easier to type in. There are less characters. If you're in an emergency, you don't want to waste time typing extra letters. (Though the example I gave was over the top.) The internet is all about speed. Kids want information as fast as they can get it.

By the way, I make use of 'Keywords' a lot myself, as supported by Opera and Firefox. I assign a word or number to a bookmark, then all I have to do is type that in. For instance typing w then m then w always takes me straight to this forum. (Had to write that out longwise - the forum replaced my keyword with the full title of this site!)

2) To me, the examples all look like websites. Although I wished for the TLD to disappear as well, I think I was being foolish. To me, without the "www." you still know "example.com" is a website because, well what else could it be? And if typing "example.com" in to the browser works, then great. The problem obviously lies in when it doesn't work because "www." or another prefix is required by the server.

3) Answer C is pushing it. I'd say, like question 2, that either www.example.com or example.com both sound perfect to me. They clearly denote a website.

ruserious




msg:686790
 12:13 pm on Oct 4, 2005 (gmt 0)

> 1) Which is easier to type in?
> a)www.really-long-example-up-to-64-characters-are-allowed-i-believe.com
>
>b)really-long-example-up-to-64-characters-are-allowed-i-believe.com

Perfect example why it's unnecessary to dump the www. It's just not going to make a significant difference.

Also: you completely missed the part of the discussion that detailed why the main hostname you use does NOT have to equal what users have to type in (you can do redirects serverside; and browsers do their part in supporting what you are trying to do).

> 2) Which looks like a website and which doesn't?
> a) www.example.com
> b) example.com
> c) www.example.org, .net etc.

All of those look like hostnames and might be used for all kinds of services (smtp, nntp, imap, ...). The ones that start with www. make it clear that they are likely running a web-server at those addresses.

> 3) If you heard an announcer say the following, which
> would appear to reference a website?
> a) "Go to double-u double-u double-u example dot com
> for more information"
> b) "Go to example dot com for more information"
> c) "Visit our website - just enter example into the
> browser's address bar."

a and b make sense. c is just weird. Sounds like someone is trying to re-invent AOL's walled gardens which failed for very obvious reasons.

As has been pointed out before, using www. is optional. If you don't want to, then don't. There are valid reasons why it can make sense - but it was never _required_ anyway.

I wonder why people are not as eager to get rid of real-word addresses. You know, just do away with streets, and numbers, and apartments numbers, and cities, countries and zipcodes. Everybody on earth (all 6 [?] billion people) should just have one single, concise, short and easily rememberable string for identifying him. Then we could have a big database at the post offices and finally we could get rid of all that address nonsense. Who's in for that...?

MultiMan




msg:686791
 2:50 pm on Oct 4, 2005 (gmt 0)

I wonder why people are not as eager to get rid of real-word addresses. You know, just do away with streets, and numbers, and apartments numbers, and cities, countries and zipcodes. Everybody on earth (all 6 [?] billion people) should just have one single, concise, short and easily rememberable string for identifying him. Then we could have a big database at the post offices and finally we could get rid of all that address nonsense. Who's in for that...?

A point well-made with truly hilarious sarcasm! :)

twist




msg:686792
 6:19 pm on Oct 4, 2005 (gmt 0)

I wonder why people are not as eager to get rid of real-word addresses. You know, just do away with streets, and numbers, and apartments numbers, and cities, countries and zipcodes. Everybody on earth (all 6 [?] billion people) should just have one single, concise, short and easily rememberable string for identifying him. Then we could have a big database at the post offices and finally we could get rid of all that address nonsense. Who's in for that...?

If we got rid of all the imaginary lines on maps that make up countries we wouldn't have any reason to go to war, then what would we do to keep the populace down?

If we stopped using names for streets and started using a sensible system for layouts of cities, then people from out of town wouldn't spend hours driving around in circles and getting in accidents trying to find a place. It would really cut into auto body shop's profits. I don't want to live in a world with less accidents, fewer cold pizzas, and on time deliveries. Never mind the emergency vehicles, it's their job to memorize every single street address in a town, sure they might miss a turn once in awhile, but hey, it's not like its going to kill someone to wait a little longer for an ambulance.

I also like the fact that five other people that use my bank, also share my full name, it makes me feel like I am in my own little community. Besides, if we used any type of numbering system, the 1/8 of the world that is christian would be upset because that would be the mark of the beast. It's not like we can get rid of religion. Without religion people couldn't blindly hate or condemn people they don't know and have never met. What kind of world would that be, the idea is ludacris.

Hester




msg:686793
 8:48 am on Oct 5, 2005 (gmt 0)

Actually that's something I thought of when email addresses became popular. How come you can receive email using a single line when postal mail requires several lines of address? Why not something like joe.bloggs@12sunnyroad.york.yo1.e23?

Back to the main topic. I looked around for company products with web addresses on. I made a list of the first ten I found, and every one used "www.". Two even added "http://". From this I can conclude that we need to keep the w's. Not for the server, but for marketing purposes.

The exception is perhaps when it's part of the company name. Doesn't AOL advertise as Aol.com? Not sure if their literature adds the w's or not to the address elsewhere.

I just wish they'd chosen a single-syllable letter to triplicate at the start of common web addresses. Eg: aaa.example.com. Too late to change now I guess. :)

claus




msg:686794
 9:51 pm on Oct 5, 2005 (gmt 0)

not indicating a specific hostname with your URL makes this a possible future point of failure.

I don't really like when something goes wrong with my web sites, but I've never heard about this before, so could you elaborate a little on that john_k?

How possible? What kind of failure, exactly? What exactly will not happen? Who will perceive that failure as being a failure? What will it take to make this happen? What will likely consequences be? Could you take precautions against this without adding a subdomain? Would that be hard to do/expensive/impossible?

As I read it, apart form that sentence, what you posted (the RFC quotes) does not offer one single word supporting the use of the www subdomain or omitting it. And everything that's not proven impossible is possible - not always likely, but still possible. That's why I'm so curious as to exactly what this "point of failure" implies.

StupidScript




msg:686795
 11:23 pm on Oct 5, 2005 (gmt 0)

(From john_k's first RFC quote)
In fact, some client software may offer as a
service to translate abbreviated, non-conformant locators entered by users into successful access instructions or into conformant locators (e.g., by adding a domain name to an unqualified hostname)

i.e. you type in "example" and the client software sends it (translates it) into a conforming locator like "http://www.example.com"

What I haven't seen here is the old-fashioned term "machine name" that explains what the "www" is. There have been some great explanations of how the "machine name" is used, but I haven't seen that nomenclature.

A basic "conformant locator" includes:

1) The protocol to use ("http", "ftp", "mailto")
2) A separator ("://" or ":" for mail)
3) A machine name ("www", "ftp", "mail", etc.)
4) A separator (".")
5) A host name (the "domain" name)
6) A separator ("."), and
7) A domain indicator ("com", "net", etc.)

Items 3-7 constitute the "host".

Of these, which ones does anyone want their client software to assume? The protocol? The machine name? The separator?

Assumption/translation only works in our simple, pre-historic times. And likely only with IPv4.

Let's take the example of a web/network setup in the not-too-distant IPv6 future, shall we?

My family has a setup that handles all of our needs using many IP-enabled machines. It serves web pages (1 IP/1 machine), handles text messaging to our cell phones and other devices like wristwatches and automobile interfaces (12 IPs/1 machine), voice and video conferencing (6 IPs/1 machine), taps into my refrigerator (1 IP/1 machine) and deals with inventory and shopping lists, distributes our mail (2 IPs/1 machine), manages our GPS services (3 IPs/1 machine), manages our media consumption demands (7 IPs/3 machines), controls the temperature (2 IPs/1 machine) and maintenance functions of our house (5 IPs/3 machines), and many other things.

Each machine has its own "machine name", whether it's a computer as we now know it or a watch or a car or a refrigerator.

Within those server applications/machines, our web pages might be served to a client requesting "http://www.familyname.nom.uk". Or we might set it up to use "http://web.familyname.nom.uk" and use our "www" machine for our own personal surfing needs.

Typing in "familyname" would subject the request to the whims of the client software and force it to either translate my request or perform a search for it or fail to resolve it. If the client did a name translation, what would it be? Likely "http://www.familyname.com" ... which is clearly incorrect.

It's like living at "123 Elm Avenue" and having someone send mail to "123 Elm". Is that "Avenue", "Road", "Street", "Place", or what? Probably, the USPS would send it to "Street" ... which is the wrong guess, but what did they have to work with? They cannot know the sender's intentions.

So, "future failure" seems to me to mean "assumptions based on todays simplified needs are potential failure points in the much more complex future".

IMHO. (Think big ... we're running out of IPv4 addresses already and we've only just begun!)

StupidScript




msg:686796
 2:22 am on Oct 6, 2005 (gmt 0)

Essentially ... ahem ...

There was a time when humans could relay a message to the exact person they were speaking to by simply referring to "Og" ... or "Thub" ... or "Stinkfinger" ...

We are living those times now, my friends, within the scope of the Internet's lifespan.

All we need to do is type "example" in our web browser's location bar and our request is delivered to http://example.com (the "www" is, in fact, optional for the most part), which resolves to the proper machine for serving web pages using the HyperText Transfer Protocol.

Bingo.

Who cares if the browser is "figuring it out" for us?
We're there.

Well ... Og and Thub and Stinkfinger are long-dead. The time will come, shortly, when we need first names, too.

First names? No problem ... right? Wrong.

"I'm looking for a man named Smith."

is equivalent, in locator terms, to:

smith.man

May we (the browser) assume Smith lives in Brooklyn, NY, USA? Well then, okay ... we will.

You see my point ...

"I'm looking for a man named Smith with the first name Sam."

sam.smith.man

Much better. Now we know:

- Look only in the "man" database (cuts resource abuse)
- Look only for the last name "smith"
- And look, specifically for the "smith" "man" named "sam"

We will end up with something more like:

public.www.sam.smith.nom-m.london-4.uk

... but the brilliance currently driving our locator system will grow to simplify that. Like ZIP codes did.

Like the URL system did when it supplanted the <protocol>://<ipaddress>:<port>/<file>.<extension> system.

So ... in our simplicity, we do not, in fact, need the "www" machine name when the address is typed into what we refer to as a "web browser". The software will do a little magic, according to its taste, and we will get to one of the few villages on the network where the singular identity we seek resides.

We will need the first names ... sooner or later. We will map them to machines, and directories, and handlers ... as we do now.

IMHO: Keep the "www" to prepare for the future.

john_k




msg:686797
 5:22 am on Oct 7, 2005 (gmt 0)

I don't really like when something goes wrong with my web sites, but I've never heard about this before, so could you elaborate a little on that john_k?

How possible? What kind of failure, exactly? What exactly will not happen? Who will perceive that failure as being a failure? What will it take to make this happen? What will likely consequences be? Could you take precautions against this without adding a subdomain? Would that be hard to do/expensive/impossible?

As I read it, apart form that sentence, what you posted (the RFC quotes) does not offer one single word supporting the use of the www subdomain or omitting it. And everything that's not proven impossible is possible - not always likely, but still possible. That's why I'm so curious as to exactly what this "point of failure" implies.

If you re-read the post, you will see I was referring to the practice of relying upon your DNS to jump to the conclustion that requests for "example.com", regardless of protocol, are seeking out your webserver.

What is not being said is that when you do this, you are relying on a DNS A record that indicates the default host IP address for the domain, regardless of the protocol.

So not indicating a specific hostname with your URL makes this a possible future point of failure.

As I stated in my first post in this thread, somewhere near the beginning of this thing, and as a few others have observed, web sites will not always be the most popular use for a domain name. Other types of services will emerge. It is not unreasonable to expect that a new type of service could emerge at some time and overtake website useage in 2 to 3 years. Regardless, when/if it is no longer "wise" (implies that it is now) for your DNS to assume that inbound packets are for your website, then what will you do?

Note that I am not saying that websites will drop off the face of the earth. On the contrary, and at the heart of the problem, is the fact that they will remain important. For people with large numbers of inbound links to their websites, it will be impractical for them to contact all of the owners of those links and ask them to change them. At best, they will be stuck routing some traffic to the wrong servers.

So my point is that this is one possible (and realistic) outcome. Since the standard is to include a hostname, and since it is realistically possible that the practice of excluding it will cause grief down the road, then why exclude it in your marketing?

(Again, I am NOT talking about what someone types into their browser's address bar. I AM talking about how you market your URL, be it online, print, or other media, as well as how your system handles requests.)

Wai_Wai




msg:686798
 10:03 am on Oct 7, 2005 (gmt 0)


In fact, there's no country code for United States. A ".com" for exmaple witohut country code is intended to mean United States' websites. But it is no longer true.)

It seems that IANA disagree with you over this
[iana.org...]

.us is the Internet country code top-level domain (ccTLD) for the United States of America, established in 1985. Registrants of .us domains must be United States citizens, residents, or organizations, or a foreign entity with a presence in the United States.

Most registrants in the country have registered for .com, .net, .org and other gTLDs, rather than .us, which has traditionally only been used by some state governments. In particular, the domains .gov and .mil have been reserved for US usage. Probably the most widely used .us site is the free hosting site imageshack.us.

However, from April 2002, second-level domains became available for commercial use. Previously, registrants could only register third-level domains or higher.

Now the .us domain is administered by NeuStar Inc..

[Source is from Wikipedia. Sorry for not posting the link because it seems to be not allowed here!]

This 140 message thread spans 5 pages: < < 140 ( 1 2 3 [4] 5 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Domain Names
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved