Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)

[Cyrus Daboo]

Hi Harrie,

--On Monday, February 3, 2003 9:45 AM +0100 Harrie Hazewinkel <[EMAIL PROTECTED]> wrote:

| The main reason why I propose this is to seperate the domain from
| the user identification. I understand that by commbining the two
| you can have equal usernames int different domains. That is specified
| in section 'Other considerations'.
|
| The benefits I see (maybe should be added in the draft) is that
| - accounts in a multi domain environment can easier be managed.
| While manging an account you only care about the specific domain.
| This also allows a simpler and better distributed domain management.

The underlying account system can still separate out account information by domain when domain-in-userid is used.

| - domains can easier be distributed and re-distributed.
| When you move a virtual IMAP host to a different host, for the client
| does not change. If he was 'forced' to use the VHOST the client
| transparantly connects to this new host.

There are already a number of single front-end/multiple backend server architectures that handle moving accounts between different host machines. We also have RLOGIN and RLIST extension to do referrals to new machines.

| - customers do not see that they are in a multi-domain environment.
| (Better for marketing of services.) For them it is no difference
| and is like they have there own server.

Of course that is wrong - customers DO have to enter the domain information somewhere in their client so that the client would know what to use for VHOST. In the domain-in-userid approach its a simple matter to 'hide' the concept of the domain by simply telling the user to use their email address as their user id - I think that's a simple enough concept for most users.

| - Could enable better load-balancing/load-distribution. Not added yet,
| but I was thinking of adding 'response codes' to the response.
| The response code could indicate to a client that the virtual
| IMAP host is not available at the moment, or is moved to another
| host (temporarly or permanent). This option could facilitate
| a better load-balancing/distribution.

Again front-end/back-end systems, RLOGIN etc already allow provide this.

| This as equal of what HTTP does. HTTP introduced virtual hosting
| by creating a host-header to indicate, for instance, www.example1.com or
| www.exaple2.com on a single host. HTTP could also work with a single
| hostname and adding a directory. For instance,
| http://server.example.com/www.example1.com and
| http://server.example.com/ www.exaple2.com.
| For various reasons virtual hosting was introduced.

That's fine but IMAP already supports virtual hosting using capabilities available in its basic implementation.

|
| Yes, I understand that clients need to be changed to implement it
| where one could say little benefit. However, the benefit is on
| the server side and this feature can is backwards compatible with
| existing clients or servers.

The domain-in-userid already provides the same benefits with the added advantage of not having to change clients. I'm afraid I still don't see the benefit of VHOST. Perhaps other server vendors can explain existing problems with virtual hosting using domain-in-userid (if any)?

--
Cyrus Daboo