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

Carlo v. Loesch CvL at mail.symlynX.com
Tue May 30 12:05:30 UTC 2006

Richard Dobson typeth:
| 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.

The JEP specifies that corrections to the recipient list must be made
according to the change in privacy lists. Where's the problem?

| > | This IMO is not very desirable and can break at quite a lot of cases.
| > No. Name one.
| See above.

That was a misunderstanding on your side, not a case.

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

There is no 'try' in that. The original protocol has the same semantic
intention, so it is a perfectly valid approach. You still haven't
delivered facts, you are only delivering feelings.

| Nothing I have suggested is against the specs or requires any re-writing 

You are using JEP-0033 for presence, which conflicts with the way
XMPP defines presence distribution. Also the recipient list storage
idea is not part of JEP-0033, we came up with that.

| 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 

Bring up a precise example that breaks our proto-JEP, then please
help come up with a solution, too. I'm still presuming you are trying
to be constructive. I said that we need a way to distinguish directed
presence, and it would be a shame if XMPP had no way to do this.

| are going to start spouting baseless accusations (after all JEP-0033 
| doesn't break any specs, so why would my suggestion??) please get your 

You are using JEP-0033 for presence, which conflicts with the way
XMPP defines presence distribution.

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

We have a disco negotiation that ensures that both sides know what they
are doing. Now we only need a way to ensure that a directed presence
can be distinguished and treated seperately as it always has been.
At worst we can always add a parameter and a namespace, but it would
be nicer not having to do that.

| 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 

Yeah sure, JEP-0033 for presence is in accordance to all RFCs.
You're dreaming.

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

You started the accusations, and you are the one with the distorted "facts."
Stop accusing and start being helpful.

| especially when your own suggestions is clearly against the very RFCs 
| that you are accusing others of being in breach of.

Not clear at all. Come up with facts, until then this is just babble.
Why do you keep this aggressive tone? Is this proposal affecting your
financial prospects? I obviously can't be aware of all the side effects
a technological improvement can have.

More information about the Standards mailing list