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

Peter Saint-Andre stpeter at jabber.org
Tue Feb 24 21:24:40 UTC 2004


On Wed, Jan 21, 2004 at 06:36:13PM -0600, Thomas Muldowney wrote:
> 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.

Another point is that the IETF is not the best place to develop
protocols. Granted, this protocol was originally developed in the Jabber
community, but I agree that it would be good to do more reality-focused
prototyping and design.

BTW, JEP-0016 never moved to final because (1) very few JEPs have moved
to final at all and (2) we included it in the IETF process, therefore
deferred consideration of it in the JSF.

As to (1), perhaps we need to focus on moving some JEPs to final. :-)

Peter


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




More information about the Standards mailing list