Re: [Standards] XMPP Council Minutes 2019-01-16

2019-01-18 Thread Goffi
Le vendredi 18 janvier 2019, 15:56:28 CET Georg Lukas a écrit : > > 4) Outstanding Votes > > One each for Georg and Link, on "Order-By" (expiring 2019-01-23). > > +1 > > My detail objections still exist, but these are not sufficient to reject > the acceptance of the XEP. The ML discussion has

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

2019-01-18 Thread Georg Lukas
* Jonas Schäfer [2019-01-08 17:55]: > This message constitutes notice of a Last Call for comments on > XEP-0280. > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes, it is a very important piece for modern multi-client

Re: [Standards] XMPP Council Minutes 2019-01-16

2019-01-18 Thread Georg Lukas
* Tedd Sterr [2019-01-16 19:43]: > 1) Roll Call > Apologies: Link, Georg Sorry for missing it on short notice. > 3) Proposed XMPP Extension: Cryptographic Hash Function Recommendations for > XMPP - https://xmpp.org/extensions/inbox/hash-recommendations.html +1 > 4) Outstanding Votes > One

[Standards] Council Voting Summary 2019-01-18

2019-01-18 Thread Tedd Sterr
2019-01-09 (expiring 2019-01-23) Proposed XMPP Extension: Order-By - https://xmpp.org/extensions/inbox/order-by.html Dave: +0 (reserve the right to change that while others are still on-list) Georg: +1 (still have detail objections, but not enough to reject; interested in seeing how it

Re: [Standards] Tidying Deferred

2019-01-18 Thread Dave Cridland
On Thu, 17 Jan 2019 at 17:41, Ненахов Андрей wrote: > чт, 17 янв. 2019 г. в 15:38, Ralph Meijer : > > This is explicitly not how our standards process has been set up. The > > idea here is that having a published document as a starting point makes > > it more likely that people are not

Re: [Standards] Tidying Deferred

2019-01-18 Thread Evgeny
On Fri, Jan 18, 2019 at 12:19 PM, Dave Cridland wrote: is that those same people will expect to be able to have their specifications rubber-stamped through the process. I fail to see how this is even possible within the XSF process. If the spec is bad it will get -1 from the Council. But I,