On Thu, 7 Jan 2010, Cyrus Daboo wrote:
ACAP is overkill for what is needed here.
Yes.
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.
You need a layer of indirection between the mail domain and the web
server, e.g. SRV or NAPTR, to accommodate sites like cam.ac.uk which do
not have a web server on their zone apex, or customers who delegate email
service to a service provider.
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
MUA configuration should be in one file. If you split it up by protocol
then it is too easy to perpetuate problems with POP vs. IMAP
prioritization.
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.
The MUA doesn't have a userid at this point: it only knows an email
address.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.