[Standards-JIG] proto-JEP: Smart Presence Distribution

Carlo v. Loesch CvL at mail.symlynX.com
Thu May 18 09:31:30 UTC 2006


Pedro Melo typeth:
| Multicasting messages is a different protocol because they cannot  
| rely on the roster info, given that it does not have any bearing on  
| a, for example, MUC room composition.

well, the 'Smart Multi-User Chat Distribution' JEP which is lying in
our thinktank CVS right now and is ready for submission does make use
of a different way on how to collect the list of receivers, but once
the list is defined it uses the same technique for distribution as
the proto-JEP on presence.

so you could say we have taken the best of both options - we have
a generic smarticast and later multicast solution for both problems,
and still we have optimization for each of the two cases.

| > Nothing is wrong with servers using measures to try and make sure  
| > the rosters are up to date, but because they wont be 100% up to  
| > date all the time it seems wrong to use them as you want to as it  
| > means presence could be leaked to people who shouldnt receive it.
| 
| So if this is the problem, what solution would we use to keep the  
| multicast-service lists in sync? If that protocol appears, why not  
| use it to keep the rosters in sync?

yes i agree that keeping the rosters in sync, then using them, is
a better idea than to use new distribution services (JEP-0033 !=
multicast) and leaving the roster problem as it is, on the floor
bleeding. so i'd rather see some derivate of JEP-0033 in use for
repairing rosters.

| I admit that I'm still thinking on the best way to deal with presence- 
| out privacy lists.
| 
| The best I came up with so far is extending the subscription types  
| with modifiers: add a silent modifier. for example, if you and me  
| have our rosters in sync with both, and I add you to my presence-out  
| privacy list, I would send a <presence sp:modifier="silent"  
| to="your_jid" sp:xmlns="some_namespace" /> to you.
| 
| Notice that again, the usage of this extension was negotiated  
| previously so we are fine to add new meanings to existing protocols.

yes please keep this productive discussion up. we have not suggested
how to implemented privacy lists in the new constellation, mostly
because we consider people like you more competent to help us finish
the proto-JEP they way you need it.

our competence lies in multicasting. both pseudo multicasting (what we
call smart unicast or what you call jep-0033) and real multicasting
(where we haven't even gotten to in the discussions so far).




More information about the Standards mailing list