[Standards] XMPP in ENUM / ENUM in XMPP
jajcus at jajcus.net
Wed Jan 31 12:20:45 UTC 2007
On Wed, Jan 31, 2007 at 12:49:33PM +0100, Matthias Wimmer wrote:
> 1. How are XMPP addresses included in ENUM.
> There is already an enumserivce for presence (RFC 3953) but none for
> instant messaging. So we could either defining an enumservice for the
> "im:" URI scheme and/or more XMPP-like for the "xmpp:" URI scheme.
I generally prefer xmpp: URIs for XMPP-reachable entities over im: URIs.
> 2. How do we submit ENUM addresses in XMPP.
> Probably we will only allow inclusion of ENUM addresses in XMPP on c2s
> links. The natural way would that we allow to use E.164 addresses as the
> value of the to attribute of our stanzas. (e.g. <message
> from='mawis at amessage.info' to='+491777719999'>...</message>)
> From the point of view of our current syntax for JIDs this would mean,
> that we use E.164 addresses as domains. As E.164 addresses like
> '+491777719999' do pass the nameprep profile of stringprep and are not
> used as domains (due to the '+' sign at the beginning), so this seems to
> be okay, as it does not break existing software/standards beside being a
> destination not resolvable by them.
Seems ok to me. How would such JIDs work with Jingle and other protocols
that may be useful with E.164 numbers? Doesn't any of the protocols
require node part in the JID?
> For a client to be able to know if the server supports ENUM, we should
> define a service discovery feature, that is advertized by such servers.
Not ENUM, but rather E.164 addressing. If it is done server-side then it
doesn't matter what mechanism is used to resolve the address or what
kind of protocol is used to reach the target. I can imagine VoIP
gateways integrated into server that would handle E.164 number calls.
And practically no specific client support would be needed (just let the
user enter E.164 addresses).
> (Alternative solution would be to define a new iq protocol, that a
> server can offer, that does the ENUM DNS resolving. This protocol could
> be used by a XMPP client to query the E.164 address and get back an XMPP
> address that can be used as destination JID of a stanza.)
This would make easier to use E.164 for XMPP<->XMPP communication --
after getting the real JID it is regular communication between two
regular JIDs, but would make a bit harder to implement transparent
gateways to other services, I think.
More information about the Standards