[Standards-JIG] proto-JEP: Smart Presence Distribution
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
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