Re: [Standards] Deprecating Privacy Lists

On Wed, Sep 30, 2015 at 4:54 PM, Sam Whited wrote: > On Wed, Sep 30, 2015 at 2:57 AM, Sergei Golovan wrote: >> Well, It's unfortunate, because XEP-0191 doesn't cover the following case >> I'd consider important: it doesn't allow me to block all messages from >> unknown contacts (contacts not in m

Re: [Standards] Deprecating Privacy Lists

> Hmm, not sure if you can translate this to xep191. What happens if a > xep191 client removes a jid entry which was added by the server because > the jid is the 'enemies' group? The server should map in both ways, i.e. reflect changes to XEP-0191 into the privacy lists, and also reflect changes

Re: [Standards] Deprecating Privacy Lists

* Florian Schmaus [2015-09-30 15:26]: > On 30.09.2015 15:09, Holger Weiß wrote: > > * Florian Schmaus [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: T

Re: [Standards] Deprecating Privacy Lists

On 30.09.2015 15:29, Christian Schudt wrote: > It's the server's responsibility to return an adequate block list, which is > built/mapped from a privacy list. > E.g. if the privacy list contains a single rule: >value='Enemies' > action='deny' > order='1'/> > > The

Re: [Standards] Deprecating Privacy Lists

On Wed, Sep 30, 2015 at 8:29 AM, Christian Schudt wrote: > IMO, it's not a client interop issue, but a server mapping issue and a lack > of well specified mapping rules. The problem is that privacy lists is almost too flexible, making it both difficult to implement, and difficult to create that

Re: [Standards] Deprecating Privacy Lists

On Wed, Sep 30, 2015 at 2:57 AM, Sergei Golovan wrote: > Well, It's unfortunate, because XEP-0191 doesn't cover the following case > I'd consider important: it doesn't allow me to block all messages from > unknown contacts (contacts not in my roster). Recently, I received a > fair amount of > spam

Re: [Standards] Deprecating Privacy Lists

> http://mail.jabber.org/pipermail/standards/2014-December/029430.html > The problem is that it's unclear (to me) how to map XEP-0016 rules that > block some kinds of stanzas but not others. If that's all, I think XEP-0191 §5 only lacks a more precise mapping of 0016 privacy list to block list.

Re: [Standards] Deprecating Privacy Lists

On 30.09.2015 15:09, Holger Weiß wrote: > * Florian Schmaus [2015-09-30 14:37]: >> On 30.09.2015 10:47, Holger Weiß wrote: >>> * Christian Schudt [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). >>> >>> Th

Re: [Standards] Deprecating Privacy Lists

* Florian Schmaus [2015-09-30 14:37]: > On 30.09.2015 10:47, Holger Weiß wrote: > > * Christian Schudt [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

Re: [Standards] Deprecating Privacy Lists

On 29.09.2015 22:02, Sam Whited wrote: > Deprecating privacy lists will simplify the XMPP stack and ...would remove the only way to for mobile clients to block communication on server side based on the subscription type. Which is currently the only way mobile clients can protect against a malicio

Re: [Standards] Deprecating Privacy Lists

On 30.09.2015 10:47, Holger Weiß wrote: > * Christian Schudt [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 §

Re: [Standards] Deprecating Privacy Lists

On 30 September 2015 at 09:07, Florian Schmaus wrote: > Can you deprecate something without having an equal powerful alternative > at hand? > >From a general standpoint, yes. Simplifying and removing unused use-cases seems perfectly fine. There are specific questions about whether there are im

Re: [Standards] Deprecating Privacy Lists

On 30 Sep 2015, at 09:07, Goffi wrote: > I think a XEP should not be deprecated if its features are not superseeded by > the new one(s). Just addressing this one point, rather than the wider ‘privacy lists’ issue. I don’t think there’s any need to have a new XEP providing all the features of a

Re: [Standards] XEP-0301 Annual review (In-Band Real Time Text)

> On 29 Sep 2015, at 21:44, Mark Rejhon wrote: > > Re: http://www.xmpp.org/extensions/xep-0301.html > > Infopage: http://www.realjabber.org > > I am doing an annual review of XEP-0301 adoption status. Last year, no >

Re: [Standards] Deprecating Privacy Lists

Le mercredi 30 septembre 2015, 10:47:44 Holger Weiß a écrit : > Interoperability between clients is broken today due to the use of two > incompatible extensions. Then the interop issue should be fixed. I think a global invisible command like in XEP-0186 is a really bad idea: invisibility is use

Re: [Standards] Deprecating Privacy Lists

* Christian Schudt [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. > I don't care about Prosody, but why would one remove XEP-0016 entir

Re: [Standards] Deprecating Privacy Lists

I agree to Florian, Goffi etc... XEP-0016 is complex, but powerful. I see no reason to deprecate it, just because there's a similar XEP (0191). In our company we've had an requirement to be invisible to certain roster groups. This is not solvable with other XEPs. The other mentioned use case -b

Re: [Standards] Deprecating Privacy Lists

I'm strongly against deprecating XEP-0016: we are working a lot with groups, and neither XEP-0191 nor XEP-0186 allow to block/be (in)visible only for a group. I think a XEP should not be deprecated if its features are not superseeded by the new one(s). thanks Goffi Le mardi 29 septembre 2015,

Re: [Standards] Deprecating Privacy Lists

On 29.09.2015 22:02, Sam Whited wrote: > I've brought up reconciling privacy lists and the blocking command in > the past [1], but the discussion faltered and it never went before the > council. It was brought up as part of a recent discussion again [2], > and I'd like to formally propose that it b

Re: [Standards] Deprecating Privacy Lists

Hi Sam, On Tue, Sep 29, 2015 at 11:02 PM, Sam Whited wrote: > I've brought up reconciling privacy lists and the blocking command in > the past [1], but the discussion faltered and it never went before the > council. It was brought up as part of a recent discussion again [2], > and I'd like to for