pro/cons of virtual hosting services

Repeats, clarifications:

Transparent change of server machine without changing URL can be
supported without using additional address space. 

http://company.com/ cannot be supported without using additional
address. 

http://company.com/company/ can be supported.  Note that the second
"company" can be different form the first as long as it is unique on the
physical server. 

Current policy is to "strongly discourage" using additional addresses. 


Responses to arguments:

There certainly are cases where this practise can be justified even when
the address space conservation is taken into account.  Strongly
discouraging does not mean forbidding. 

If this indeed consumes relatively little address space and parts of
subnets which are currently unused it is problem.  However promoting
this practise will of course create additional demand.  Some
contributions to the discussion already said "we have to do it because
*they* do it". 

http://company.com/ generally is generally no more intuitive than
http://company.com/company/.  This is a rehash of the "predictable
domain name" and "predictable mailbox name" discussion.  It only makes a
difference for very well known company names.  Promoting this practise
will give a wrong image of prestige to a "short URL". 

Promoting this practise will also put additional pressure on DNS
namespace by suggesting registrations of all sorts of entities as close
as possible to the root of the tree.  This creates even more pressures
on an already very loaded system that can only work and scale well if
organised hierarchically. 

This is not limited to one address per company since companies are
assigned subtrees of the DNS space providing for an unlimited amount of
names.  In some TLDs companies can also register arbitrarily many subtrees.


Policy:

In the absence of a specific IANA policy on the issue European Internet
registries will "strongly discourage" the use of additional address
space for virtual hosting of HTTP servers.  They will not assign
significant amounts of address space for this purpose. 


Further process: 

If this group does not consider this policy adaequate, please define another.


Daniel