* Florian Schmaus <f...@geekplace.eu> [2015-09-30 15:26]:
> On 30.09.2015 15:09, Holger Weiß wrote:
> > * Florian Schmaus <f...@geekplace.eu> [2015-09-30 14:37]:
> >> What about XEP-191 § 5?
> >
> > This doesn't solve the issue:
> > http://mail.jabber.org/pipermail/standards/2014-December/029430.html
>
> It appears it could solve it: The client using xep16 generates an
> privacy list item as per xep191 § 5, and the server exposes this item as
> blocked jid item for clients using xep191. Maybe Sam or you could
> provide some details in this case: How does the privacy item look like
> which gajim does generate?

Gajim blocks everything but incoming presence:

  <iq type="set">
    <query xmlns="jabber:iq:privacy">
      <list name="block">
        <item action="deny" type="jid" order="1"
         value="jul...@example.com">
          <message />
          <iq />
          <presence-out />
       </item>
      </list>
    </query>
  </iq>

> Does the server transform xep191 and xep16 entries?

Yes, but ejabberd considers a JID as "blocked" in the sense of XEP-0191
only if all stanza types are blocked in both directions.

> But I've not heard that that this is a problem. And I don't
> think it will be: The user used a xep16 client to generate the xep16
> rules and is therefore aware that they exist.

Please explain this to my users.  They press a "block" knob in Gajim.
Later they use Pidgin, where the blocked contact is marked as unblocked.
Their reaction is usually not like "oh sure, I remember how I used an
XEP-0016 client to generate an XEP-0016 rule last year.  My new client
just implements XEP-0191, so the behavior is obvious."  Instead, they
simply perceive this as yet another XMPP brokenness.

Holger

Reply via email to