[Standards] Deprecating Privacy Lists

Florian Schmaus flo at geekplace.eu
Wed Sep 30 13:26:22 UTC 2015


On 30.09.2015 15:09, Holger Weiß wrote:
> * Florian Schmaus <flo at geekplace.eu> [2015-09-30 14:37]:
>> On 30.09.2015 10:47, Holger Weiß wrote:
>>> * Christian Schudt <christian.schudt at gmx.de> [2015-09-30 10:38]:
>>>> XEP-0016 is complex, but powerful. I see no reason to deprecate it, just
>>>> because there's a similar XEP (0191).
>>>
>>> That's not the reasoning.  The reasoning is that they aren't compatible.
>>
>> 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? Does the server transform xep191 and xep16
entries?

It is my understanding that servers supporting xep16 and xep191 SHOULD
translate a xep16 privacy list item

<item type='jid'
          value='tybalt at example.com'
          action='deny'
          order='29'>

simply into

<block xmlns='urn:xmpp:blocking'>
  <item jid='tybalt at example.com'/>
</block>

as per xep191 § 5.

> The problem is that it's unclear (to me) how to map XEP-0016 rules that
> block some kinds of stanzas but not others.

You can't map those to xep191. After all xep16 is more powerful then
xep191. Therefore clients using just xep191 will never be aware of their
existence. 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.


- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150930/04ffb662/attachment.sig>


More information about the Standards mailing list