[Standards] Blocking command and Privacy Lists

Dave Cridland dave at cridland.net
Mon Dec 22 15:21:35 UTC 2014

On 22 December 2014 at 13:51, Sam Whited <sam at samwhited.com> wrote:
> On 12/22/2014 04:19 AM, Dave Cridland wrote:
> > Slightly confused by this. XEP-0191 is server-side enforced, so the
> > behaviour will be applied and controlled by the server, not the client.
> Gajim uses Privacy lists without the XEP-0191 frontend. Sorry, I was
> unclear there.
Ah, so it's not really doing XEP-0191 at all.

> > This would mean that probes still get sent, which seems inappropriate.
> My language probably needs to be tweaked (and updated in several other
> places in the XEP); outgoing probes (from the user to the blocked
> client) should remain the same (dropped so the user appears offline).
> Incoming probes should be handled like they currently are:
> From XEP-0191:
> > For presence stanzas (including notifications, subscriptions, and
> > probes), the server MUST NOT respond and MUST NOT return an error.
> The server must not respond, but it could still pass notifications on to
> the user.
As Kurt says, the spec is pretty clear - if a contact is blocked via
XEP-0191, then the user neither sends nor receives any stanzas to/from the
contact. I don't think we want to play spec-lawyer games here.

> > Otherwise we're in the slightly weird situation that we're predicating on
> > remote servers sending presence without a probe - this is quite possible,
> > but could lead to some very odd behaviour when this get out of sync.
> Also,
> > there's the RFC 3921 optimization; that reduces the presence to just
> > online/offline in some cases.
> Good point; I hate to potentially leak information by sending probes to
> the server. I'll have to think about this one.

Also bear in mind that XEP-0191 was designed to be a simple replacement to
XEP-0016, the observation being that with the exception of some extremely
rare cases, everything people actually used XEP-0016 for could be wrapped
up into XEP-0191 and XEP-0186. I don't really want to make this more
complex than it absolutely has to be.

So overall, I'm bound to entirely agree with Kurt's line of reasoning and
recommended resolutions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141222/a243744a/attachment.html>

More information about the Standards mailing list