[Standards-JIG] proto-JEP: Smart Presence Distribution
melo at co.sapo.pt
Thu May 18 00:10:02 UTC 2006
On May 18, 2006, at 12:40 AM, Richard Dobson wrote:
>>> 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.
> Yes you can, but you still have to agree that its not a good idea
> to do something against the original protocol specs when there is a
> simple solution that isnt against them as Joe suggested, dont you
Yes, I do.
His solution seems great, I can't see any problem with it.
>> 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.
> Well personally I think its a better idea to produce one protocol/
> mechanism that can be used by both presence and message though,
> makes things far simpler. But each to their own.
Well, depends. I agree with you on principle.
My point of view is that for now I only see multicast of messages
useful in two contexts: MUC and PubSub. And for those, I prefer the
solutions posted a few hours ago by Jean-Louis Seguineau. You might
not need a new protocol at al.
>> 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.
> Exactly my point, but there do seem to have been points in this
> conversation when it was suggested that this "Smart Presence
> Distribution" protocol would work for message stanza's too, which I
> cant see how it can.
oh missed that suggestion and I would agree with you on that one: I
don't see how it could be used for messages at all.
>> 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?
> Because as already explained even if the rosters are in sync, you
> still need to have some way of dealing with the privacy lists
> without just simply having to not use this mechanism as is
> currently suggested in the spec, we need something long term that
> actually works with privacy lists
In another email I stated that the privacy list problem is one of the
problems still to be solved with this proposal, and personally
syncing privacy lists are not my preferred way to do this.
A bit more thoughts on this (you quoted my previous proposal): I
would use roster annotations, something that would mean, don't
forward presences from this contact.
>> 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.
> Yes thats a possibility, but until the privacy list issue is solved
> using some means of other this "Smart Presence Distribution"
> protocol is pretty useless long term, as as more clients support
> privacy lists more clients are likely to have some blocked contacts
> or other on domains and in so needing this optimization disabled.
Of course: without solving the privacy lists problem, I also prefer
not to go through the trouble of implementing this.
> Yes thats fine, but its still not a good idea to go against the
> specs for no good reason wouldnt you agree? But anyway there is no
> need to argue about this particular point any further thanks to Joe.
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt
More information about the Standards