[Standards] alternate SRV records?

Peter Saint-Andre stpeter at stpeter.im
Mon Mar 24 04:47:19 UTC 2008

Joe Hildebrand wrote:
> On Mar 22, 2008, at 8:43 AM, Alexander Gnauck wrote:
>> Peter Saint-Andre schrieb:
>>> 1. Let's say you want to connect to a MUC service. Does it make sense to
>>> have an SRV record for that? Such as:
>>> _xmpp-groupchat._tcp.conference.jabber.org 5269 athena.jabber.org
>>> 2. Let's say you want to connect to a pubsub service that pumps out
>>> notifications. How about this?
>>> _xmpp-notification._tcp.pubsub.jabber.org 5269 athena.jabber.org
>> I think that we should recommend srv records also for services which
>> run on subdomains. Most server admins setup srv records only for the
>> main server. But I don't think it makes much sense to come up with new
>> prefixes, because groupchat and muc are just services which require
>> s2s, so I would use _xmpp-server for them.

Yes, I think you're right. If you know your account is at foo.com and
you want to join a chatroom at bar.com then you know that a
server-to-server connection will be required.

> +1.  You can always disco#info to the address to find out what it is.

Right. Step 1 if you're a client is to get on the network. Step 2 is to
find out about other entities on the network.

> If you really had to do this, it should probably be some sort of NAPTR
> query, anyhow, so that you could look up
> _xmpp-notification._tcp.jabber.org and have it give you back
> xmpp:pubsub.jabber.com, which you could then SRV.  This would be useful
> in the edge case where I'll allow you to talk to my pubsub, but not to
> my IM domain, so that I can't disco#items your IM domain to find the
> other related services.

Hmm, that does seem like an edge case. Do any existing servers behave
that way?


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080323/f0efd26e/attachment.bin>

More information about the Standards mailing list