[Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue
Richard Dobson
richard at dobson-i.net
Sat Feb 9 18:54:27 CST 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.
Richard
More information about the Standards
mailing list