[Standards] RFC 3921bis Managing Presence Subscriptions based on full JIDs serious issue
Maciek Niedzielski
machekku at uaznia.net
Fri Feb 8 10:23:18 CST 2008
Pedro Melo pisze:
> On Feb 7, 2008, at 3:14 PM, Tomasz Sterna wrote:
>> Dnia 2008-02-07, Cz o godzinie 15:48 +0100, Ralph Meijer pisze:
>>>> I still see a very good use case for having full JIDs on the roster:
>>>> to communicate with different facets of the same thing.
>>>> Ex. chrome.pl/echo and chrome.pl/broadcast
>>>> or +48123456789 at sms.chrome.pl/Gateway1
>>>> and +48123456789 at sms.chrome.pl/Gateway2
>> But why do you enforce me to choose the resource every time (instead of
>> just double clicking the contact) when I know that I will always be
>> wanting to communicate only with the given one?
> hmms... You are asking a client to decide something semantic based on
> the resource value.
> It really depends why would you want to choose Gateway1 over Gateway2.
> If it is because you want to use some specific feature that 1 provides
> that 2 does not, then it's clearly a matter for capabilities and not
> resource names.
It depends on which SMS gateway is provided by your mobile operator and
and who operates the number you're trying to reach. And yes, it's mostly
about money and other limits that mobile operators have in their gateways.
(So for example, if my phone is operated by operator A, and I'm trying
to send to a number operated by the same operator, I probably want to
use operator A's gateway. But if the number I am trying to reach is from
operator B, operator A's gateway may not allow me to send this message
for free. Also using operator B's gateway may be not-free for me (as my
number is operated by A). But maybe it will be cheaper with my current
cost plan. Etc, etc.)
--
Maciek
xmpp:machekku at uaznia.net
More information about the Standards
mailing list