Hi,
On Jun 19, 2008, at 9:58 PM, Simon Wistow wrote:
On Wed, Jun 18, 2008 at 04:52:19PM -0700, Blaine Cook said:
Steve Ivy and I kicked around some ideas last week. They're
recorded on the
DiSo project blog here: http://diso-project.org/wiki/messaging-
brainstorming
I've only skimmed through the brainstorming doc and apologies if this
has already been discussed before and I've not found the prior
discussions but ...
We already have a discovery mechanism in place for web and
(especially)
mail endpoints - it's DNS and it's well understood and battle
proven to
work.
It's extensible too - see SPF and also RFCs 1712 and 1876 which
describe
how to provide location information in your zone file.
So instead of
<!-- Messaging 1.0 Endpoint Definition -->
<Service priority="10">
<Type>http://xrdstype.net/messaging/1.0/server</Type>
<URI simple:httpMethod="GET">http://
endpoint.mysocialinbox.com</URI>
<LocalID>http://myopenid.example.com</LocalID>
</Service>
why not something like (completely off the top of my head and stolen
liberally from SPF)
example.org. IN TXT "v=messaging1.0 \
server=http://endpoint.mysocialinbox.com \
local-id=http://myopenid.example.com";
or
example.org. MSG endpoint.mysocialinbox.com \
local-id=http://myopenid.example.com
Or, to put it another way, why reinvent everything again over HTTP.
Why
have your messaging endpoint rely on your web server (unless of course
the goal is to reinvent messaging over HTTP which is a whole other
argument)?
First let me tell you that I personally agree with you.
The argument against DNS, as I've seen it in the past, is that it
raises the barrier to entry.
Today, publishing files via HTTP (either a new home-page with a
couple of link rel's or an xrds file) is much simpler than publishing
new DNS records.
Also, personal records for vast numbers of users has never been done
before. Today, if we share a domain between us to, I don't believe
you can have different SPF policies for each one.
But that is expected from blogs or people sharing the same social site.
Anyway, I like DNS based approaches for several reasons, but in this
case, I don't think they are a good match.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
