[Standards-JIG] proto-JEP: Smart Presence Distribution
Carlo v. Loesch
CvL at mail.symlynX.com
Tue May 30 17:56:15 UTC 2006
Richard Dobson typeth:
| > The JEP specifies that corrections to the recipient list must be made
| > according to the change in privacy lists. Where's the problem?
| That is something which is not currently part of how privacy lists work,
| if you apply an outgoing block of presence it does just that, it doesn't
| send out an unavailable presence, are you suggesting we change how
Well the intention was not to send out something because a privacy list
has changed, but to reflect the new recipient list that the change of
privacy list implies - which in the end technically boils down to the
same thing, only you can do it just before the next presence update
instead of doing it when the user is doing something to her privacy lists.
| privacy lists work so that when you block someone from receiving your
| presence you send out an unavailable presence to them?, that could
With MUC 'unavailable' has exactly the meaning we need, that's why
our strategy works just fine for MUCs. with regular presence, unavailable
is indeed not exactly the same thing as 'not on my list anymore'
| possibly work, but does kind of go against the spirit of how it works,
| does anyone else have any problem doing this? It is making you appear
| off-line automatically whereas it wouldn't have previously is anyone
| taking advantage of this fact in the wild?
Yes that is a very good question. Would this change have any effect
on anybody, or is it acceptable? We could try it out on a test basis
and should any scenario appear, where it _is_ a problem, then we have
to define a new stanza for list deletion.
mind you, one little extension for occasional deletions is still much
less overhead than doing all additions and deletions in a new format
and possibly even adding acks.
especially for MUCs it would be sad to go for a new list population
syntax, as the existing MUC presence protocol is just perfect for list
population. i get the feeling we should have submitted _that_ proposal
| A precise example is if you send directed presence to a particular JID
| that is not in your roster (i.e. would not normally receive your
| presence broadcasts) that is at the same server as someone who is in
| your roster the person you sent directed presence to would start
| receiving your broadcasted presence whenever you updated it, whereas in
| section 184.108.40.206 it says "it MUST NOT include the entity's JID in any
| subsequent broadcasts of available presence initiated by the user".
That's the problem I am talking about when I say I want to be able
to distinguish direct presence from regular, so that it DOESN'T get
taken into account for future broadcasts.
At worst we'll have to push a list-delete after the directed presence.
Then again, we can simply mark the directed presence with a namespace
| That's the problem I cant see any clean way around the problem with
| directed presence without having explicit lists of recipients being
| set-up between servers as there is no visible difference between a
| presence broadcast and directed presence once it reaches the destination
That is not nice, but let's see what we can do about it.
We could restrict the direct presence to always be sent to a resource
whereas the regular presence is always sent to bare JIDs. The sending
server would ensure that, as it has to process outgoing directed
| Yes not a very nice solution (feels like a bit of a hack), but im not
| sure if there is any other way, it also means the server altering the
| presense stanzas when they are received from the user, not the end of
| the world but best avoided, how does anyone else feel about this?
When redistributing presence one-to-many you are rewriting things
all the time anyway.
| It is in accordance as far as I can see, can you please explain exactly
| what is making you think that using JEP-0033 is against the RFCs? which
JEP-0033 is a protocol for delivering ONE message to multiple recipients
ONCE. it has no provisions for managing lists on a recipient side, as that
is a new idea. instead it comes with to/cc/bcc overhead which is of no use
here. and it was never designed or allowed to deliver presence stanzas.
so if you send presence in a JEP-0033-like syntax, you are stopping to send
it according XMPP IM 5.x - this may not be a breach, but you are stepping
away from the current practice a lot further than we do.
| Sorry but no, you started the accusations stating that JEP-0033 and my
Hehe now we get petty indeed. You started the heavy tones when you said
I had no right to say our proto-JEP is the best proposal when it comes
to scalability. Which still holds true, because concerning the amount of
traffic reduction, ours is the most light-weight. The old one was even
better, but alas, roster can't be trusted on Jabber. Works fine for PSYC
though. So now we have one that requires occasional refreshes. Still
better than one with acks. The problems have to be figured out, but that
counts true for all proposals and I wasn't denying that. In fact I mentioned
that in the same sentence. So that was the point when you fired up the
| Its not affecting my financial prospects, I simply object to people who
| aggressively defend their position using arguments or assumptions that
| have been shown to be incorrect, saying things without backing them up
Whenever you have shown we were incorrect, we went back to drawing board
and thought about something new. But most of the time you were TELLING us
we were wrong with something, and never making it sufficiently CLEAR.
So as long as your criticism isn't clear, you can't expect anybody to
back down just because you have written a server or work for an
impressive company. Last time it took posts after posts until you
finally came up with the real information: XMPP is broken when it comes
to rosters. Okay, we didn't know about that. It's okay, we'll navigate
around the problem as seems to be the usual practice.
I'm not here because I like XMPP. I like Jabber, the idea of it, after all
it's the same idea that started me working on PSYC in 1991, but I sure don't
like a lot of technical aspects about it. That is a less cozy approach than
any Jabber enthusiast's, but still a very good chance for XMPP to get better.
» Carlo v. Loesch » http://symlynX.com » psyc://ve.symlynX.com/~lynX
xmpp:lynX at ve.symlynX.com » irc://ve.symlynX.com/#symlynX
CryptoChat » https://ve.symlynX.com:34443/LynX/?room=symlynX
More information about the Standards