[Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue

Richard Dobson richard at dobson-i.net
Sun Feb 10 00:54:27 UTC 2008

Tomasz Sterna wrote:
> Dnia 2008-02-08, Pt o godzinie 20:54 +0000, Richard Dobson pisze:
>> But surely in those cases the JIDs would be something like:
>> +48123456789 at vodafone.sms.chrome.pl
>> +48123456789 at orange.sms.chrome.pl
>> +48123456789 at tmobile.sms.chrome.pl
> What I _really_ don't like with it, is mapping one namespace to many
> namespaces in XMPP domain.
> +48123456789 at vodafone.sms.chrome.pl is the same thing that @orange. and
> @tmobile.

But they are not are they, they are completely different providers, the 
poster was saying how they wanted to address completely different 
service providers using JIDs similar to:

+48123456789 at sms.chrome.pl/vodafone
+48123456789 at sms.chrome.pl/orange

But personally I dont think that is the right way to go about it, 
resources IMO should really be used for addressing the same entity just 
how they are used in c2s terms, and IMO different service providers are 
different entities. The other way is to do as Pedro suggested and use:

+48123456789 at sms.chrome.pl

and just allow the one gateway to route the text message via the 
cheapest route itself.

> This is similiar case with transports, that map one legacy names to many
> XMPP JIDs, depending where the gateway is, causing very abstract
> problems...

So you are suggesting when addressing transports we use JIDs similar to 
the following?

12345 at gw.xxxx.com/msn
12345 at gw.xxxx.com/yahoo
12345 at gw.xxxx.com/aim


> "I just switched my transport from gw.xxxx.com to gw.yyyyy.net. How do I
> migrate my contacts of 12345 at gw.xxxx.com. Oh, btw, I do want to keep the
> chat history so this strange thingy JRU is no good..."

Migration is a completely separate issue to the addressing of the 
gateways, that just needs a protocol so you can easily migrate 
automatically without much real effort from the user.

> And with different gateways we loose the fallback to try Gateway2 when
> selected Gateway1 resource is not available (default highest priority
> resource message routing fallback).

No you dont, if the gateway is not available you will get an error 
returned to you and you can just try resending to a different gateway.


More information about the Standards mailing list