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

Richard Dobson richard at dobson-i.net
Tue May 30 11:47:56 UTC 2006

Carlo v. Loesch wrote:
> Mridul typeth:
> | Maybe I did not explain it properly enough - I am referring to
> | "http://www.jabber.org/jeps/inbox/smartpresence.html".
> | I was referring to the way the JEP is using outgoing presence info to
> | cobble together a list on the fly in section 5.
> The term "cobble" implies that the process is not well defined, but it is.
No cobble in this context means you are making an already defined 
protocol which does one thing mean another thing that it was not 
originally intended to do, which seems a perfectly reasonable comment to me.
> | It is making assumptions as to who all are in my roster based on the
> | behavior of who all I send my presence updates to , or want the info to
> | be sent to.
> Incorrect. It remembers who you have sent presence to and whom you will again
> later. If you change the privacy list, the change will propagate to all
> involved servers.
Incorrect, if you apply a privacy list or add someone to one the server 
does not automatically send an unavailable presence stanza, so the 
servers will very quickly get out of sync if people are using privacy 
lists and you are relying on presence stanzas as you currently are.
> | This IMO is not very desirable and can break at quite a lot of cases.
> No. Name one.
See above.
> | >| > The initiating server can request for a list creation with a set of bare
> | >| > jid's and then use that as 'to' in subsequent presence stanza's -
> | >
> | >Yes, this is how the context lists operate.
> | 
> | Exactly , why not use this ?
> | Create a new list on the fly on the remote server with the required
> | barejid's, and use that list as recipient to send presence updates to.
> Yes. That's what happens, although it's a bit more deterministic than
> "on the fly."
No it isn't, what he means is having an explicit protocol (as I 
suggested) to manage the lists, rather than trying to reuse existing 
protocol to mean something it wasn't originally intended to.
> | I do not see how there are significant savings when comparing what
> | Richard proposed to what is currently proposed in the proto-JEP ...
> Both suggestions are using the same concept of context lists on the
> receiving side, so they are both fundamentally right. Richards plan
> however makes Presence as it is defined in XMPP IM 5.x useless,
> whereas we keep on using it. It's a question of taste, I personally
> don't mind rewriting the XMPP RFCs, but it is certainly out of the
> scope of a new JEP then.
Nothing I have suggested is against the specs or requires any re-writing 
(it is simply a small extension of the idea of an existing draft 
protocol), if you really think this then you should go back and re-read 
them as you have clearly misunderstood them. In fact it is your 
mechanism that would require re-writing the specs as it is not 
compatible with directed presence as outlined in XMPP IM 5.1.4, if you 
are going to start spouting baseless accusations (after all JEP-0033 
doesn't break any specs, so why would my suggestion??) please get your 
facts right first, "those in glass houses shouldn't throw stones".
> | Without the guesswork , security issues, etc.
> | There is no need to be different just to be "new" :-)
> What guesswork? What security issue? And who's trying to be new and different?
The fact that you are making the assumption that just because you have 
sent presence to a particular JID that you want them to receive all 
future broadcasts, directed presence is what makes your mechanism 
guesswork and a security issue as you do not want people you have sent 
directed presence to to get all your normal broadcasts.

> | Exactly - it would become a generic : create "random lists" sort of thing.
> | How you use these lists would be implementation dependent.
> | Could be for MUC , for presence broadcast , etc ... not necessarily for
> | multicast.
> | The "life" of a list is also not gaurenteed - except for reasonable
> | limits like atleast one operation on the list , prevent abuse by
> | throttling number of lists being created , etc.
> | 
> | But then I think something like this is already in place right ?
> You are thinking all along our lines. Just because we use the *existing*
> syntaxes to populate certain lists that serve a certain purpose doesn't
> mean you can't use those lists in a different way, populating them with
> the appropriate protocol to that purpose. The data structures and
> algorithms are there. You think a one-protocol-fits-all approach would
> be nicer - alright, but then you have to do it against the current RFCs.
No it is not against the current RFCs any more than JEP-0033 is against 
the current RFCs, as already noted it is in fact your suggestion that is 
against the RFCs, so again please get you facts right in future and 
don't just spout baseless accusations without anything to back them up, 
especially when your own suggestions is clearly against the very RFCs 
that you are accusing others of being in breach of.


More information about the Standards mailing list