pro/cons of virtual hosting services

  > Heikki Suonsivu <hsu at clinet.fi> writes:
  > 
  > Daniel Karrenberg writes:
  >  > We recommend to use URLs of the form
  >  > 
  >  > 	http://www.www-provider.com/customer1/
  >  > 	http://www.www-provider.com/customer2/
  >  > 
  >  > or if customers desire www.customer.com:
  >  > 
  >  > 	http://www.customer1.com/customer1/
  >  > 	http://www.customer2.com/customer2/
  >  > 
  >  > with CNAME RRs for www.customer1.com and www.customer2.com pointing to
  >  > the real server. The latter variant provides mobility for the customer
  >  > without using extra address space.
  > 
  > This means that
  > 
  > - people can't start with a WWW hotel and then move the server to their own
  > host after they have been connected, without trouble of readvertising their
  > WWW page.  Lots of people start this way, as visibility in WWW is
  > important, but they don't know enough of Internet to take it in their
  > everyday business, and are afraid of security issues involved here.  But
  > usually they will move it, sooner or later.
  > 
  > - it is annoying to search for someone's page if one has to know who is the
  > WWW provider first.
  > 
  > - most companies seem very reluctant to allow service provider name to be
  > visible in their name, both for image reasons and the simple fact that it
  > gives too much control to service provider: The company can't simply switch
  > the service provider if they aren't pleased with the one they have been
  > using.

All this is addressed in the second soloution above, isn't it. 

  > It seems to me to be an overkill to save single IP numbers, in particular
  > when they are only consumed one per company?

Unfortunately it is not overkill.  We have seen requests for cosiderable
amounts of address space for these purposes. 

The soloution proposed works without any additional address space and
has the only drawback that the company name has to appear twice in the
URL and not even that if you just choose unique names for the first part
of the URL. 

Daniel