Re: [Standards] 2016 Compliance Suites

[Kevin Smith]

On 10 Oct 2015, at 19:30, Sam Whited  wrote:
> 
> On Sat, Oct 10, 2015 at 1:27 PM, Peter Saint-Andre - 
>  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

[Kevin Smith]

> 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

[Kevin Smith]

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

[Kurt Zeilenga]

> 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

[Peter Saint-Andre -]

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

[Sam Whited]

On Sat, Oct 10, 2015 at 1:27 PM, Peter Saint-Andre - 
 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

[Sam Whited]

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

[Sam Whited]

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

[Curtis King]

> 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

[Curtis King]

> 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

[Christian Schudt]

> 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

[Kevin Smith]

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

[Sam Whited]

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

[Standards] 2016 Compliance Suites

[Sam Whited]

Hi all,

I've started working on updating the compliance suites (last done in
2012) on this branch:

https://github.com/SamWhited/xeps/tree/2016_compliance_suite

Right now there is a basic "Core" suite and an "IM" suite (which
builds upon the core suite for the common instant messaging
application of XMPP).

I'm sure most of these will probably change, but it's just a start.
I'd love your feedback on what should be included, and what should go
in what level so that we can bring a strong recommendation to the
council if/when they're finished.

I'd also love it if anyone who's more familiar with other aspects of
XMPP would be willing to add suites for other technologies (eg. IoT
devices) and send me a patch or make a PR against that branch.

Thanks,
Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

Re: [Standards] 2016 Compliance Suites

[Sam Whited]

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