On Monday, February 3, 2003, at 05:28 PM, Cyrus Daboo wrote:
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.
This architectures I can immagine, but that is different.
| - 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.
I am here speaking of having a different/multiple front-end, handling all
a specific set of domains. With VHOST and doing VHOST forwarding (if I may
call it that way) you move a complete host whether it is a virtual host is
then not important.
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.
That depends. If an IMAP client is to discover the domain from its server settings it is not needed.
| - 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.
I cannot find 'RLOGIN' in some RFC or Internet-draft related to IMAP, but I assume you mean RFC 2193 (referrals) correct?? Just a question to IMAP client vendors. Do all clients understand referrals??
| 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.
I don't see this as such, maybe I am missing something. I only understand you do need to embed the domain in the user id of LOGIN or add it to the AUTHENTICATE command. That is not what I think of virtual hosting.
|| 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)?
I agree, the VHOST command has no extreem benefit, but some environments it would do, IMHO. The referal method is at an command oriented level and a client could potentially start jumpiong between the originated server and the referred server. The VHOST problem would solve this by telling the complete server is somewhere else in contrary to the per-mailbox approach. regards, Harrie ------------------------------------------------------------------ Author of MOD-SNMP, enabling SNMP management of Apache HTTP server
