[Standards-JIG] proto-JEP: Smart Presence Distribution
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
>> 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.
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt
More information about the Standards