[standards-jig] Fwd: [JDEV] Client support for XMPP Privacy and Jabberd 2

Thomas Muldowney temas at box5.net
Thu Jan 22 00:36:13 UTC 2004

Even though this is moving off this list to XMPP, I think there are 
some important results of this to consider.  First, I think this is 
related to recent council discussions about more implementation fueled 
design again.  Perhaps this protocol moved to fast without any 
practical use, and now that people are finally starting to they are 
finding flaws.  Previously this was largely related to the movement to 
final, but looking back at 16, it never moved to final, which would 
have required implementations and notes from them.  I think the recent 
council actions are steps in the right direction, but I just want 
everyone to reflect on it all a bit, and not just move on.


On Jan 21, 2004, at 3:20 PM, Peter Saint-Andre wrote:

> Folks:
> This is how the protocol has *always* been. I refer you to JEP-0016,
> which advanced to Draft (presumbly following review and discussion on
> this list and by the Jabber Council) before being deprecated in favor
> of work by the XMPP WG:
> http://www.jabber.org/jeps/jep-0016.html
> It's been two years since this protocol was introduced, and no one has
> brought up resource synchronization until now. There are many factors 
> to
> take into account here, not least of which is that privacy rules are
> updated by sending the complete list (not the delta, as with rosters),
> and pushing the complete list out to all resources was perceived as
> problematic. It's possible that we could develop some sort of
> notification protocol (IQ push or message) to be used if one of your
> active lists has been changed by another resource, thus prompting your
> client to retrieve the list again. But this is not the place to discuss
> such changes, since we've ceded control of this protocol to the XMPP 
> WG.
> So we need to discuss this topic on the XMPP WG mailing list:
> http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg/
> Peter
> On Wed, Jan 21, 2004 at 02:32:06PM -0500, Julian Missig wrote:
>> Is there any particular reason this protocol was not designed such 
>> that
>> the iq sets of changes go out to all resources? Whenever dealing with
>> something server-side, the choices made for iq:roster should be
>> examined and see whether they apply to the new protocol... I'm fairly
>> certain this is a case where iq:roster's behavior of sending iq sets 
>> to
>> all resources is desired.
>> Any reason why we wouldn't want these changes automatically 
>> propagating
>> to all resources?
>> Julian
>> On 21 Jan, 2004, at 14:26, Thomas Muldowney wrote:
>>> This thread from jdev is an important read.  There are a few replies
>>> on jdev.  Thoughts?
>>> --temas
>>> Begin forwarded message:
>>>> From: Dudley Carr <dudley at cs.stanford.edu>
>>>> Date: January 21, 2004 1:06:09 AM CST
>>>> To: jdev at jabber.org
>>>> Subject: [JDEV] Client support for XMPP Privacy and Jabberd 2
>>>> Reply-To: jdev at jabber.org
>>>> I'm working on a client-side implementation of XMPP Privacy and I
>>>> seem to have run into a snag. There are visual elements in our 
>>>> client
>>>> that can be changed which in turn changes the active privacy list.
>>>> This is all good and well expect if there are multiple clients 
>>>> logged
>>>> onto the same server with the same JID but with different resources.
>>>> Both clients typically would read the privacy settings after logging
>>>> in. However, they would be unaware of changes to the privacy lists,
>>>> and thus the visual elements (such as showing your status as
>>>> invisible) in the one of the clients would be incorrect. The roster,
>>>> like the privacy lists, is a piece of data that clients have to
>>>> synchronize on. Unlike the privacy lists, the roster side steps this
>>>> problem b/c the XMPP spec, I believe, requires roster changes to be
>>>> pushed to all the resources. As far as I can tell, this isn't true
>>>> for privacy lists changes.
>>>> A possible work around that I was considering is to send an set-IQ
>>>> packet from one client to another so that they can be synchronized,
>>>> but the current Jabber 2 server doesn't allow IQ packets through for
>>>> query namespaces such as jabber:iq:privacy or jabber:iq:roster. I
>>>> can't seem to find anything in XMPP that would disallow this
>>>> behavior, but it does make sense in most cases.
>>>> I'm out of ideas on this one short of some kind of custom namespace
>>>> solution.
>>>> Regards,
>>>> Dudley
>>>> _______________________________________________
>>>> jdev mailing list
>>>> jdev at jabber.org
>>>> http://mailman.jabber.org/listinfo/jdev
>> _______________________________________________
>> Standards-JIG mailing list
>> Standards-JIG at jabber.org
>> http://mailman.jabber.org/listinfo/standards-jig
> -- 
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list