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

[Pedro Melo]

Hi,

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
>>
>> You can communicate just fine with different resources directly, even
>> if
>> just the bare JID is on your roster or not on it at all. If you
>> receive
>> presence, you'll know about their availability, too.
>
> Sure.
> 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.

I think that in the long run, you'll be better off using capabilities  
or feature negotiation.

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.

But without the reasoning of your decision to choose 1 over 2, I can  
only speculate.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!