[Standards] Jingle: UDP relays
stpeter at jabber.org
Wed Aug 15 16:11:51 UTC 2007
Scott Ludwig wrote:
> On Aug 14, 2007 4:05 PM, Peter Saint-Andre <stpeter at jabber.org
> <mailto:stpeter at jabber.org>> wrote:
> Peter Saint-Andre wrote:
> > Unnikrishnan V wrote:
> >> The best approach, in my opinion is to have a generic network
> >> record framework and XMPP registrar to keep addition of services
> >> entries. The same framework can be used for network server offered
> >> service or XMPP service (like muc ).
> > Yes I think that is worth considering. I'll give it some more thought
> > over the new few days...
> Well, I thought about it some more.
> Please note something in XEP-0215:
> "This method should be used only as a fallback when DNS SRV lookups are
> not possible for the client or server."
> Now, I wonder why we're going to spend a lot of time defining something
> that is essentially DNS-SRV over XMPP. Why not encourage people to
> deploy SRV instead?
> One practical reason is that the people who write code in the XMPP
> servers are not always the same as the people who configure DNS records,
> at least in larger organizations :) This seems like a problem that XMPP
> is well suited for.
> Another consideration: querying SRV records takes a fair bit of code and
> complexity in the client on some platforms. It's easier for an XMPP
> client to parse XMPP messages.
But typically I don't think it's a good idea to reinvent the wheel. :)
If we go the route of developing a "generic network service record
framework" with an XMPP registry of services, then we need a flexible
way to do encapsulate the information that a client or other XMPP entity
might want to retrieve. That information will be different for different
network services (e.g., IP and host for STUN servers, potentially some
kind of credentials, etc.). I assume that someone has already solved
that problem. In fact, it's probably what DNS SRV does -- people just
want an XMPP-ish interface to that data, right?
/me ponders some more
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards