[Standards] Managing Presence Subscriptions based on full JIDs

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 6 23:56:26 UTC 2008


Tomasz Sterna wrote:
> 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?

Hmm, we'd need to change the rule so that the server stamps the 'from'
address with the bare JID only if the 'from' is not included by the
approving client.

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

The removing client would specify the full JID and the server would send
the unsubscribe to that full JID. But then we'd need to define how the
receiving server handles that.

> 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).

Right. Those use cases seem potentially interesting.

> 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.

Again, that is a client rule, not a server rule. Naturally, the client
could violate that rule, in which case the server might be confused
about how to handle things. So in any case we need to document more
clearly how the server shall handle all these roster/subscription stanzas.

> 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... :-(

Your examples were subscriptions to <host/resource> JIDs, not full JIDs
(connected resources of registered accounts). But as I say we need to
document all this more clearly, because presence is so valuable that
clients will want to subscribe to things like echo scripts, pubsub and
MUC services, etc.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080206/c51683a7/attachment.bin>


More information about the Standards mailing list