[Standards] Managing Presence Subscriptions based on full JIDs

Tomasz Sterna tomek at xiaoka.com
Sun Feb 3 15:02:49 UTC 2008


Dnia 2008-02-03, N o godzinie 10:43 +0100, Tomasz Sterna pisze:
> So I actually need full JID based subscriptions.

I did some thinking and come to conclusion that it would be hard to
allow full JID based presence subscriptions.

Especially 3.1.5. Server Processing of Outbound Subscription Approval
would be problematic. How does one differ full JID or bare JID based
approval?

Or 2.5. Deleting a Roster Item - shall the subscription 'unsubscribe'
be send where there is another full JID based contact item,or not?


But it would still be possible to add full JIDs to the roster and use
them for server related stuff handling, like sending/answering probes,
and by clients for opening chatwindows to the specific resources (we
have an SMS gateway that uses resources to select which web gateway one
wants to use: +48123456789 at sms.chrome.pl/Gateway1
and +48123456789 at sms.chrome.pl/Gateway2 both send SMS to the same
telephone number, but using different web gateways, so user can add one
or another to send SMS using specific gateway just by clicking the
contact).

During the research I found:
2.3.  Adding a Roster Item
Note: When the item added represents another IM user, the value of the
'jid' attribute MUST be a bare JID <contact at domain> rather a full JID
<contact at domain/resource>, since the desired result is for the user to
receive presence from all of the contact's resources, not merely the
particular resource specified in the 'to' attribute.

Which concludes subscription handling difficulties I described.
But removing the full JID based roster items would disable many good use
cases I described in the thread... :-(


-- 
  /\_./o__ Tomasz Sterna
 (/^/(_^^' http://www.xiaoka.com/
._.(_.)_   im:smoku at xiaoka.com





More information about the Standards mailing list