Re: [Standards] 2016 Compliance Suites
On 12 Oct 2015, at 12:01, Kurt Zeilenga wrote: > > >> On Oct 12, 2015, at 1:12 AM, Kevin Smith wrote: >> >> I don’t (although my opinion changes if this is Compliance versus BCP). > > I note that in some circles (like the IETF), a BCP carries full standard > weight. Do you mean an Informational guideline instead of standard? I’m referring to my previous comment about calling them something like “2015 Best Practices”. The XSF doesn’t have BCPs in the same way as the IETF. The idea is that we can say where we think implementations should be going at the moment, including stuff that is too fledgeling to start calling implementations ‘non-compliant’ if they’ve not picked it up yet. Perhaps “Current statement of direction” is better than “Best Practise”. My main point was to try to get away from things being Compliance-based, as we don’t use them for that. /K
Re: [Standards] 2016 Compliance Suites
> On Oct 12, 2015, at 1:12 AM, Kevin Smith wrote: > > I don’t (although my opinion changes if this is Compliance versus BCP). I note that in some circles (like the IETF), a BCP carries full standard weight. Do you mean an Informational guideline instead of standard? smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] 2016 Compliance Suites
On 10 Oct 2015, at 19:30, Sam Whited wrote: > > On Sat, Oct 10, 2015 at 1:27 PM, Peter Saint-Andre - &yet > wrote: >> But nice UI indicators are what people care about. :-) > > That's fair. Maybe I should make a client that just always waits some > random amount of time and then displays a green tick box (without > actually doing anything on the backend). It’s not about the UI in your client, it’s about what your client enables others to show in theirs. /K
Re: [Standards] 2016 Compliance Suites
> On 10 Oct 2015, at 19:11, Sam Whited wrote: > > On Thu, Oct 8, 2015 at 10:32 AM, Curtis King wrote: >> On Oct 8, 2015, at 3:33 AM, Ralph Meijer wrote: >> >> I agree that the latter three examples are nice to have, but I don't >> agree that Carbons, Chat States or CSI are nice to haves at this point >> in time. >> >> Thats your point of view not mine nor our customers. That’s the problem with >> the XEP it has a very narrow scope, just like carbons. > > > I think it makes sense to remove chat states and delivery receipts > since they don't really do anything but give you a nice UI indicator. I don’t, FWIW, think they should be removed. They may be just a ‘nice UI indicator’ for some folks, but they always rely on your contacts supporting them for you to do so. I consider implementing both in at least the form that’s useful for your contacts (sending CSN and Receipts when asked) best practice. > Carbons and CSI however have real benefits (in the form of making sure > that a message gets delivered to the correct client(s), and making > sure we're not eating battery on mobile devices). So I've left those > in. The XSF may disagree, of course, but we'll see. I don’t (although my opinion changes if this is Compliance versus BCP). /K
Re: [Standards] 2016 Compliance Suites
On Sat, Oct 10, 2015 at 1:27 PM, Peter Saint-Andre - &yet wrote: > But nice UI indicators are what people care about. :-) That's fair. Maybe I should make a client that just always waits some random amount of time and then displays a green tick box (without actually doing anything on the backend). —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] 2016 Compliance Suites
On 10/10/15 11:11 AM, Sam Whited wrote: On Thu, Oct 8, 2015 at 10:32 AM, Curtis King wrote: On Oct 8, 2015, at 3:33 AM, Ralph Meijer wrote: I agree that the latter three examples are nice to have, but I don't agree that Carbons, Chat States or CSI are nice to haves at this point in time. Thats your point of view not mine nor our customers. That’s the problem with the XEP it has a very narrow scope, just like carbons. I think it makes sense to remove chat states and delivery receipts since they don't really do anything but give you a nice UI indicator. But nice UI indicators are what people care about. :-) Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] 2016 Compliance Suites
On Thu, Oct 8, 2015 at 10:32 AM, Curtis King wrote: > On Oct 8, 2015, at 3:33 AM, Ralph Meijer wrote: > > I agree that the latter three examples are nice to have, but I don't > agree that Carbons, Chat States or CSI are nice to haves at this point > in time. > > Thats your point of view not mine nor our customers. That’s the problem with > the XEP it has a very narrow scope, just like carbons. I think it makes sense to remove chat states and delivery receipts since they don't really do anything but give you a nice UI indicator. Carbons and CSI however have real benefits (in the form of making sure that a message gets delivered to the correct client(s), and making sure we're not eating battery on mobile devices). So I've left those in. The XSF may disagree, of course, but we'll see. —Sam
Re: [Standards] 2016 Compliance Suites
On Tue, Oct 6, 2015 at 8:23 AM, Christian Schudt wrote: > The same for PubSub, which is missing, although it seems to become more and > more important. Note that pubsub is covered by PEP. Is it necessary to list both? I wouldn't think so, but I have no strong feelings one way or the other. Might as well be explicit and list both I guess. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
Re: [Standards] 2016 Compliance Suites
> On Oct 8, 2015, at 3:33 AM, Ralph Meijer wrote: > > I agree that the latter three examples are nice to have, but I don't > agree that Carbons, Chat States or CSI are nice to haves at this point > in time. Thats your point of view not mine nor our customers. That’s the problem with the XEP it has a very narrow scope, just like carbons. ck
Re: [Standards] 2016 Compliance Suites
On 2015-10-06 15:23, Christian Schudt wrote: >> 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) If you look at what people are looking for in the Slacks, HipChats and WhatsApps these days, I believe that CSI is crucial for mobile use for its positive effects on battery consumption. Delivery receipts are the blue checkmarks everyone loves (haha), and MAM and Carbons are there for chat history and communications sync requirements. > The same for PubSub, which is missing, although it seems to become more and > more important. PubSub is not a thing by itself. It comes in by way of Personal Eventing, but I would prefer to (also) list actual XEPs using PEP for whatever features that are deemed needed for these suites. > 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. I agree that the latter three examples are nice to have, but I don't agree that Carbons, Chat States or CSI are nice to haves at this point in time. -- ralphm
Re: [Standards] 2016 Compliance Suites
> On Oct 6, 2015, at 6:23 AM, Christian Schudt wrote: > > 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. +1 ck
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] 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] 2016 Compliance Suites
Oops, didn't upload a rendered version. Here it is: https://blog.samwhited.com/xeps/xep-cs2016.html —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com