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

Richard Dobson richard at dobson-i.net
Wed May 17 21:30:29 UTC 2006

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.

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

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

> The result should be same as with a JEP-0033-like transfer of the
> context subscriber list before getting started with smarticasting.

No it isnt as it doesnt take account of privacy lists.

> Concerning the privacy lists, we could extend the protocol used to
> define these privacy lists between client and server in a way that
> the changes are also forwarded to the target server, so the target
> server knows which exceptions to keep in mind. 

Thats one way, but as already noted you might not want to pass the 
privacy lists onto the other server, and why do you even need to? as 
only the presence-out part of the privacy list is even relevant to other 

 > 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 noticed Jabber sends presence whenever someone is in the roster,
> then you have to put a filter to stop him from doing so. Other protocols
> let you keep somebody in the buddy list even if you haven't exchanged
> presence subscriptions.. easily, so you don't have to filter something
> afterwards. You can simply avoid handing out presence in the first place.

Jabber allows you to have people in your roster without presence 
subscriptions its called a status of "none".

> I have understood that privacy filters is the only mechanism of this
> kind, and thus you cannot do without. It would be nicer if one could
> exchange "friendship" and roster listing without implying presence
> subscriptions.

Privacy lists allow you to stop someone from receiving your presence 
temporarily without having to unsubscribe them from your presence, which 
is IMO a very useful feature, otherwise you would need to unsubscribe 
them from your presence, and when you do want to allow them to see your 
presence again you cant, as its them thats got to re-subscribe to your 
presence again, you cant do it for them, overall very messy.

> But this is just theory. Jabber has a model that relies on outgoing
> filters, so we will see how we can go about that.

What is just theory?


More information about the Standards mailing list