[Standards] XMPP in ENUM / ENUM in XMPP
stpeter at jabber.org
Wed Jan 31 15:57:47 UTC 2007
Matthias Wimmer wrote:
> Hi Jacek!
> Wow ... I just noticed that we have
> http://www.ietf.org/internet-drafts/draft-ietf-enum-xmpp-01.txt solving
> my first point. :-) I wasn't aware of this internet draft.
Yes, I've communicated with the author of that spec.
Also I've been chatting with an admin from e164.org about getting ENUM
support into XMPP systems -- he is quite keen on it. His one-sentence
summary of ENUM is:
"You take a phone number, reverse and dot notate it, do a look up for
NAPTR records, the right hand side is used for a regex replacement (you
can add \\1 for wild cards etc, but that's about it), and you end up
with a URI."
But I still need to read RFC 2915 etc. to understand it more fully.
> Jacek Konieczny schrieb:
>>> 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.
> Well it depends on what they are used for. Personally I prefere xmpp
> IRIs for use cases, that are special for XMPP. While I prefere "im:" for
> writing down instant messaging addresses.
> A typical user is not interested in the protocol he uses, but just wants
> to send a message to someone. The im: prefix hides the protocol from the
> user and allows an application to transparently select the protocol used
> to start communications.
True. But it also introduces all sorts of weird resolution methods.
> The reason why we currently do not really see any advantage of the im:
> scheme might be, that the XMPP community talks about interoperability,
> but does not really do much about it. We have standards for
> interoperating with other IM networks (RFC 3922, RFC 3923,
> draft-saintandre-xmpp-simple-08), but I currently see no big progress in
> deployment of these specifications.
Mostly because (1) big companies are interested in XMPP-SIMPLE interop
but open-source developers are not, (2) there are multiple flavors of
SIMPLE (MS, IBM, etc.) but even they don't interoperate and (3) SIMPLE
is not yet widely deployed on the open Internet (only in things like
Microsoft LCS, which doesn't federate at all).
>> 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?
> Indeed this will require some more thoughts ... also the interworking of
> E.164 and rosters in that case.
>>> 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
>> 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).
My e164.org friend reports:
The FreeSwitch guys have these URIs stored for +1 (641) 985-7858:
22.214.171.124.126.96.36.199.4.6.1.e164.org. 600 IN NAPTR 100 10 "u" "E2U+xmpp"
"!^.*$!xmpp:888 at jabber.asterlink.com!" .
188.8.131.52.184.108.40.206.4.6.1.e164.org. 600 IN NAPTR 100 99 "u" "E2U+xmpp"
"!^.*$!xmpp:freeswitch at gmail.com!" .
>>> (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.
Why exactly would we want/need E.164 for XMPP<->XMPP communication? I'm
not saying we don't, it's just that I'm still learning about E.164.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards