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

Richard Dobson richard at dobson-i.net
Wed May 17 23:40:55 UTC 2006


>> 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 think?

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

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

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

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

If we are going to introduce a proper protocol for this it definately 
needs to account for the privacy lists somehow and still be able to 
optimise the traffic.

> Notice that again, the usage of this extension was negotiated previously 
> so we are fine to add new meanings to existing protocols.

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.

Richard





More information about the Standards mailing list