Re: [Standards] NEW: XEP-0387 (XMPP Compliance Suites 2017)

2017-02-09 Thread Sam Whited
On Thu, Feb 9, 2017 at 7:28 AM, Guus der Kinderen wrote: > Is footnote 10 "Support can be enabled via an external component or an > internal server module/plugin." relevant? I think the idea was to say "even if a server isn't compliant because it doesn't support this, a service using that server

Re: [Standards] NEW: XEP-0387 (XMPP Compliance Suites 2017)

2017-02-09 Thread Guus der Kinderen
Thanks for getting the ball rolling on this one again, Sam. Is footnote 10 "Support can be enabled via an external component or an internal server module/plugin." relevant? I suggest o remove footnote 6, and simply make CAPS a requirement on it's own. - Guus On 9 February 2017 at 00:32, XMPP Ex

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

2017-02-09 Thread Dave Cridland
On 9 February 2017 at 10:08, Evgeny Khramtsov wrote: > Thu, 9 Feb 2017 09:41:43 + > Dave Cridland wrote: > >> Because the server has to send an empty string, not the absence of a >> challenge. > > When does it make a difference (i.e. empty string vs its absence)? For a challenge, I can't thi

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

2017-02-09 Thread Evgeny Khramtsov
Thu, 9 Feb 2017 09:41:43 + Dave Cridland wrote: > Because the server has to send an empty string, not the absence of a > challenge. When does it make a difference (i.e. empty string vs its absence)? ___ Standards mailing list Info: https://mail.jab

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

2017-02-09 Thread Dave Cridland
On 9 February 2017 at 08:58, Evgeny Khramtsov wrote: > Thu, 9 Feb 2017 08:40:49 + > Dave Cridland wrote: > >> 3) > > I still do not understand, what's the point in sending > =? Because the server has to send an empty string, not the absence of a challenge. It's possible that no challenges

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

2017-02-09 Thread Ruslan N. Marchenko
On 09.02.2017 00:07, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0352 (Client State Indication). Abstract: This document defines a way for the client to indicate its active/inactive state. URL: http://xmpp.org/extensions/xep-0352.html Th

Re: [Standards] Improving Usability of XMPP Clients from the Bottom - Usability Considerations

2017-02-09 Thread Kevin Smith
On 8 Feb 2017, at 22:11, Tobias M wrote: > To improve the overall usability of XMPP software, I want authors to consider > how the protocols they design might be implemented, and how their protocol > influences the usability. Some examples for this are: > > * providing guidelines to what terms

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

2017-02-09 Thread Evgeny Khramtsov
Thu, 9 Feb 2017 08:40:49 + Dave Cridland wrote: > 3) I still do not understand, what's the point in sending =? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org

Re: [Standards] Improving Usability of XMPP Clients from the Bottom - Usability Considerations

2017-02-09 Thread Dave Cridland
On 8 February 2017 at 22:11, Tobias M wrote: > * providing guidelines to what terms to use for certain things the protocol > introduces, e.g. XEP-0319 could recommend “Idle since” or “last active at” > as possible phrases to use when presenting the time to the user > * defining that for MIX channe

Re: [Standards] Proposed XMPP Extension: Extensible SASL Profile

2017-02-09 Thread Dave Cridland
On 9 February 2017 at 05:50, Evgeny Khramtsov wrote: > Thu, 9 Feb 2017 02:05:35 + (UTC) > XMPP Extensions Editor wrote: > >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Extensible SASL Profile >> >> Abstract: This document describes a replacement for the SA

Re: [Standards] Improving Usability of XMPP Clients from the Bottom - Usability Considerations

2017-02-09 Thread Georg Lukas
* Tobias M [2017-02-08 23:12]: > I suggest adding a mandatory “Usability Considerations” to XEPs, even > if some XEPs will just say “This protocol provides no recommendations > to usability.” or something like that. +1 I think it would be useful to have the XEP template contain the “Usability Co