[Standards-JIG] Roster Subscription Synchronisation

trejkaz at xaoza.net trejkaz at xaoza.net
Wed Sep 15 04:27:53 UTC 2004

At Wed, Sep 15, 2004 at 01:09:42AM +0100, Richard Dobson wrote:
> >Erm, I don't think it's a wise idea to just delete something when you're 
> >not sure what it is!
> In what cases wouldnt a "none" mean the legacy contact has been removed 
> from the legacy roster?

If your transport were transporting to Jabber (unlikely, sure, but just an
example,) the user on the other end might have simply unsubscribed from you,
and revoked your subscription, but not removed the roster item.  Of course,
nothing really says that the legacy IM services won't have this feature as
well, it's just sheer luck that all the major ones oversimplify the process.

> Now as you say at stage 3 the transport could reply with an unsubscribe and 
> it would return the subscription to "to", but all this interaction is 
> hardly intuitive and has a big potensial of seriously confusing the end 
> user, IMO the transport should only ever be sending a "subscribe" to the 
> jabber user if the legacy user is actually subscribing to the users 
> presence, sending this falsified subscription IMO is a hack and is unclean 
> (a clean solution would be one that transmitted the "to" info without 
> needing to make any falsified subscriptions as you seem to want to) as it 
> is not really intending to subscribe to the users presence and so is the 
> wrong way to do it.

Maybe this information shouldn't even be going all the way to the user, but
the user should be setting some security rules on the server, and the server
should be automatically handling all this on the behalf of the user.

That way, when the subscription changes, the roster update would get pushed
to the user just as if another resource were logged in.  No presence flies
around, then, or at least not to the user.  But maybe if it were the server
handling it, client backwards compatibility would no longer be an issue, and
we could use simpler <iq/> packets to do the exchange.


             Email: Trejkaz Xaoza <trejkaz at xaoza.net>
          Web site: http://xaoza.net/trejkaz/
         Jabber ID: trejkaz at jabber.xaoza.net
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20040915/6a2871dd/attachment.sig>

More information about the Standards mailing list