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

Pedro Melo melo at co.sapo.pt
Wed May 17 22:36:56 UTC 2006


On May 17, 2006, at 10:30 PM, Richard Dobson wrote:
> Carlo v. Loesch wrote:
>> Richard Dobson typeth:
>> | What makes you suppose that? We usually prefer to look longer  
>> term when | developing protocols here, and prefer to develop  
>> solutions that will not | break or are against the existing  
>> protocol, we prefer to extend.
>> Even the JEP as it is posted to the inbox doesn't break anything.
> Yes it does, as already stated by several people not having the to  
> attribute is against the protocol specifications, and thus breaks  
> the spec.

As long as its properly negotiated by two parties, it's fine.

>> The current suggestion is, if the user is using privacy lists on any
>> target of a particular server, to revert to the current distribution
>> method, thus a fan out with exceptions.
> Yes which shows that this protocol is not something we really want  
> long term, and that it is simply a short term hack, long term we  
> want a multicasting protocol that does not have this limitation and  
> that also works for messages not just presence.

No. We want the correct protocol for each type of problem. In my view  
presence is a different problem of messages and IQ's because  
presence's can use the already distributed roster information. So a  
multicast protocol for presence should use that roster information,  
like this proto-jep does.

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.

>> It would be good to know, if even this simple approach already brings
>> relevant traffic decrease. We have no figures on that.
>> Concerning the problem of keeping subscriptions in sync:
>> What's bad about occasionally having your server re-issue subscribed
>> and unsubscribed messages during off hours, so that the server  
>> network
>> slowly cleans out sync problems. wouldn't it be possible to use the
>> existing presence subscription protocol without changing anything?
> 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?

> > This also is a much
> > less invasive change than to introduce a verbose new protocol.
> Sorry but as far as I can see that is not true at all as keeping  
> the privacy lists in sync will be a far more verbose protocol, than  
> a protocol for keeping a distribution list in sync would be, simply  
> because when you send over the privacy list you are sending all  
> sorts of data and settings, whereas with a distribution list you  
> are just adding and removing JIDs, also if you are just using the  
> standard privacy list protocol whenever it changes you send the  
> whole list over each time, very verbose, whereas the distribution  
> list protocol could easily use an approach similar to the roster  
> where you can add and remove items without sending the whole list  
> each time.

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.

Best regards,
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt

More information about the Standards mailing list