[Standards] XMPP in ENUM / ENUM in XMPP

Matthias Wimmer m at tthias.eu
Wed Jan 31 13:07:22 UTC 2007


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.

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.

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.

> 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 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).

Right.

>> (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.

Right.



Tot kijk
     Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/

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


More information about the Standards mailing list