Hi John,
--On January 6, 2010 3:03:51 PM -0500 John C Klensin <john+smtp(_at_)jck(_dot_)com>
wrote:
Such a file could also do two things that no "find the server"
mechanism can provide: (i) deal with the POP/IMAP (or really
POP/IMAP/Webmail) question on a per-user or per-environment
basis and (ii) deal with multiple mailboxes, on multiple
servers, for the same user in an efficient way. I think both
are realistically necessary today in a world where signing up
for various IM or other services carries mailboxes with them.
For that purpose, one could think of any of the approaches that
have been mentioned, even though my mentioning ACAP was intended
mostly as a bad joke and sad commentary about a lost opportunity.
ACAP is overkill for what is needed here.
Frankly something akin to XRDS/Yadis (XML configuration file on an HTTP
server) would suffice (with perhaps something like XCAP in play too).
Couple that with the new .well-known URI mechanism
(<http://tools.ietf.org/html/draft-nottingham-site-meta-05>) and finding a
service would be as simple as doing an HTTP request on the primary domain
with request-URI .well-known/XXX.
In fact I have been thinking that one option here is to register
.well-known/srv and then any of the registered SRV service types could have
meta-data stored underneath that. e.g.:
.well-known/srv/imap
.well-known/srv/submission
etc
If we define an XML schema for resources located at those URIs we can
provide great flexibility for client bootstrap configuration.
If data needs to varying on a per-user basis, then defining a simple
RESTful api to include the userid in the request would be easy.
--
Cyrus Daboo