Re: [Standards] Deprecating Privacy Lists
Tue, 6 Oct 2015 11:35:58 -0500 Sam Whited wrote: > and I doubt that > anyone's going to try and come up with a new thing *unless* the old > one is deprecated The thing is nobody will come up even in the case the XEP is deprecated. There were several attempts to write SPIM related XEPs. None of them was widely adopted. So we may end up with servers with privacy lists disabled and their users unprotected from some sort of attacks.
Re: [Standards] Deprecating Privacy Lists
On Tue, Oct 6, 2015 at 7:10 AM, Evgeny Khramtsov wrote: > Not sure I understand the sentence. Wouldn't it be better to find > "other ways" in blocking "unsolicited spam/flooding" *before* > deprecating XEP-0016? Because after deprecation nobody will perform > this task. I don't agree that we should wait; people can continue to use the existing functionality after it's been deprecated (like I said, it's not going to dissapear from every server overnight), and I doubt that anyone's going to try and come up with a new thing *unless* the old one is deprecated and more servers are *considering* dropping functionality. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] 2016 Compliance Suites
On Tue, Oct 6, 2015 at 7:03 AM, Kevin Smith wrote: > I think there might be merit in changing these from “Conformance Suites” to > something along the lines of “2015 Best Practices”. I think that leaves us > more free to include things that are best practice but not widely deployed > (e.g. Client State Indications) that otherwise we’d have to argue about > whether it’s reasonable to label something “non-conformant” because it > doesn’t implement them, or whether it’s reasonable to include Experimental > specs, while satisfying the main purpose for these suites of indicating which > XEPs people should be implementing right now. I like that idea too; makes me feel less weird about including the "experimental" features which I none-the-less feel are essential, or are widely deployed. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] 2016 Compliance Suites
> Please discuss. I think the outcome of that discussion probably affects what > should go into the suites. I never really understood the purpose of these "suites", nor did I feel the XSF is pushing them (last one is Deferred). Nonetheless, here are my thoughts (assuming it should be some kind of recommendation or list of "important features"): I don't like the idea to include Experimental specs in an "Implementation Recommendation / Best Practices / Suite" document. On the one hand you (XSF) recommend to implement/deploy it, on the other "Experimental" only encourages exploratory implementations. The suggested list also feels a bit arbitrary: I think File Transfer capabilities, vCard or Delayed Delivery are more important features, than delivery receipts or CSI. (That's also why the XMPP community has already specified and implemented them many years ago) The same for PubSub, which is missing, although it seems to become more and more important. But I think the only really important XEPs, that should be on the list, are XEP-0045 and XEP-0198. The rest more or less feels like "nice-to-have" features (e.g. Carbons, Chat States, CSI, ..). They could as well be "Idle Time", "Roster Item Exchange" or "Message Correction", depending on personal opinions/preferences. -- Christian
Re: [Standards] Deprecating Privacy Lists
Tue, 6 Oct 2015 12:43:06 +0100 Kevin Smith wrote: > On 5 Oct 2015, at 14:42, Matthew Wild wrote: > > XEP-0191 is simple and efficient. It does one job, which is the one > > that most users need and expect - blocking someone they not longer > > want communication with. This operation is available on just about > > every modern communication system they could be familiar with. > > > > Other problems that XEP-0016 could be applied to, such as > > unsolicited spam/flooding, should be taken care of in other ways, > > instead of trying to solve everything (inadequately) with one > > protocol. > > I agree. > > Deprecating 16 in favour of 191+the one extra common use case sounds > good to me. > > /K Not sure I understand the sentence. Wouldn't it be better to find "other ways" in blocking "unsolicited spam/flooding" *before* deprecating XEP-0016? Because after deprecation nobody will perform this task.
Re: [Standards] Deprecating Privacy Lists
Le mardi 6 octobre 2015, 13:09:34 Florian Schmaus a écrit : > I've started a Wiki Page to collect opinions, arguments and possible > solutions at > > http://wiki.xmpp.org/web/Server_Aided_Communications_Blocking > > Feel free to contribute your arguments, opinions and solutions. > > My summary so far is that blocking command does not support some use > cases I consider important. Most prominent is the ability to block > stanzas from entities they users is not subscribed to. This is required > in order to prevent an attacker, to which the user is not subscribed, > from draining a mobile users battery by sending stanzas to the users JID. > > - Florian Good idea, but the page is only talking about blocking, invisibility is in the same boat (it's not possible to be (in)visible to a roster group with XEP-0186). Goffi
Re: [Standards] 2016 Compliance Suites
On 1 Oct 2015, at 15:34, Sam Whited wrote: > I've started working on updating the compliance suites (last done in > 2012) on this branch: I hinted at this out of band, but I’ll raise it here too. I think there might be merit in changing these from “Conformance Suites” to something along the lines of “2015 Best Practices”. I think that leaves us more free to include things that are best practice but not widely deployed (e.g. Client State Indications) that otherwise we’d have to argue about whether it’s reasonable to label something “non-conformant” because it doesn’t implement them, or whether it’s reasonable to include Experimental specs, while satisfying the main purpose for these suites of indicating which XEPs people should be implementing right now. Please discuss. I think the outcome of that discussion probably affects what should go into the suites. /K
Re: [Standards] Deprecating Privacy Lists
On 5 Oct 2015, at 14:42, Matthew Wild wrote: > XEP-0191 is simple and efficient. It does one job, which is the one > that most users need and expect - blocking someone they not longer > want communication with. This operation is available on just about > every modern communication system they could be familiar with. > > Other problems that XEP-0016 could be applied to, such as unsolicited > spam/flooding, should be taken care of in other ways, instead of > trying to solve everything (inadequately) with one protocol. I agree. Deprecating 16 in favour of 191+the one extra common use case sounds good to me. /K
Re: [Standards] Deprecating Privacy Lists
I've started a Wiki Page to collect opinions, arguments and possible solutions at http://wiki.xmpp.org/web/Server_Aided_Communications_Blocking Feel free to contribute your arguments, opinions and solutions. My summary so far is that blocking command does not support some use cases I consider important. Most prominent is the ability to block stanzas from entities they users is not subscribed to. This is required in order to prevent an attacker, to which the user is not subscribed, from draining a mobile users battery by sending stanzas to the users JID. - Florian signature.asc Description: OpenPGP digital signature
